Zawinski: Well, I think you want to arrange for there to be no morethan three or four people working really closely together on a day-todaybasis. Then that can scale up a lot. Say you’ve got a project whereyou can divide it up into twenty-five really distinct modules. Well, youcan 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 thinkthere’s a whole lot of limit to how big you can scale that. Eventually itjust starts looking like multiple projects instead of like one project.

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

Zawinski: Well, there’s got to be agreement about what the interfacebetween 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 toagree 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 interactionbetween modules be easy is to just make it be really simple. Makethere be fewer ways for that to go wrong.

And what lines you divide on depends entirely on a project. Withsome kind of web app you’ve probably got the UI and you’ve got yourdatabase and the part that runs on the server and the part that runson the machine behind the server. And if it’s a desktop application it’ssimilar division of labor. There’s file formats and GUI and basiccommand structure.

Seibel: How do you recognize talent?

Zawinski: That I don’t know. I’ve never really been the person whohad to hire people. And when I’ve been involved in interviews I’vealways just felt like I had no idea. I can tell from the interview whetherI’d get along with this person, but I can’t tell whether they’re any goodor 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 abig fan of C++ templates—keep me away from that guy. But thatmight just be a snap judgment on my part. Maybe in the contextthey’ve used them, they actually work fine. Certainly with the folks I’veworked with, ability to argue their point was important because we allended up being a pretty argumentative bunch. With that environment,that helped a lot. That certainly doesn’t have anything to do withprogramming 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 sopeople owned different parts of the software. Some people thinkthat’s really important. Other folks say it’s better for a team tocollectively own all the code. Do you have an opinion on that?

Zawinski: I’ve done it both ways. They both have their merits. Theidea that everyone should own all the code, I don’t think is reallypractical because there’s going to be too much of it. People are goingto have to specialize; you need an expert sometimes. It’s just alwaysgoing to work out that way. There’s always going to be the codeyou’re familiar with because you happened to write more of thatmodule than some other guy did. Or there’s just going to be parts thatresonate with you more. It’s certainly good for other people to havetheir hands in it, if only because you’re not going to be maintaining ityourself forever. It’s going to have to be handed off to someone elsefor one reason or another. And for that knowledge to be spreadaround is good. But it’s also good to have someone to blame. Ifeverybody is responsible for it then there’s no one to put their footdown.

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 Emacsthat were written by other people. Those people didn’t really workfor me but it was a little bit like management. And a lot of thosepeople were definitely less experienced and the way that worked outwell was they were doing their favorite thing and I was basically givingthem 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 thismodule in the thing that I’m going to ship, I’m going to haverequirements about it. Does the damn thing work is really the bottomline there. So I would give them advice on, “I think you’re going tohave better luck if you try it this rather than this way.” But I wanted itto work and I wanted to not have to be the one to write it. If theywanted to go do it in some crazy way but it worked, that was OKbecause that gave me point two: I didn’t have to write it. But mostlythe feedback I was giving them was just, does it work and does it makesense.

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

Zawinski: I guess the most important thing is they’d recognize whenit was time to level up. When I went to work for Fahlman I was givensome silly little busy work. And eventually got given tasks that were alittle 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 alittle more nurturing?

Zawinski: Well, he wasn’t completely a cave man. He would actuallytell me things, too. I know I ended up doing a lot of reading of codeand asking questions. I think one thing that’s really important is to notbe afraid of your ignorance. If you don’t understand how somethingworks, ask someone who does. A lot of people are skittish about that.And that doesn’t help anybody. Not knowing something doesn’t meanyou’re dumb—it just means you don’t know it yet.

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

Zawinski: Yeah. Just poking around—“I wonder how that works.”The impulse to take things apart is a big part of what gets people intothis 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 atelegraph tapper that I made out of a tin can. When I was little I hadthese old books I got at a garage sale or something, like Boy’s OwnScience Book from the ’30s, and I remember getting a really big kick outof those. That was really hacker culture in the ’20s and ’30s wherethey’re showing how to wire up a telegraph between your room andthe 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 anartist or a craftsman or something else?

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

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

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