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.”

Seibel: And did you give them a free rein? You tell them you want X, Y, and Z and then they get to figure out how to do it?

Zawinski: Yeah. If I’m trying to decide whether to include this module in the thing that I’m going to ship, I’m going to have requirements about it. Does the damn thing work is really the bottom line there. So I would give them advice on, “I think you’re going to have better luck if you try it this rather than this way.” But I wanted it to work and I wanted to not have to be the one to write it. If they wanted to go do it in some crazy way but it worked, that was OK because that gave me point two: I didn’t have to write it. But mostly the feedback I was giving them was just, does it work and does it make sense.

Seibel: On the flip side, when you were the less-experienced programmer, what did your mentors do that was helpful?

Zawinski: I guess the most important thing is they’d recognize when it was time to level up. When I went to work for Fahlman I was given some silly little busy work. And eventually got given tasks that were a little more significant—not that they were significant at all really.

Seibel: I think you talked about Rob MacLachlan, who just hovered and said, “Wrong!” Was that balanced, perhaps, by someone else who was a little more nurturing?

Zawinski: Well, he wasn’t completely a cave man. He would actually tell me things, too. I know I ended up doing a lot of reading of code and asking questions. 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.

Seibel: Did you read code mostly because it was something you were working on, or was it just something you wanted to know how it worked?

Zawinski: Yeah. Just poking around—“I wonder how that works.” The impulse to take things apart is a big part of what gets people into this line of work.

Seibel: Were you actually one of those kids who took toasters apart?

Zawinski: Yeah. I made a telephone and learned how to dial with a telegraph tapper that I made out of a tin can. When I was little I had these old books I got at a garage sale or something, like Boy’s Own Science Book from the ’30s, and I remember getting a really big kick out of those. That was really hacker culture in the ’20s and ’30s where they’re showing how to wire up a telegraph between your room and the barn and how to make Leyden jars.

Seibel: That brings me to another of my standard questions: do you, as a programmer, think of yourself as a scientist or an engineer or an artist or a craftsman or something else?

Zawinski: Well, definitely not a scientist or engineer because those have very formal connotations. I don’t do a lot of math; I don’t draw blueprints; I don’t prove things. I guess somewhere between craftsman and artist, depending on what the project is. I write a lot of screen savers—that’s not craftsman; that’s making pretty pictures. Somewhere in that area.

Seibel: Do you feel like you taught yourself computer science or did you just learn to program?

Zawinski: Well, I certainly picked up a bunch of computer science over the years. But learning to program was the goal. Making the machine do something was the goal and the computer-science side of it was a means to an end.