How to Tell if You’re a Bad Programmer

By Deane Barker on April 4, 2009

Signs that you are a bad programmer: This is a good analysis of your general competency as a programmer. For example, you are a bad programmer if you suffer from the following:

  • Inability to reason about code

  • Poor understanding of the language’s programming model

  • Deficient research skills / Chronically poor knowledge of the platform’s features

The article breaks these down further, for instance:

  1. Re-inventing or laboring without basic mechanisms that are built-into the language, such as events-and-handlers or regular expressions

  2. Re-inventing classes and functions that are built-into the framework (eg: timers, collections, sorting and searching algorithms)

  3. “Email me teh code, plz” messages posted to help forums

  4. “Roundabout code” that accomplishes in many instructions what could be done with far fewer (eg: rounding a number by converting a decimal into a formatted string, then converting the string back into a decimal)

  5. Persistently using old-fashioned techniques even when new techniques are better in those situations (eg: still writes named delegate functions instead of using lambda expressions for one-offs)

  6. Having a stark “comfort zone”, and going to extreme lengths to solve complex problems with primitives

There’s some brutal honesty there, even if it does get a little snarky at the end.

Not all of this is gospel, however, since a lot of this is all opinion. The comments in the Reddit thread get medieval on some it. They’re worth reading just for a good dose of dissent.

Sign’s you’re a bad programmer: Everyone hates your software and nobody finds it useful. Or nobody uses your software because of your inability to ship anything.

Really, thats it, as far as I’m concerned.

All these people pontificating about how to spot a bad programmer should first be required to publish a list of the best software they have written and let us take a call on whether or not to follow their advice.