A Good Programmer: Why You Need to Avoid Being One

I’ve worked with what I consider to be good software programmers but are they really good programmers? What makes them so good? (and maybe, are they just average?)

I recently read a blog post by Mark Pearl titled “Programming, a Subset of Writing.” As much as I agree with the underlying message of this post, something really struck me when I read the following paragraph:

“This is where I draw the biggest parallel between the two. A good programmer is one that programs in a clean, understandable way - all unnecessary complexities are removed from the code. The really good programmers I have worked with have this mantra of code it, then refactor and refactor some more.”

It is true you become better with practice - just like with all life skills. But what else do you need to do besides refactor and then refactor some more?

Another area that helps us perfect our craft is simply being open-minded of other important factors that go into programming. Unit testing, exception handling or even communication skills are all important. If overlooked, ignoring these elements can lead to overconfidence, possibly making you a “confidently wrong person.”

I often caution the mantra of encouraging all programmers to become “good programmers” without considering realistic pragmatism, and following religious conformance to software practices.  I’ve worked with “good programmers,” and I’m sometimes left thinking they are just “confidently wrong programmers;” although, to be fair, some were indeed very good.

I agree with my former colleague, Russell Politzky, in saying that:

“They [confidently wrong programmers] tend to be dogmatic, intolerant and impractical.  In our line of business, that can result in inappropriate and self-defeating design decision.”

These are the programmers who may be caught out making statements such as:

• All tests must be unit tests
• 100% code coverage is a desirable goal regardless of the value of the tests required to achieve it
• All mocks/stubs etc. used in your unit tests must be built using a mocking library
• All applications must be built around the DDD paradigm, regardless of their purpose
• All applications using a database must use an ORM to round out their data access layer
• Applications that don't use an ORM are suboptimal and hard to maintain
• All comments in code are undesirable because they're indicative of code that hasn't been written well enough to sufficiently express intent and it's always possible to express the detail of your domain in the program code itself
• Any documentation you produce, for your design, is necessarily always out of date and less than useless
• The code is the only documentation you'll ever need
• The code is the only model you'll ever need
• It's impossible to do good top-down design; this approach will always fail and those espousing it simply haven't seen the light, as yet, but eventually they'll all succumb to the superiority of "evolutionary design", meaning TDD
• You can't write good software in any paradigm other than Object Orientation because only OO has ways of decomposing complexity

Do you know this programmer? If so, what do you think of their performance? Experience has shown that this kind of dichotomous thinking, whereby something is either all good or all bad, is illogical.

Applying good levels of pragmatism and sensible reasoning is also what makes you a good programmer.  Perfecting your craft and enhancing your skill is good, but through this process we should clearly understand the bounds, scope, cost and context of our reasoning. The ability to take all this into reasonable context requires maturity and such maturity is important to being a “good programmer.”

Along with lots of practice, of course.