Seibeclass="underline" Do you think programmers are overenamored of new things? New languages, new tools, new whatever?
Fitzpatrick: They might be. I don’t know if that’s desperation in hoping the new thing doesn’t suck, like the new programming language does what we all want. But users are the same way. Users always like to get the one with the higher version number even if it sucks more.
I don’t know if programmers are statistically different than humans in general. New must be better. Which is not always the case, but people hope it is. They want it to be.
I remember talking to my dentist a while back and she was going on and on about, like, the advances in dentistry over the last, like, five years, and she was really excited about them.
Seibeclass="underline" A lot of being a modern programmer requires finding the right pieces that you need to use and understanding them just well enough to use them. How do you deal with that?
Fitzpatrick: CPAN has everything. There are 14 ID3 parsers. Pick one.
Seibeclass="underline" So that, in a way, is the problem facing the modern programmer—there are 14 of them. How do you pick?
Fitzpatrick: Google search—which one’s highest? Which one do people tend to like? And knowing people. I got so much more involved in the open source community once I started going to all these conferences because then I would meet people and see who was respected, and who was cool.
Then I would see their code: I remember that guy. He was awesome. He was fun, friendly, and attentive, and he really cared about his code. He was really passionate when people complained about it. I’m going to use that one because if I find any bugs, I know he’ll be crazy about fixing them. As opposed to the grumpy guy who maybe writes great code, but he’s grumpy and not fun to interact with if you have a question or a bug. So you pick maintainers you trust or respect.
Seibeclass="underline" Then is there any trick to quickly figuring out whether something’s going to suit your needs?
Fitzpatrick: I just start. I don’t plug it right into my code—first I write a test program that uses the couple functions I know I’m going to need, make sure they work. Or write a unit test for just that library on just the data I plan to use with it. A lot of libraries out there don’t even have their own tests. Even if it does, maybe you read the doc and you don’t really trust that it does what it says it does, or the doc wasn’t clear about how it behaves. So I write my own tests for the shit I care about. I figure since I’m going to have to write something to learn the library anyway, my first Hello, World program might as well be a unit test against it.
Seibeclass="underline" What about the actual tools you use—you’re still an Emacs user, right?
Fitzpatrick: I’m still an Emacs user. I wish I were better at Emacs. But I know all the keystrokes but I don’t really customize it much. I steal other people’s customizations and I can kind of read it. But I find myself getting annoyed by something and saying, “I should go write some Elisp to bind it to a key.” And then I don’t.
Steve Yegge is working on project to basically replace all of Elisp with JavaScript. So I keep saying, I’ll wait for him to do that so I don’t have to learn another language. I’ll just write it in JavaScript. I don’t mind JavaScript as a language. It’s browsers that suck. At Google I write a lot of stuff in JavaScript that I then embed in Java and C++. I figure JavaScript is a good embedding language.
Seibeclass="underline" Are there any tools that you are forced to use regularly that you just hate? Other than your whole desktop?
Fitzpatrick: Yeah, the whole desktop. There are a whole lot of things on my desktop. All these browsers are always hanging and crashing and using tons of memory. My whole operating system hanging. My coworkers try to tell me—if they see me doing something in Emacs—that Eclipse or IntelliJ does it for them automatically. So every six months I try out one of them, Eclipse or IntelliJ. And the damn thing just sits there spinning forever, consuming memory and maybe crashes in the middle of me typing or can’t keep up with me typing. Come on—syntax-highlight in the background or compile in a different thread. Why are you blocking my typing to do this? OK, I’ll try it again in six months, guys. So I’m glad I’m not forced to use that. I should really get better at Emacs, though.
My learning curve is, I learn something pretty rapidly until I get to this point where I’m pretty productive and good enough. Then I kind of plateau at like maybe 90 percent or 80 percent, where I’m productive and I don’t have to look things up and I’m happy. And then it slowly gets better after that. It’s only after I’m super comfortable with something that I’m like, “I’m going to go dig around the docs for this language—the man pages—and learn every nook and cranny.”
Seibeclass="underline" Is that maybe wise these days? There are so many things you could learn. You could spend forever just learning how to use your editor, and how much software would you write then?
Fitzpatrick: Yeah, but I’ve always found—at least for your editor—it always pays off. Whenever I learn something, it pays off within, I don’t know, a week or two. Whenever I write a stupid little shell script in my bin directory, or a little Perl script, or something to automate my life, it always pays off.
Seibeclass="underline" So you’ve never gotten trapped in the pit of endless toolsmithing?
Fitzpatrick: Nah. I tend to do it for a purpose. I definitely know people who are just always working on their personal tools and never get anything done. I can go a little bit more in that direction and be safe, though.
Seibeclass="underline" What do you think is the most important skill for a programmer to have?
Fitzpatrick: Thinking like a scientist; changing one thing at a time. Patience and trying to understand the root cause of things. Especially when you’re debugging something or designing something that’s not quite working. I’ve seen young programmers say, “Oh, shit, it doesn’t work,” and then rewrite it all. Stop. Try to figure out what’s going on. Learn how to write things incrementally so that at each stage you could verify it.
Seibeclass="underline" Is there anything that you did specifically to improve your skill as a programmer?
Fitzpatrick: Sometimes I’ll go out of my way to write something in a language that I would rather not write it in—and I know it’ll take me longer to write in that language—because I know I’ll be better in the end. Like when I got to Google, there were a lot of times where I was writing one-off things and I’d go to write it in Perl. Then I’d be like, “Ah, no, I should write this in Python.” Now I write tons of Python and it doesn’t bother me—I barely have to look things up. Perlbal was originally written in C# just to learn that.
Seibeclass="underline" And are there skills apart from programming itself that you think would-be programmers should develop?
Fitzpatrick: There’s communication, but I’m not sure that’s something you can really practice. Deal with people on mailing lists a lot. Written communication style goes a long way. But that’s a general life thing, right? There was some study about who was successful after high school. Was it the smart kids or the social kids? It turned out that it was the social kids who ended up making all the money in life, not the people with the good grades. I thought that was interesting.
Seibeclass="underline" That seems to be a bit of a change from the past. It used to be programmers could be gnomes hiding in an office. These days it’s all mailing lists and collaboration.
Fitzpatrick: Well, at the places I’ve worked, either on open source or at companies, everyone depends on each other. The motivating factor is, “I’m going to write this code because I know you’re going to be needing it in two weeks or I’m going to be needing yours in two weeks.” There’s always a human level.