Bad programmers are often comfortable within the constraints of their narrow skill sets.This quote is so true. I often see programmers who started their careers off in COBOL, or FORTRAN, and apply the same skills to a language like Java, or Ruby. The top down approach to programming is evident in everything they do. OO concepts are limited to a class with thousands of lines of code often codified in one giant method.
They have very superficial knowledge of their problem domain, and their tools.A great example is using a great IDE like NetBeans along with JPA. That is the project they are working on has JPA. They can not get the ORM concept down, and instead write SQL to get what they from the database. Finally, they use their native queries inside JPA, and struggle to map the results to objects. Rather than take advantage of the IDE to generate the code for them, or learn a little more about JPA, they solve the problem with what they "know" and complain that JPA, or the tooling is bad.
... they view the quest for alternative ways of doing things as the kind of folderol that's more of a personal programming indulgence than a productive activity.The corollary to this is that they will spend hours trying to undermine the new technology to find new ways of doing the same thing with which they are familiar. It is the snake swallowing its own tail.
What they don't appreciate, though, is just how much work and effort they shift to the rest of the team. And if this information is communicated to them, they're initially surprised, then incredulous, but ultimately unfazed.Been there done that... and this is so true. I am usually the bad guy. Imagine that.
Personally, I believe that the only way to sufficiently communicate their shortcomings to them and make their cost clear to management is through the diligent use of code reviews.This is true, but I think it is important to stress that a code review should be done on all code which is part of a multi-developer, and multinational project. However, I think that doing the code review in a blind code review with their peers will stress the point to them initially that the quality of their work is not up to par. If the blind review fails, then a public review where they defend their design decisions should be done. This gives them a chance to reform, and puts them on notice.
Andrew seems to believe from his article that they are already long gone, and should be ultimately fired. I want to believe that people can make changes to become productive. It is fundamental to me to believe in people. However, in practice it has ultimately resulted in the bad programmer being fired, or moving on to another company to continue their damaging activities.