Linus Torvalds gave a TED talk. This talk is interesting first because Linus has had such an influence on software; a majority of web servers and mobile phones are presently running code that he wrote. But second, it’s interesting because we get a chance to learn from such a great programmer.
He says three things that I’d like to dig into:
- What he chooses to work on
- What personality traits he believes have helped him as a computer programmer
- What he thinks having good taste in code means
First, what does he choose to work on?
Linus says in the talk that “I’m an engineer … I want to fix the pothole that’s right in front of me before I fall in.” That seems like a good way to build software: Fix problems that are real that you (or other people) actually have.
I’d like to contrast it with a guy at a random party who, never having built a world-changing operating system kernel or a world-changing version control system, can serve as a nice contrast. “I have an idea for an app,” he says, “it’s like Facebook, but…” and goes on to describe Facebook. Now, this guy is being polite, taking an interest in my career (sort of), which is nice. But I don’t think he’s giving good advice. The day to day work of software development is really about iteration, about fixing one problem at a time until you build something really good. Even Facebook started really small.
Now, random-party-guy might go on to found the next Twitter, or something, but most developers, most of the time, make slow progress by solving one little problem at a time. The site crashes if too many people try to download materials they previously uploaded at the same time. Certain important database queries are too slow. With certain data entered, some page on the website becomes unresponsive. I think an important part of learning to program is learning to derive satisfaction from repeatedly solving small problems.
Second, what personality traits make him a good programmer?
Stubborn. That was a personality trait that Linus emphasized quite a bit during the interview. Why should a software engineer be stubborn? First, because nothing ever works the first time, and most things are not easy to learn. But second, because, using modern tools at least, software is “kinda, mostly” working for 85% of the development time. In other words, it’s very, very easy to build software that’s OK. It usually doesn’t crash, you can figure out the interface if you play with it for a while. But the problem is that it takes a lot of fighting small, incremental little fixes to get from 85% to 100%. (If you want to see some very in-depth work to fix very small things, take a look at The Old New Thing.)
If we build a portrait of Linus Torvalds, from his own words, he is a stubborn, pragmatic engineer. He will fight with the problem right in front of him until it is well and truly solved, and then look for the next problem. I think these are traits to imitate.
Third, what does he call “taste” in code?
The part of the TED talk that was about code was pretty brief. About 14 minutes into the talk, Linus puts up two slides of code, both of which are examples of a method that will delete an item from a singly linked list. In this situation, there are three nodes that you care about: the node before the one we’re deleting, the node we’re deleting, and the node after the node we’re deleting. In Linus’s first example, there’s an if check to see whether the node we’re deleting is the beginning of the list. If it is, we have to treat it differently. The second example, which is the one Linus likes, there’s a while loop that simply runs zero times if we’re removing the beginning of the list, so there is no if-statement.
This piece of code is pretty trivial, but he makes an important point:
“I don’t want you understand why it doesn’t have the if statement, but I want you to understand that sometimes you can see a problem in a different way and rewrite it so that a special case goes away and becomes the normal case. And that’s good code”
Shortly after I saw this talk, at work I wrote a while statement. After a few minutes of thinking, I was able to write the method so that the while statement executing zero times wasn’t special. I think it was a good mental exercise, and the code is certainly easier to read. In a future article, I want to dig more into what Linus might mean by “special case.” I feel I’ve barely scratched the surface here.
So, next time you see a special case in code, ask yourself, “Is that special case a special case in the domain? Do business people think that is a special case? Or did we make that special by not having Linus’ taste in code?”
Till next week, happy learning!