Peter Seibel - Coders at Work - Reflections on the craft of programming

And then I end up writing all these stupid little shell scripts—selfdefense stuff. I know I could do this by clicking on 30,000 web pages and doing it by hand, but why don’t I write this script—little timesaver things. Which barely feels like programming to me. I know to people who aren’t programmers, that seems like a black art.

I really enjoyed doing the Mac port of the XScreenSaver framework. That was actually writing a lot of new code that required thinking about APIs and the structure of the thing.

Seibel:Was that your APIs—how you were structuring your code?

Zawinski:Both. Both figuring out the existing APIs and figuring out the best way to build a layer between the X11 world and the Mac world. How should I structure that? Which of the Mac APIs is most appropriate? It was the first time in a long time that I’d done something like that and it was just like, “Wow, this is kind of fun. I think I might be kind of good at this.”

It had been forever because I got completely burned out on the software industry. That part of it I just couldn’t take anymore—the politics of it both in the corporate world and in the free-software world. I’d just had too much. I wanted to do something that didn’t involve arguing online about trivia. Or having my product destroyed by bureaucratic decisions that I had no input in.

Seibel:Are you ever tempted to go back and hack on Mozilla?

Zawinski:Nah. I just don’t want to be arguing with people and having pissing matches in Bugzilla anymore. That’s not fun. That kind of thing is necessary to build big products. If it’s something that requires more than one person working on it, which obviously Mozilla does, that’s the way you have to do it. But I don’t look forward to that kind of fight anymore. That’s been beaten out of me by too many years of it. And the other alternative, as a programmer, is go work for someone else. And I don’t have to do that, so I can’t. My first bad day I’d just leave. And were I to start my own company I couldn’t be a programmer—I’d have to run the company.

Seibel:Other than having two million people using your software, what about programming do you enjoy?

Zawinski:It’s a hard question. The problem-solving aspect of it, I guess. It’s not quite like it’s a puzzle—I don’t really play many puzzletype games. Just figuring out how to get from point A to point B—how to make the machine do what you want. That’s the basic element that the satisfaction of programming comes from.

Seibel:Do you find code beautiful? Is there an aesthetic beyond maintainability?

Zawinski:Yeah, definitely. Anything expressed just right, whether it’s being really concise or just capturing it—like anything, a really wellput-together sentence or a little doodle, a caricature that looks just like someone but only used four lines, that kind of thing—it’s the same sort of thing.

Seibel:Do you find that programming and writing are similar intellectual exercises?

Zawinski:In some ways, yeah. Programming is obviously much more rigid. But as far as the overall ability to express a thought, they’re very similar. Not rambling, having an idea in your head of what you’re trying to say, and then being concise about it. I think that kind of thinking is the overlap between programming and writing prose.

It feels like they use similar parts of my brain, but it’s hard to express exactly what it is. A lot of times I’ll read things that just look like bad code. Like most contracts. The really rigid style they use—it’s so repetitive. I look at that and I’m like, why can’t you break this out into a subroutine—which we call paragraphs. And the way they usually begin with definitions, like, so and so, referred to as blah blah blah.

Seibel:Lets talk a little bit about the nitty-gritty of programming. How do you design your code? How do you structure code? Maybe take your recent work on the OS X XScreenSaver as an example.

Zawinski:Well, first I messed around and made little demo programs that never ended up being used again. Just to figure out here’s how you put a window on the screen, and so on. Since I’m implementing X11, the first thing to do is pick one of the screen savers and make the list of all the X11 calls it makes.

Then I create stubs for each of those and then I slowly start filling them in, figuring out how am I going to implement this one, how am I going to implement this one.

At another level, on the Mac side of things, there’s the start-up code. How is the window getting on the screen? And at some point that’s going to call out to the X code. One of the trickier parts of that was really figuring out how to set up the build system to make that work in any kind of sane way. So a bunch of experimentation. Moving things around. At some point, maybe I’d had this piece of code on top and this piece of code being called by it. And then maybe those need to be turned inside out. So there’s a lot of cut-and-pasting until I kind of wrapped my head around a flow of control that seemed sensible. Then I went in and cleaned things up and put things in more appropriate files so this piece of code is together with this piece of code.

That was sort of the broad strokes, building the infrastructure. After that it was just a matter of moving on to the next screen saver; this one uses these three functions that the previous one hadn’t used before, so I’ve got to implement those. And each of those tasks was fairly straightforward. There were some that ended up being really tricky because the X11 API has a ton of options for putting text on the screen and moving rectangles around. So I kept having to make that piece of code hairier and hairier. But most of them were fairly straightforward.

Seibel:So for each of these X11 calls you’re writing an implementation. Did you ever find that you were accumulating lots of bits of very similar code?

Zawinski:Oh, yeah, definitely. Usually by the second or third time you’ve cut and pasted that piece of code it’s like, alright, time to stop cutting and pasting and put it in a subroutine.

Seibel:If you were doing something on the scale of writing a mail reader again, you mentioned starting with a few paragraphs of text and a list of features. Is that the finest granularity that you would get to before you would just start writing code?

Zawinski:Yeah. Maybe there’d be a vague description of the division between library and front end. But probably not. If I was working alone I wouldn’t bother with that because that part is just kind of obvious to me. And then the first thing I would do with something like that is either start at the top or at the bottom. So start with either, put a window on the screen that has some buttons on it, and then dig down and start building the stuff that those buttons do. Or you can start at the other side and start writing the thing that parses mailboxes and that saves mailboxes. Either way. Or both and meet in the middle.

I find that getting something on the screen as soon as possible really helps focus the problem for me. It helps me decide what to work on next. Because if you’re just looking at that big to-do list it’s like, eh, I don’t know which one I should do—does it matter which one I do? But if there’s something you can actually look at, even if it’s just the debug output of your mailbox parser, it’s like, OK, there! That’s something; what’s the next direction this needs to go in? OK, instead of just displaying a tree structure, now maybe I should be emitting HTML or something along those lines. Or parsing the headers in a more detailed way. You just look for the next thing to build on from there.