Only Good Developers Write Bad Code

The first developer I ever worked with was named Fred.  I was only about 17 years old at the time, and had gotten a job working at an engineering firm after school. I did a lot of grunt work type things: assembled documentation binders, removed all old parts books out of the library, organized & filed software for the developers. (There used to be hanging folders that had sleeves for 5.25″ and 3.5″ floppies, so you could keep all your software in a filing cabinet.)  But sometimes I’d get a break from doing the grunt work and would get to work with Fred. Granted, I don’t think I ever wrote code with Fred, but I’d work in his office, or I’d have some small Access database that I’d be working on and Fred would be kind enough to answer questions.

If you asked Fred about some piece of software that he wrote, he’d tell you he looked it up in some book, or saw some code in a magazine article and he basically just copied it and it worked. The last thing Fred would do is tell you how great his code was. In fact, I can honestly say I never once remember him saying anything like that.  After I’d worked with him for a whlie, I found out not only was Fred writing software for the company I was at, but before that, he was writing code for the Cray super computers, he obviously knew his stuff.

Working with Fred has kind of stuck in my mind for the last 15-20 years, because he taught me something.  He taught me that good software developers write a lot of bad code. They might even write an disproportionate amount of bad code.  I’ve worked with developers who didn’t seem to have the first clue about the project they were working on, didn’t understand the business, didn’t understand the customer, yet they never wrote bad code. In contrast, I’ve worked with developers (like Fred) who were way smarter than me, writing code that was much more complex than anything I’ve written (or probably will write) and yet their code was completely useless.

The best way to find out if someone has written bad code is to ask them.  A lot of people will tell you “Oh yeah, my first couple projects were bad. I used to use GOTO statements back when I first started.”  And that’s good, that they would be embarrased by the first code they wrote. (The first commercial app I wrote had one reviewer saying that the Help file looked like it had been done by a Kindergartner.)  But for most of us, that first app was many years ago, probably more than a decade.  Was that the last bad code that was written?

Good developers will look at the code that they wrote last year, and tell you how worthless it is.  There’s some area that’s hard to maintain, or there was something they didn’t factor in, and if they had it all over, they’d write it differently.

In contrast, the bad developers that I’ve worked with might say things like “Yeah, I couldn’t think of any other way to write it.” Or “I knew it wasn’t the best approach, but …”  

The difference there is subtle but important.  Most bad developers don’t reflect.  If you were to bring up code that they wrote 6 months ago, they’d offer you excuses, they’d admit it wasn’t perfect, but it wouldn’t annoy them looking at their old code.  Conversely, most good developers not only know that the code is bad, but they’ve been thinking about that code for some time.  Probably not constantly, but anytime they do some sort of work (for example, a repository class) they think back to the lessons learned from the last 3 times they’ve gone down this road, and they write it better.

Good developers cranked out a bunch of bad code las year, last month, last week, yesterday. And I hope that I crank out as much bad code as they do.