Antirez, creator of Redis, excellent C programmer and API designer, tweeted this:
https://twitter.com/antirez/status/1282967596350881792 (the thread goes both up and down from this link, it'd be helpful to scroll up then read)
He says (paraphrasing) that
(0) while programming is many things to many people,
(1) to him, part of programming is being able to implement a bubble sort or selection sort (slow, quadratic algorithms that are rarely seen outside beginner courses) under pressure—in an interview or on the job,
(2) and, if you struggle to produce a working bubble sort, he expects you will likely also struggle with other day-to-day dev tasks.
I would mostly disagree, but more than that, I was surprised to hear Antirez say all this, because he has also spoken at length about the importance of getting the API design right. He talks about spending days working and reworking an API:
"I really mean it when I say days, just for the API. Writing drafts, starting the implementation shaping data structures and calls, and then restarting from scratch to iterate again in a better way, to improve the design and the user facing part. Why I do that, delaying features for weeks? Is it really so important? Programmers are engineers, maybe they should just adapt to whatever API is better to export for the system exporting it." http://antirez.com/news/107
I had implicitly believed that anyone who valued the importance of API quality, of making them ergonomic and perfectly-matched to the problem at hand, would simultaneously believe that implementing things like bubble sort was UNimportant. So his tweet thread above made me realize that you can believe in both the importance of classic programmer puzzles AND of API design (and presumably use).
To clarify my position a bit—I do know people who can visualize an algorithm for a code puzzle in their heads and then throw down the code at the speed of typing. I think that skill is neither necessary nor sufficient to succeed in the day-to-day dev work I do, of building apps. I believe if someone can't implement a working bubble sort in an hour, I can teach them what they need to know in another hour, and they'll be able to contribute to my codebase just as effectively.
I feel that the bulk of my work can be broken down into three types:
-
writing low-level things (sorts, database drivers, DOM manipulation libraries, numerical special functions): 1% of my time, 5% in importance, because while it'll probably be buggy and incomplete, it does occasionally unlock a competitive edge
-
gluing together APIs others have designed, APIs of varying levels of quality: 80% of my time, 20% in importance because this is what actually delivers value to my users
-
ensuring that the APIs that we've built for our application reflecting our understand of our users and domain: 19% of my time, 80% in importance, because I completely agree with Antirez' blog post about the importance and value of APIs that are as perfectly-matched to your domain as humanly possible. This is what ensures that we continue being able to deliver for our users, with minimal technical debt.
The dev who can't implement bubble sort without some handholding—within <10 sessions implementing various similar low-level algorithms, they'll be able to handle it on their own.
But they can immediately begin creating value by gluing together APIs (other people's and ours) and solving our problems.
And they can be incredibly helpful both detecting and fixing infelicities or unsmoothed edges in your API representation of your business domain.
I'm fine with you not knowing how to solve a puzzle. We'll learn how to do that. We can teach you other people's APIs (SQL, Pandas, STL, Unity, React, etc.). Because we want you to bring your instincts about the business domain and make sure our APIs represent our best understanding of that domain.
I promised Stefan Knüpfer: there's a whole documentary on his work tuning the pianos of the world's great soloists but here's a great starter: https://www.youtube.com/watch?v=fsdqgvIYX-Q
Knüpfer creates the pianos. Aimard plays the pianos.
Asking someone to be able to do bubble sort is confusing the pianist from the tuner. I see the people who deign languages and runtimes and external libraries as Knüpfers. Crucial, but orthogonal to my task as a pianist—of using the tool to do something else.
(Posted to Octodon, 2020-11-11. Reprinted here with minor modifications.)