Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
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:
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:
These are the programmers who may be caught out making statements such as:
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.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.