Zawinski: I know it's kind of a cliché but it comes back to worse is better. If you spend the time to build the perfect framework that's going to do what you want and that's going to carry you from release 1.0 through release 5.0 and everything's going to be great; well guess what: release 1.0 is going to take you three years to ship and your competitor is going to ship their 1.0 in six months and now you're out of the game. You never shipped your 1.0 because someone else ate your lunch.

Your competitor's six-month 1.0 has crap code and they're going to have to rewrite it in two years but, guess what: they can rewrite it because you don't have a job anymore.

Zawinski: Yeah. Maybe there'd be a vague description of the division between library and front end. But probably not. If I was working alone I wouldn't bother with that because that part is just kind of obvious to me. And then the first thing I would do with something like that is either start at the top or at the bottom. So start with either, put a window on the screen that has some buttons on it, and then dig down and start building the stuff that those buttons do. Or you can start at the other side and start writing the thing that parses mailboxes and that saves mailboxes. Either way. or both and meet in the middle.

I find that getting something on the screen as soon as possible really helps focus the problem for me. It helps me decide what to work on next. Because if you're just looking at that big to-do list it's like, eh, I don't know which one I should do—does it matter which one I do? But if there's something you can actually look at, even if it's just the debug output of your mailbox parser, it's like, OK, there! That's something; what's the next direction this needs to go in? OK, instead of just displaying a tree structure, now maybe I should be emitting HTML or something along those lines. Or parsing the headers in a more detailed way. You just look for the next thing to build on from there.

This was one of my first programs—it was something like K equals grab the next char. Then I said if K equals “a”, print “a”; if K is “b”, print “b”. I pretty much did every letter, number, and some punctuation. Then at one point I was like, “Wait, I could just say, 'Print the variable!'” and I replaced 40 lines of code with one. I was like, “Holy shit, that was awesome!” That was some major abstraction for a six-year-old.

Fitzpatrick: Yeah, I worked at Tektronix for a while. Before I had any official job, I got some hosting account. I got kicked off of AOL for writing bots, flooding their chat rooms, and just being annoying. I was scripting the AOL client from another Windows program. I also wrote a bot to flood their online form to send you a CD. I used every variation of my name, because I didn't want their duplicate suppression to only send me one CD, because they had those 100 free hours, or 5,000 free hours. I submitted this form a couple thousand times and for a week or so the postman would be coming with bundles of CDs wrapped up.

My mom was like, “Damn it, Brad, you're going to get in trouble.” I was like, “Eh—their fucking fault, right?” Then one day I get a phone call and I actually picked up the phone, which I normally didn't, and it was someone from AOL. They were just screaming at me. “Stop sending us all these form submissions!” I'm not normally this quick and clever, but I just yelled back, “Why are you sending me all this crap? Every day the postman comes! He's dropping off all these CDs!” They're like, “We're so sorry, sir. It won't happen again.” Then I used all those and I decorated my dorm room in college with them. I actually still have them in a box in the garage. I can't get rid of them because I just remember them being such a good decoration at one point.

Fitzpatrick: I don't mind it. The syntax is terrible and totally inconsistent and the error messages, at least from GCC, are ridiculous. You can get 40 pages of error spew because you forgot some semicolon. But—like anything else—you quickly memorize all the patterns. You don't even read the words; you just see the structure and think, “Oh, yeah, I probably forgot to close the namespace in a header file.” I think the new C++ spec, even though it adds so much complexity, has a lot of stuff that'll make it less painful to type—as far as number of keystrokes. The auto variables and the for loops. It's more like Python style. And the lambdas. It's enough that I could delude myself into thinking I'm writing in Python, even though it's C++.

Seibel: 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.

Seibel: You said earlier that you got into computers because you thought they would make the world a better place.
Crockford: That's my intention.

Seibel: How's that working out?

Crockford: For the most part, we've done pretty good. I think the world is a better place, although it's not always moving forward. Looking at, say, international politics over the last ten years, the consolidation of big media and the corrupting effects of that have not been compensated for by the open network. That's a big disappointment.

Hundreds of thousands of people have died as a direct consequence of that. That's really sad. I would like for the network to be doing a better job so that kind of stuff doesn't happen again. It's not clear yet what transformations to the network have to occur in order to accomplish that. And maybe it'll be fine on its own, but I'm more pessimistic. I think we need to figure out the next leap in order to overcome whatever is not working now.

Eich: [...] But it was definitely painful and it takes too long. As Oscar Wilde said of socialism, “It takes too many evenings.”

Seibel: Speaking of writing intricate code, I've noticed that people who are too smart, in a certain dimension anyway, make the worst code. Because they can actually fit the whole thing in their head they can write these great reams of spaghetti code.

Bloch: I agree with you that people who are both smart enough to cope with enormous complexity and lack empathy with the rest of us may fall prey to that. They think, “I can understand this and I can use it, so it has to be good.”

Seibel: Is there something intrinsic in programming that's always going to draw people with that kind of mentality?

Bloch: Absolutely. We love brainteasers. But we have to temper this love with the knowledge that we're solving real problems for real people. And if we don't do that we are, essentially, whacking off. I think that part of the failure of the first company that I was involved in was due to the fact that we didn't understand that what we were doing wasn't pure engineering.

Armstrong: Well, as an undergraduate some of the courses involved writing programs and I really enjoyed that. And I got to be very good at debugging. If all else failed, I would debug people's programs. The standard debugging was one beer. Then it would go up—a two-beer problem or a three-beer problem or something like that.

Seibel: That was in terms of how many beers they had to buy you when you debugged their program?

Armstrong: Yeah, when I fixed their program. I used to read programs and think, “Why are they writing it this way; this is very complicated,” and I'd just rewrite them to simplify them. It used to strike me as strange that people wrote complicated programs. I could see how to do things in a few lines and they'd written tens of lines and I'd sort of wonder why they didn't see the simple way. I got quite good at that.