Swoopers and Bashers and Writers and ProgrammersPosted: April 23, 2009
It’s funny that Bruce Eckel posted on Artima yesterday about how programming is analogous to writing. I’ve thought that for a long time, and Eric Roberts, who developed the introductory CS curriculum at Stanford (and is just an amazing teacher in general) liked to point out to incoming freshmen that success in those classes was more closely correlated with SAT verbal test scores than with SAT math scores. But what I’d been meaning to write about was a bit of a tangent to that: it wasn’t about how programming is like writing, but rather about how people have wildly different writing styles, which I think everyone accepts (no one expects Dan Brown to compose a novel the same way as Salmon Rushdie or Haruki Murakami), yet people often expect that there’s One True Way to write quality software. Method X works for them, so if it doesn’t work as well for you, it must be because you’re doing something wrong.
But the truth of the matter is that programmers program differently, just like writers write differently. One of my favorite discussions of writing comes from Kurt Vonnegut. In his novel Timequake, he says there are two types of writers:
Tellers of stories with ink on paper, not that they matter any more, have been either swoopers or bashers. Swoopers write a story quickly, higgledy-piggledy, crinkum-crankum, any which way. Then they go over it again painstakingly, fixing everything that is just plain awful or doesn’t work. Bashers go one sentence at a time, getting it exactly right before they go on to the next one. When they’re done they’re done.
It’s an over-generalization, but as over-generalizations go it’s a pretty brilliant one. Personally I fall into the swooper category; in fact, I’m even more extreme in that I’ll often rewrite from whole cloth large sections or even entire essays (or e-mails, or term papers). I’ve found that I need to get something down in some roughly-complete form simply in order to collect my thoughts, so I simply couldn’t bash out something perfect one sentence at a time no matter how much I wanted to. When English teachers in grade school made us write outlines for an essay, I’d write my outline after I was done with the paper, because that was the only way the two would line up.
Interestingly (to me, at least), I’ve found that I’m most productive when I program the same way. For a long time, I felt kind of bad that I didn’t enjoy doing rigorous test-driven development; it seemed like TDD was some kind of ideal of well-constructed code and if I was just a little more disciplined, I’d fully TDD everything and my code would be flawless as a result. But in reality, that style is just sub-optimal for me. Just like when I write, I need to sketch something out in order to really see where I’m going. So my development methodology these days is often to start with a brutal, hacked-up end-to-end spike of a feature, write some end-to-end tests, and then start building it sideways, back-filling more targeted tests as I go and always keeping it close to some known-good state. If I try to throw that spike away and start over with TDD, or if I don’t do that spike at all, I go slower and produce code that’s harder to read or modify later.
My point is that there is no one right way to develop; what works well for one person won’t work so well for another person. Most developers, I think, would admit that different methodologies and techniques and tools are appropriate for different problem spaces; one-person throwaway projects are obviously a different deal from 100-person projects where the code needs to live for decades. But even within the same problem space, people are just different, and one programming methodology or style doesn’t fit all.
As a developer, it’s your responsibility to figure out what works for you, and that requires some experimentation and often the willingness to try out something that feels horribly awkward and unfamiliar at first. Unfortunately, it’s often hard to know if you’re giving up too early or if something really just isn’t going to work for you. So by all means, read all you can about TDD, BDD, pair programming, rapid prototyping, getting real, modeling, or just go out there and start hacking. Try a method out, ask people who like it, take what works and leave what doesn’t, and find the style that leads to you doing your best work.
And if you ever happen to find yourself in a position of authority, one of the worst things you can do is require everyone to try to program the same way just because it’s the way that works for you or that works for some guy in a book you read. Give people the freedom to do their best work and, surprise surprise, they will.