Fitzpatrick: Generally I would bring up an editor and just write notes withpseudocode for the schema. After it got good, I would make up a realschema and then I would copy-paste it in just to make sure that “createtable” works. Once I got that all going, I’d actually go implement it. I alwaysstart with a spec.txt first.

Seibel: After you write a bunch of code do you ever discover that youreally need to reconsider your original plan?

Fitzpatrick: Sometimes. But I’ve started with the hard bits or the parts Iwas unsure of, and tried to implement those parts first. I try not to put offanything hard or surprising to the end; I enjoy doing the hard things first.The projects that I never finish—my friends give me shit that it’s a wholebunch—it’s because I did the hard part and I learned what I wanted to learnand I never got around to doing the boring stuff.

Seibel: Do you have any advice for self-taught programmers?

Fitzpatrick: Always try to do something a little harder, that’s outside yourreach. Read code. I heard this a lot, but it didn’t really sink in until later.There were a number of years when I wrote a lot of code and never readanyone else’s. Then I get on the Internet and there’s all this open sourcecode I could contribute to but I was just scared shitless that if it wasn’t mycode and the whole design wasn’t in my head, that I couldn’t dive in andunderstand it.

Then I was sending in patches to Gaim, the GTK instant-messenger thing,and I was digging around that code and I just saw the whole design. Justseeing parts of it, I understood. I realized, after looking at other people’scode, that it wasn’t that I memorized all my own code; I was starting to seepatterns. I would see their code and I was like, “Oh, OK. I understand thestructure that they’re going with.”

Then I really enjoyed reading code, because whenever I didn’t understandsome pattern, I was like, “Wait, why the fuck did they do it like this?” and Iwould look around more, and I’d be like, “Wow, that is a really clever wayto do this. I see how that pays off.” I would’ve done that earlier but I wasafraid to do it because I was thinking that if it wasn’t my code, I wouldn’tunderstand it.

Seibel: And how do you tackle reading other people’s code? For starters,do you read code just to see how it works overall, or do you always go inwith some change you want to make?

Fitzpatrick: Generally I wanted to change something. Or if you reallyrespect some programmer, go read some of their code. Maybe that’ll makeyou realize that they’re mortal and they’re not really someone you shouldbe idolizing. Or you learn something about their code.

Seibel: So say you’ve got a change you want to make; how do you tackle it?

Fitzpatrick: First step, take a virgin tarball or check out from svn, and tryto get the damn thing to build. Get over that hurdle. That tends to be thehugest hurdle for most people—dependencies in the build system or they’reassuming this library is installed. I almost wish that these large projects justcame with a virtual machine that was the build environment.

Seibel: You mean like a VMware virtual machine?

Fitzpatrick: Yeah, so if you just want to get into hacking on it reallyquickly, here’s all the dependencies. People’s connections are getting quickenough. That’s totally viable.

Anyway, once you have one clean, working build, kill it, and just make onedamn change. Change the title bar to say, “Brad says, ‘Hello world.’” Changesomething. Even if everything’s ugly, just start making changes.

Then send out patches along the way. I find that’s the best way to start aconversation. If you get on a mailing list and you’re like, “Hey, I want to adda feature X,” the maintainer is probably going to be like, “Oh fuck, I’m sobusy. Go away. I hate feature X.” But if you come to them and you’re like,“I want to add feature X. I was thinking something like the attached patch,”which is totally wrong but you say, “But I think it’s totally wrong. I’mthinking the right way might be to do X,” which is some more complex way,generally they’ll be like, “Holy crap, they tried, and look, they totally did itthe wrong way.”

Maybe that pains the maintainer. They’re like, “Oh man, I can’t believe theywent through all that effort to do it. It’s so easy to do it the right way.” Or,“Oh, wow, they did all this work in the wrong direction. I hope they don’tgo in that direction any more.” And then they reply.

That’s always the best way to start a conversation. Even at Google, that’sthe way I start a lot of conversations to a team I don’t know. When I fix abug in their product the first thing I do is send them a patch in the mail andjust say, “What do you guys think of this?” Or on the internal code-reviewtool I’d be like, “Here is a review. What do you think?” They could just say,“Fuck no, that’s totally the wrong fix.”

Seibel: Do you still read code for fun, as opposed to reading it because youneed to work with it?

Fitzpatrick: Sometimes. I checked out Android source code for no realreason. The same with Chrome; when it went open source, I mirrored therepo and just looked around. I did the same thing with Firefox and OpenOffice. Some program you’ve been using and all of a sudden you have accessand you might as well look.

Seibel: Programs like that, the code base is pretty huge. When you look atsomething like that for fun, how deeply do you get into it?

Fitzpatrick: Generally, I’ll just pipe find into less and try to understandthe directory structure. Then either something grabs my eye or I don’tunderstand what something is. So I pick a random file and get a feel for it.Then I bounce around and wander aimlessly until I’m bored and then pick anew random spot to jump in.

A lot of times, I’ll work on building it in parallel with reading it becausethey’re very parallelizable tasks, especially if it’s hard to build. By the timeit’s finally built, then I can start tweaking it if I want to.

Seibel: So when you read good code it either fits into patterns that youalready understand, or you’d discover new patterns. But not all code isgood. What are the first warning signs of bad code?

Fitzpatrick: Well, I’m particularly snooty now, having worked at Googlewith really strict style guidelines in all languages. On our top six or sevenlanguages, there’s a really strict style guide that says, “This is how we lay outour code. This is how we name variables. This is how we do spacing andindentation, and these patterns and conventions you use, and this is howyou declare a static field.”

We’ve started putting these online too, just as a reference for externalcontributors contributing to our projects. We wanted to have adocumented policy so we don’t just say, “We don’t like your style.”

Now when I work on projects in C, the first thing I do is add a style guide.Once a project is mature and has a lot of people hacking on it, they’ll have astyle guide. It’s not even always written, but the programmers just respectthe style of code written already. Maybe they don’t like the brace style, butfuck it, it’s more important to have it consistent within a file, within aproject, than to do it your favorite way.

Seibel: Do you ever do any pair programming?

Fitzpatrick: I think it’s pretty fun. It’s good for lots of things. Sometimesyou just need to think and want to be left alone. I don’t subscribe to it allthe time, but it’s definitely fun.

I start too many projects. I finish them because I have guilt if I don’t finishthem, but I definitely context-switch way too often and I’m spread too thin.This is why I really need pair programming—it forces me to sit down forthree solid hours, or even two or one solid hour, and work on one thingwith somebody else, and they force me to not be bored. If I hit a boredpatch, they’re like, “Come on. We’ve got to do it,” and we finish.