I recently read Coders at Work by Peter Seibel, which is a collection of interviews with famous programmers. It was a pretty interesting look at their backgrounds, programming processes, and what they thought was important to focus on.
Over the course of reading it, a few things jumped out at me that almost everyone mentioned and agreed on:
The importance of unpacking abstractions
If you don’t understand how something works, ask someone who does. A lot of people are skittish about that. —Jamie Zawinski
[What makes a good programmer?] Well, curiosity—taking things apart. Wanting to know what’s going on under the hood. I think that’s really the basis of it. Without that I don’t think you get very far. —Jamie Zawinski
[What do you think is the most important skill for a programmer to have?] Thinking like a scientist; changing one thing at a time. Patience and trying to understand the root cause of things. —Brad Fitzpatrick
Over the years I’ve kind of made a generic mistake and the generic mistake is to not open the black box. —Joe Armstrong
to really be a good programmer, you can’t just do that. You have to understand a little bit more, and say, “Is it safe, what I’m doing here? Or what are the failure cases? Sure, I tried it once and it worked, but is it always going to work? How do I write test cases to show that and to understand it a little better, and then once I’ve done that, can I extract what I’ve done and publish a new tool that other people can use because I’ve put these pieces together in a certain way.” —Peter Norvig
I can visualize the structure of programs and how things are efficient or inefficient based on those op codes, by seeing the bottom and imagining the hierarchy. And I can see the same thing with programs. —Ken Thompson
There’s this overemphasis on reusable software where you never get to open up the box and see what’s inside the box. It’s nice to have these black boxes but, almost always, if you can look inside the box you can improve it and make it work better once you know what’s inside the box. Instead people make these closed wrappers around everything and present the closure to the programmers of the world, and the programmers of the world aren’t allowed to diddle with that. —Donald Knuth
Code is written to be read
One of the constant themes of the interviews is a special focus on writing code not just to be correct, but to be readable: as Hoare put it, having “obviously no bugs, rather than no obvious bugs.”
Readability of code is now my first priority. It’s more important than being fast, almost as important as being correct, but I think being readable is actually the most likely way of making it correct. —Douglas Crockford
My attempts to make my programs readable. As Knuth would say, a program is essentially a work of literature. —Joshua Bloch
What I do instead is I will cheerfully spend literally hours on identifier names: variable names, method names, and so forth, to make my code readable. —Joshua Bloch
One that’s tricky is slight spelling errors in variable names. So I choose variable names that are very dissimilar, deliberately, so that error won’t occur. —Joe Armstrong
I like documentation. I don’t think a program is finished until you’ve written some reasonable documentation. —Joe Armstrong
You use reasonable variable names. That’s why I liked the keyword parameters in Smalltalk. It really makes things pretty readable. —Dan Ingalls
Documenting is an art as fine as programming. It’s rare I find documentation at the level I like. —Ken Thompson
The other rule is to realize that programs are meant to be read. Even though I’m guilty of writing pages of TECO macros back in my early days, I very quickly—probably when I was working on the PDP-1 time-sharing system and the complexity of the time-sharing system started to sink in— came to the belief that computer-program source code is for people, not for computers. —Bernie Cosell
I don’t put a lot of comments in my code because I think you should be writing your code so that it is readable and your algorithms and thoughts are clear in the code. —Bernie Cosell
The most extreme form of this is literate programming, but no one other than Knuth said that they actually used it. Honestly I think that even though Donald Knuth is awesome his programming process is pretty deeply weird, so I’m inclined not to update too strongly on the fact that it works so well for him.
Rewriting for simplicity
Another thing that distinguished many of the programmers was a strong belief that code almost never needs to be complicated:
It used to strike me as strange that people wrote complicated programs. I could see how to do things in a few lines and they’d written tens of lines and I’d sort of wonder why they didn’t see the simple way. I got quite good at that. —Joe Armstrong
I know that my boss, and probably some other of my colleagues, have said I was a great debugger. And that’s partly true. But there’s a fake in there. Really what I was was a very careful programmer with the arrogance to believe that very few computer programs are inherently difficult. —Bernie Cosell
If you’re looking at a piece of code and it looks very hard—if you can’t understand what this thing is supposed to be doing—that’s almost always an indication that it was poorly thought through. At that point you don’t roll up your sleeves and try to fix the code; you take a step back and think it through again. —Bernie Cosell
And because of this, they were willing to take unnecessarily complicated code and rewrite it.
I used to read programs and think, “Why are they writing it this way; this is very complicated,” and I’d just rewrite them to simplify them. —Joe Armstrong
The stuff where you can’t concentrate and something’s saying, “No, no, no, this is wrong, wrong, wrong”—I was ignoring that years ago. And I’d throw it all away. Now I can’t program anymore if it says, “No.” I just know from experience, stop—don’t write code. Stop with the problem. Do something else. —Joe Armstrong
[How do you decide when code needs to be thrown away?] When it’s hard to work on. I do it much quicker than most people do. I’ll throw away code as soon I want to add something to it and I get the feeling that what I have to do to add it is too hard. —Ken Thompson
So I would think through what it was supposed to do, throw it away, and write it again from scratch. —Bernie Cosell
Most of the bad programs I ran into, the ones where I threw things out and recoded them, there wasn’t a little island of complexity you could try to understand and fix, but the complexity had oozed through the program. —Bernie Cosell
Then I’d get an insight—“Ah! Wrong! Idiot!” I’d rewrite it. Again: “Yeah, it’s wrong”—rewrite it. I remember thinking to myself, “Wouldn’t it be nice if I could think all of this stuff instead of writing it?” Wouldn’t it be nice if I could get this insight without writing it. I think I can do that now. So I would characterize that period, which took 20 years, as learning how to program. —Joe Armstrong
Comments
Thanks