Monthly Archives: June 2012

Traits of a bad programmer

A bad programmer is somebody who I personally consider a liability to any team. This category of programmers have the potential to bring down a project and even a full team. It is always better to either notify them of their deficiencies so that they improve or to ultimately save the team by removing them. I tend to identify a bad programmer from their following traits:

Lack of curiosity
If a programmer is not curious about the API and considers superficial knowledge as sufficient then it is the first warning bell that this particular person will have a mediocre knowledge and as a result mediocre performance.

Difficult to Understand Code
If the code a programmer writes is bug laden and the code itself is messy and unnecessarily large then you are dealing with a bad programmer.

Lack of Depth in Knowledge
Superficial knowledge about a topic is a dangerous attribute of a bad programmer. This can bring less than optimized behavior in the software. This superficial knowledge can range from programming API, tools of trade and even the problem domain itself.

Unwillingness to do defensive coding
A programmer has to consider lots of scenarios which can be documented as test cases or even unit tests. If a programmer only considers a general scenario and fails to accommodate the not so general scenario then the result is often a bug laden software.

Unwillingness to comment or improve code
A commented source code is an asset and an un-commented source code is a liability.  A programmer rarely works alone and if the source code written by them is not documented then it doubles up the amount of time required to fix their code. If a programmer never has time to comment the code or even simplify the code by writing smaller pieces of a large piece of code then this is a dead give away of a bad programmer.

Aversion to feedback
Any programmer worth his salt should be open to feedback from his peers. If a programmer is unfazed by negative feedback and doesn’t consider his responsibility to fix his code as a result of feedback then he is a bad programmer. A programmer should learn to make decisions based on experience and also the feedback received from peers and customers.