Peter Seibel - Coders at Work - Reflections on the craft of programming

This is not teaching people to program; this is teaching people where the semicolon goes. That seems like the kind of thing that’s going to scare people away from it more than anything, because that’s not the interesting part. Not even to someone who knows what they’re doing.

There was another book—what was it called?—about debugging, written by someone from Microsoft. It was about how to use asserts effectively. I remember thinking that was a really good book, not because I learned anything from it, but because it was the book you wish your idiot coworker had read.

Then there was another book that everybody thought was the greatest thing ever in that same period— Design Patterns —which I just thought was crap. It was just like, programming via cut and paste. Rather than thinking through your task you looked through the recipe book and found something that maybe, kinda, sorta felt like it, and then just aped it. That’s not programming; that’s a coloring book. But a lot of people seemed to love it. Then in meetings they’d be tossing around all this terminology they got out of that book. Like, the inverse, reverse, double-back-flip pattern—whatever. Oh, you mean a loop? OK.

Seibel:Is there a key skill programmers must have?

Zawinski:Well, curiosity—taking things apart. Wanting to know what’s going on under the hood. I think that’s really the basis of it. Without that I don’t think you get very far. That’s your primary way of acquiring knowledge. Taking something apart and looking at it is how you learn to build your own. At least for me. I’ve read very few books about computers. My experience has been digging through source code or reference manuals. I’ve got a goal and, alright, to do this I need to know what this thing does and what this thing does. And I’ll just sort of random-walk through that until I find where I’m going.

Seibel:Have you read Knuth’s, The Art of Computer Programming ?

Zawinski:I haven’t. And that’s one of those things where, I really probably should have. But I never did.

Seibel:It’s tough going—you need a lot of math to really grok it.

Zawinski:And I’m not a math person at all.

Seibel:That’s interesting. Lots of programmers come out of mathematics and lots of computer-science theory is very mathematical. So you’re an existence proof that it’s not absolutely necessary. How much math or mathy kind of thinking is necessary to be a good programmer?

Zawinski:Well, it depends on where you draw the line as to what’s mathy and what’s not. Is being good at pattern matching mathy? Having an understanding of orders of magnitude and combinatorics is important at a gut level. But I’m sure I would completely flunk if I had to take a basic intro quiz on that kind of stuff. It’s been so long since I’ve had to do anything formal like that.

Really the only math classes I had were in high school. I had algebra. A little bit of calculus. I wasn’t terribly good at it. I got through it but it didn’t really come naturally to me. I had a physics class in high school where we were doing mechanics and doing labs dragging blocks across sandpaper and stuff like that. I did terribly in that class and felt like an idiot because I actually enjoyed the class. I did the labs really well—the procedure was spot on—and then I just couldn’t do the math.

I’d get an answer that I knew was three orders of magnitude off. I’d show my work—I don’t know what I did wrong. I’d get half credit since the data was collected properly and I cleaned up afterwards. So math was never really my forte.

But I wouldn’t go so far as to say you don’t need that to be a programmer. There’s obviously different kinds of programming. Without people who are not like me none of this would exist. But I’ve always seen much more in common with writing prose than math. It feels like you’re writing a story and you’re trying to express a concept to a very dumb person—the computer—who has a limited vocabulary. You’ve got this concept you want to express and limited tools to express it with. What words do you use and what does your introductory and summary statement look like? That sort of thing.

The issue of taste really fits in there. You can have a piece of text describing something that describes it correctly or it can describe it well, with some flair. And the same thing’s true of programs. It can get the job done or it can also make sense, be put together well.

Seibel:And why does that matter? Is that just for the satisfaction of it or is tasteful code also better in some practical way?

Zawinski:To a large degree, tasteful and maintainable are similar. Or very closely related. One of the things that makes a piece of writing tasteful is if it’s structured in a way that’s easy to grasp. Are the facts loaded up at the front or are they scattered around? If you’re referring back—if you’re flipping through a book, can you figure out where in the book is the thing you kind of remember? “This was somewhere near the middle because that’s where he talked about this thing.” Or is it just scattered all through. And that’s the same sort of thing that goes on with programming a lot.

Seibel:Do you think the kind of people who can be successful at programming has changed?

Zawinski:Certainly these days it’s impossible to just write a program from scratch that doesn’t have any dependencies. The explosion of toolkits and libraries and frameworks and that sort of thing—even the most basic piece of software needs those these days. It’s just exploded. These days, everything’s got to be a web app. And that’s just a whole different way of going about it.

So, if anything, that makes the part of the skill set that is being able to dive into someone else’s code and figure out how to make use of it even more important. “I don’t understand this, so I’m going to write my own” worked better in the past. Whether it was ever a good idea or not, you could do it. It’s much harder to get away with that now.

Seibel:I wonder if the inclination to take things apart and understand everything also needs to be a little more tempered these days. If you try to take apart every piece of code you work with, it’ll never end—these days you’ve got to have a little capacity for saying, “I sort of understand how this works and I’m going to let it go at that until it becomes urgent that I understand it better.”

Zawinski:Yeah. My first instinct, because things work that way, is you’re breeding a generation of programmers who don’t understand anything about efficiency or what’s actually being allocated. When they realize, “Oh, my program’s getting gigantic,” what are they going to do? They’re not going to know where to start. That’s my first instinct because I’m a caveman. Really that probably doesn’t even matter because you’ll just throw more memory at it and it’ll be fine.

Seibel:Or perhaps people will actually learn a more sophisticated view of what all those things mean. Like, maybe it doesn’t really matter whether we allocated six bytes or four bytes here—what matters is whether we’ve sized this thing so it fits in one node of the cluster versus having to spill over onto a second node.

Zawinski:Right, exactly. I think programming has definitely changed in that sense. The things you had to focus on before were different. Before you would focus on counting bytes, and “How big are my objects? Maybe I should do something different here because that array header is really going to add up.” Things like that. No one is ever going to care about that stuff again. Tricks like XORing your forward and back pointers into the same word are voodoo—why would anyone do that; it’s crazy. But there’s this whole different set of skills now that were always around but come more to the front. People who can dig into an API and figure out which parts you need and which parts you don’t, is, I think, one of those important things now.