Coders at Work: Reflections on the Craft of Programming

by Peter Seibel

I enjoy working on XScreenSaver because in some ways screen savers—the actual display modes rather than the XScreenSaver framework—are the perfect program because they almost always start from scratch and they do something pretty and there's never a version 2.0. There's very rarely a bug in a screen saver. It crashes—oh, there's a divide-by-zero and you fix that. But no one is ever going to ask for a new feature in a screen saver. “I wish it was more yellow.” You're not going to get a bug report like that. It is what it is. So that's why I've always written those for fun. They make this neat result and you don't have to think about them too much. They don't haunt you.

I think one thing that's really important is to not be afraid of your ignorance. If you don't understand how something works, ask someone who does. A lot of people are skittish about that. And that doesn't help anybody. Not knowing something doesn't mean you're dumb—it just means you don't know it yet.

“I want to be a programmer; what do I do?” Or, “Should I go to college or not?” How can I answer that? I would have had very strong opinions about this if you asked me in 1986. But someone today couldn't take the same path that I took because that path doesn't even exist anymore.

But I've always seen much more in common with writing prose than math. It feels like you're writing a story and you're trying to express a concept to a very dumb person—the computer—who has a limited vocabulary. You've got this concept you want to express and limited tools to express it with. What words do you use and what does your introductory and summary statement look like? That sort of thing.

I definitely try to find an excuse to use anything, to learn it. Because you never learn something until you have to write something in it, until you have to live and breathe it. It's one thing to go learn a language for fun, but until you write some big, complex system in it, you don't really learn it.

Seibel: Some folks would also argue that learning to program teaches a way of thinking that's important, like reading and math are different ways of thinking, and both important. Crockford: I used to think so. I had these amazing insights when I started programming: everything became orderly, and I saw structures and things I had never seen before. I thought, “Wow, this is amazing. Everybody should learn how to do this,” because suddenly I was feeling a lot smarter. Except pretty quickly I'd find, talking to other programmers, that somehow they didn't get it. Programmers are capable of completely misunderstanding the world in exactly the same way everybody else does. I was really sad to figure that out.

The more things you learn and the younger you learn them, the better off you are.

The older I get, the more I realize it isn't just about making it work; it's about producing an artifact that is readable, maintainable, and efficient. Generally speaking, I find that, contrary to popular belief, the cleaner and nicer the program, the faster it's going to run. And if it doesn't, it'll be easy to make it fast. As they say, it's easier to optimize correct code than to correct optimized code.

But when you choose a language, you're choosing more than a set of technical trade-offs—you're choosing a community. It's like choosing a bar. Yes, you want to go to a bar that serves good drinks, but that's not the most important thing. It's who hangs out there and what they talk about. And that's the way you choose computer languages.

But the fundamental rule is, write the code that uses the API before you write the code that implements it. Because otherwise you may be wasting your time writing implementation code that won't get used. In fact, write the code that uses the API before you even flesh out the spec, because otherwise you may be wasting your time writing detailed specs for something that's fundamentally broken.

We're all optimists in our profession or we'd be forced to shoot ourselves.

So I would characterize that period, which took 20 years, as learning how to program. Now I know how to program. I was doing experiments to learn how to program. I think I know how to program now and therefore I don't have to do the experiments anymore.

And what I've learned is, programming when you're tired, you write crap and you throw it all away the next day.

The really good programmers spend a lot of time programming. I haven't seen very good programmers who don't spend a lot of time programming. If I don't program for two or three days, I need to do it. And you get better at it—you get quicker at it. The side effect of writing all this other stuff is that when you get to doing ordinary problems, you can do them very quickly.

I think if you're a beginner you think it's big and complicated so you don't do it. Things you don't do are difficult and things you've done are easy. So you don't even try. And I think that's a mistake.

I've always taken the view of system design, you solve the hard problems first. Identify the hard problems and then solve them. And then the easy problems, you know they'll just come out in the wash.

“I always spend a day a week learning new stuff. That means I spend 20 percent more of my time than my colleagues learning new stuff. Now 20 percent at compound interest means that after four and a half years I will know twice as much as them. And because of compound interest, this 20 percent extra, one day a week, after five years I will know three times as much,”

You're five times as productive if you're working on something that makes you enthusiastic.

Because, after all, unless some people are working on radical and elegant things you're going to end up in a local optimum, incrementally optimizing the mainstream but stuck on a low hill.

When I was in school, working as a team was called cheating.

And I think that's easier when you're younger, because your brain is better at it, or maybe it's just that you have less distractions. If you have kids, and family, and so on, you just can't devote as many consecutive hours as when you don't.

Seibel: You also mentioned Knuth's TeX, which is obviously a much larger program. What is it that makes that program beautiful? Steele: He took a very, very complicated program with lots of special cases and reduced it to a single, very simple paradigm: sticking boxes and glue together. That was an immensely critical breakthrough. It turns out to be flexible not only for typesetting text but for all manner of other things as well that have to do with laying things out visually, two-dimensionally, on a page. I wish that more GUI interfaces were based on boxes and glue for laying out buttons and things like that.

But there's also this side of it, and it's sort of the archetypal aspect of exploratory programming, which is if it gets you more quickly to an environment that you can learn from, you may find out that some of your original goals don't even matter. What's much more important is that other thing over there. And that becomes a whole new focus.

It's very much still a part of my passion, and I'm sure Alan's too, to take people through some deep dive in a direction that they're motivated about so they come away with what Alan calls powerful ideas—the “aha!” that lets you see this amazing variety is really a couple of small, general things at work.

There's an algebra of graphics. It's primitive objects, superposition translation, rotation. Or music. It's notes and temporal sequences and chordals—same thing. And I think this goes back to seeing how the wind works and how the planets move. It's an invitation to go down and find out how things work and learn the things that make up the algebra—the processes and the primitive things. So yes, that fifth area, as you call it, is just what's common about all of these things.

There's an analogy here: I tried to learn to play piano fairly late in life. People said, “Oh, you should learn when you're young. You learn so much quicker.” Although I didn't go very far, my conclusion was that it isn't that young people learn that much faster; it's just they have more time. When I would put time in, I made progress. I feel a bit the same thing with programming. When I look back on earlier times in my life, I had all the time I wanted. I would just work and work. Now there are other things going on in my life and I've got responsibilities that aren't just programming. That undermines a bit of that intense focus.

Well, part of the reason that I don't call myself a computer scientist any more is that I've seen software practice over a period of just about 50 years and it basically hasn't improved tremendously in about the last 30 years.

My definition of fragile code is, suppose you want to add a feature—good code, there's one place where you add that feature and it fits; fragile code, you've got to touch ten places.

How do you identify talented programmers? Thompson: It's just enthusiasm. You ask them what's the most interesting program they worked on. And then you get them to describe it and its algorithms and what's going on. If they can't withstand my questioning on their program, then they're not good.

I'm asking them to describe something they've done that they've spent blood on. I've never met anybody who really did spend blood on something who wasn't eager to describe what they've done and how they did it and why. I let them pick the subject. I don't pick the subject, so I'm the amateur and they're the professional in this subject. If they can't stand an amateur asking them questions about their profession, then they don't belong.

I have a couple of rules that I try to impress on people, usually people fresh out of college, who believe that they understand everything there is to know about programming. The first is the idea that there are very few inherently hard programs. 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. When you've thought it through enough, you'll find out that it's easy.