You're a Bad Programmer. Embrace It.

How many developers think they're good programmers? We're not. We're all fairly bad at what we do. We can't remember all the methods our code needs to call, so we use autocompleting IDEs to remind us. And the languages we've spent years, in some cases decades, learning? We can't even type the syntax properly, so we have compilers that check and correct it for us.

Don't even get me started on the correctness of the logic in the code... I'm looking at a chart that shows failure rates for software projects. "Small" projects (about a year for 8 people) have a 46 percent success rate. That's almost half. Any longer project just plummets down to a 2 percent rate for projects costing 10 million or more. In other words, our projects nearly always fail.

We constantly write code that breaks existing features. We add features in ways that won't scale. We create features nobody wants.

In short, as an industry, we all stink.

You can fight this. You can summon your "inner lawyer," the voice in your head that always defends you and tells you how great you are. You can take the typical developer's attitude that "it's always someone else's fault." My seven year old does that a lot, too.

Or you can embrace it. Admit it, humans aren't good at programming. It's a task that requires extraordinary complexity and detail from brains that don't work that way. It's not how we tick. We might enjoy programming, we might get "in the zone"and lose track of time, we might spend our nights and weekends writing code for fun, but after years of practice, we still need these crutches to prop us up.

Once you've embraced this bitter reality, you can start to move forward. Once you've admitted to yourself that you're a bad programmer, you can stop all the silly posturing and pretending that you're great, and you can look around and find the best possible tools to help you look smarter than you are.

If we know that anytime we touch code, we'll probably break something, then we can look around to see what catches functional breaks in code as quickly as possible: a good continuous integration system combined with a good automated test suite.

Creating a good test suite is a lot like working out, though, since we rarely take the time to create a solid, workable test automation strategy. Something like it is a great place to start.

If you recognize that we all write the same fundamentally bad code that everyone else does, then you can look around at static code analysis tools.  If you're writing Java, I highly recommend FindBugs.

These tools flag common mistakes. And I mean really common mistakes. Things you can't believe you actually do. But somehow we do nearly every day.

I've met many development teams who didn't think they needed static code anaylsis. But I've never run a tool like FindBugs without finding a real (read: not theoretical) problem in production code. They hadn't learned to embrace their badness yet. 

If you don't know what code is being exercised by your manual or automated test cases, look at a code coverage tool. Cobertura is my favorite, but I'm a bit biased as I had a hand in getting it started. 

If your team is constantly getting interrupted and pulled in different directions, try tackling smaller units of work. It's easier to push back on an "emergency" change if you can ask them to wait for only two or three days. If you're on a two month task, they won't wait.

Admit that you're a sorry sysadmin as well and script your deployments. Tools like Rake and Capistrano are extremely powerful tools that can completely automate your development, testing, and even production deployments. Once it's scripted, it becomes incredibly easy to duplicate. You'll be amazed at how much time this one will save you.

Of course, if you've automated your code deployments, it'd be silly to keep typing in SQL commands by hand. Ruby on Rail's database migrations may have been the early leaders in this area, but there are plenty of other tools available today. One prominent tool is Liquibase. 

How about customer interaction? Yes, we're bad at that too. (Ever used the phrase "stupid users"?) Try moving your specifications into a more precise, and even executable format. DSLs (Domain Specific Languages) provide a wide variety of ways to engage a customer with a precise, but understandable, langage.

There are a great many tools we can use to make ourselves look smarter than we are. Once we stop fighting against the need for the tools, and embrace them, we start looking like we're pretty good developers. I won't tell anyone you stink if you don't tell them about me. ;)

Further reading

The Reality of Bad Programmers

Article originally published on Sept. 29, 2010