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

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

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

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

It feels like they use similar parts of my brain, but it’s hard to expressexactly what it is. A lot of times I’ll read things that just look like badcode. Like most contracts. The really rigid style they use—it’s sorepetitive. I look at that and I’m like, why can’t you break this out intoa subroutine—which we call paragraphs. And the way they usuallybegin 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? Maybetake your recent work on the OS X XScreenSaver as an example.

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

Then I create stubs for each of those and then I slowly start fillingthem in, figuring out how am I going to implement this one, how am Igoing 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’sgoing to call out to the X code. One of the trickier parts of that wasreally figuring out how to set up the build system to make that work inany kind of sane way. So a bunch of experimentation. Moving thingsaround. At some point, maybe I’d had this piece of code on top andthis piece of code being called by it. And then maybe those need to beturned inside out. So there’s a lot of cut-and-pasting until I kind ofwrapped my head around a flow of control that seemed sensible. ThenI went in and cleaned things up and put things in more appropriate filesso this piece of code is together with this piece of code.

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

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

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

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

Zawinski: Yeah. Maybe there’d be a vague description of the divisionbetween library and front end. But probably not. If I was workingalone I wouldn’t bother with that because that part is just kind ofobvious to me. And then the first thing I would do with something likethat 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 digdown and start building the stuff that those buttons do. Or you canstart at the other side and start writing the thing that parses mailboxesand that saves mailboxes. Either way. Or both and meet in the middle.

I find that getting something on the screen as soon as possible reallyhelps focus the problem for me. It helps me decide what to work onnext. Because if you’re just looking at that big to-do list it’s like, eh, Idon’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 thedebug output of your mailbox parser, it’s like, OK, there! That’ssomething; what’s the next direction this needs to go in? OK, insteadof just displaying a tree structure, now maybe I should be emittingHTML or something along those lines. Or parsing the headers in amore detailed way. You just look for the next thing to build on fromthere.

Seibel: Do you refactor to keep the internal structure of the codecoherent? Or do you just have a very good sense at the beginning howit’s all going to fit together?

Zawinski: I usually have a pretty good sense of that. I don’tremember too many occasions where I thought, “Oh, I did this wholething inside out. I’m going to have to move everything around.” Thatdoes happen sometimes.

When I’m just writing the first version of the program, I tend to puteverything in one file. And then I start seeing structure in that file. Likethere’s this block of things that are pretty similar. That’s a thousandlines now, so why don’t I move that into another file. And the API sortof builds up organically that way. The design process is definitely anongoing thing; you never know what the design is until the program isdone. So I prefer to get my feet wet as early as possible; get somethingon the screen so I can look at it sideways.

Also, once you start writing the code, you’re gonna realize, “No, thatwas a dumb idea. Why did I think that this module was going to bereally easy when actually it’s way more complicated than I thought?”

Which is something you’re not going to clue into until you actuallystart writing code and you feel it getting away from you.

Seibel: What are the signs that something is getting away from you?

Zawinski: When you go into something and you have in your head,“Oh, this is going to take me half a day and it’s gonna be a chunk ofcode this size,” and then you start doing it and you get that sinkingfeeling like, “Oh, right, I need this other piece too; well, I’d better gooff and do that. Oh, and that’s kind of a big problem.”

Seibel: I’ve noticed that one thing that separates good programmersfrom bad programmers is that good programmers are more facile atjumping between layers of abstraction—they can keep the layersdistinct while making changes and choose the right layer to makechanges in.

Zawinski: There’s definitely got to be some style in where you decideto put things—it can matter a lot down the line. Being able to justhack it out somewhere up near the user versus making a maybe largerchange that may have repercussions down at the bottom—either ofthose can be the right answer and it is tricky to know which is which.

This change I need to make, is it really one little special case or arethere eventually going to be 12 of these?I think one of the most important things, for me anyway, whenbuilding something from the ground up like that is, as quickly aspossible, getting the program to a state that you, the programmer, canuse it. Even a little bit. Because that tells you where to go next in areally visceral way. Once the thing’s on the screen and you’ve got theone button hooked up that does one thing, now you kind of know,which button is next. Obviously that’s a GUI-centric description ofwhat I’m talking about.