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

Seibel:Of course you didn’t know there were going to be two Emacs at that point.

Zawinski:Sure. But even without that, even if there had only been one Emacs, there were still two Emacs—there was Emacs 18 and Emacs 19. There was still going to be a compatibility problem. In hindsight those were changes that if I’d realized what an impact it was going to make, I probably would have done that differently. Or spent a lot more time on making the old way work as well. That kind of thing.

Seibel:Earlier you said something about writing code in order to make it easier to read, which ties into maintenance. What are the characteristics that make code easier to read?

Zawinski:Well, comments obviously. Writing down what the assumptions are and what this does. If it’s building up a data structure, describing the layout of it. A lot of times I find that pretty helpful. Especially in writing Perl code when it’s like, uh, well, it’s a hash table and values are bunch of references to lists, because the data structures in Perl are just nuts. Do I need a right arrow here to get to this? I find examples like that to be helpful.

I always wish people would comment more, though the thing that makes me cringe is when the comment is the name of the function rephrased. Function’s called push_stack and the comment says, “This pushes to the stack.” Thank you.

You’ve got to say in the comment something that’s not there already. What’s it for? Either a higher-level or a lower-level description, depending on what’s most important. Sometimes the most important thing is, what is this for? Why would I use it? And sometimes the most important thing is, what’s the range of inputs that this expects?

Long variable names. I’m not a fan of Hungarian notation, but I think using actual English words to describe things, except for loop iterators, where it’s obvious. Just as much verbosity as possible, I guess.

Seibel:What about organization—ultimately there’s some linear organization but programs are not really linear. Do you organize your code top-down or bottom-up?

Zawinski:I usually end up putting the leaf nodes up at the top of the file—try to keep it basically structured that way. And then usually up at the top, document the API. What are the top-level entry points of this file, this module, whatever? With an object-y language, that’s done by the language for you. With C you’ve got to be a little more explicit about that. In C I do tend to try to have a .h file for every .c file that has all the externs for it. And anything that’s not exported in the .h file is static. And then I’ll go back and say, “Wait, I need to call that,” and I change it. But you’re doing that explicitly rather than just by accident.

Seibel:You put the leaves first in the file, but is that how you write? Do you build up from leaves?

Zawinski:Not always. Sometimes I start at the top and sometimes I start at the bottom. It depends. One way is, I know I’m going to need these building blocks and I’ll put those together first. Or another way of thinking about it is, you’ve sort of got an outline of it in your head and you dig down. I do it both ways.

Seibel:So suppose for the sake of argument that you were going to come out of retirement and build a development team. How would you organize it?

Zawinski:Well, I think you want to arrange for there to be no more than three or four people working really closely together on a day-today basis. Then that can scale up a lot. Say you’ve got a project where you can divide it up into twenty-five really distinct modules. Well, you can have twenty-five tiny teams—maybe that’s a little much. Say ten. And as long as they can coordinate with each other, I don’t think there’s a whole lot of limit to how big you can scale that. Eventually it just starts looking like multiple projects instead of like one project.

Seibel:So you’ve got multiple teams of up to four people. How do you coordinate the teams? Do you have one grand architect who’s managing the dependencies and mediating between those teams?

Zawinski:Well, there’s got to be agreement about what the interface between modules is. For that very modular approach to work at all, the interface between modules has to be clear and simple. Which, hopefully, means it won’t take too much screaming for everyone to agree on it and it won’t be too difficult to follow the module contract. I guess what I’m getting at is the best way to make interaction between modules be easy is to just make it be really simple. Make there be fewer ways for that to go wrong.

And what lines you divide on depends entirely on a project. With some kind of web app you’ve probably got the UI and you’ve got your database and the part that runs on the server and the part that runs on the machine behind the server. And if it’s a desktop application it’s similar division of labor. There’s file formats and GUI and basic command structure.

Seibel:How do you recognize talent?

Zawinski:That I don’t know. I’ve never really been the person who had to hire people. And when I’ve been involved in interviews I’ve always just felt like I had no idea. I can tell from the interview whether I’d get along with this person, but I can’t tell whether they’re any good or not just by talking to them. I always found that difficult.

Seibel:How about if they’re bad? Are there reliable clues then?

Zawinski:Sometimes. Normally I would think that someone who is a big fan of C++ templates—keep me away from that guy. But that might just be a snap judgment on my part. Maybe in the context they’ve used them, they actually work fine. Certainly with the folks I’ve worked with, ability to argue their point was important because we all ended up being a pretty argumentative bunch. With that environment, that helped a lot. That certainly doesn’t have anything to do with programming ability. That’s just interpersonal-dynamics stuff.

Seibel:And on a different team, that would actually be detrimental.

Zawinski:Yeah, absolutely.

Seibel:It sounds like at Netscape you guys divided things up so people owned different parts of the software. Some people think that’s really important. Other folks say it’s better for a team to collectively own all the code. Do you have an opinion on that?

Zawinski:I’ve done it both ways. They both have their merits. The idea that everyone should own all the code, I don’t think is really practical because there’s going to be too much of it. People are going to have to specialize; you need an expert sometimes. It’s just always going to work out that way. There’s always going to be the code you’re familiar with because you happened to write more of that module than some other guy did. Or there’s just going to be parts that resonate with you more. It’s certainly good for other people to have their hands in it, if only because you’re not going to be maintaining it yourself forever. It’s going to have to be handed off to someone else for one reason or another. And for that knowledge to be spread around is good. But it’s also good to have someone to blame. If everybody is responsible for it then there’s no one to put their foot down.

Seibel:Have you ever been a manager?

Zawinski:Not really. When I was doing the Emacs stuff at Lucid, there would be a lot of modules that were included in Lucid Emacs that were written by other people. Those people didn’t really work for me but it was a little bit like management. And a lot of those people were definitely less experienced and the way that worked out well was they were doing their favorite thing and I was basically giving them feedback: “Well, I want to include this but first I need this, this, and this from it.”