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.
3 comments :
I find it extremely disturbing that this person's knee-jerk reaction is the desire to fire someone. One would hope that this type of caveman management mentality would have disappeared long ago. I pity anyone who has to work with them or under their 'supervision'. Documented company policy along with timely feedback and reviews would have a much greater benefit than the approach this toxic manager wants to take. Toxic managers are the greatest threat to any organization and as such organizations must have policies in place to rid themselves of them. Nothing can lower the morale of well intentioned workers as acutely as the presence of a toxic manager.
I agree Jeff. I am a Boy Scout Leader, and part my belief structure is being loyal, helpful, friendly, and kind.
I think that if you took the time to hire someone, you should be loyal and give them the benefit of the doubt to change.
You must be willing to help them without being demeaning. This will hopefully make them improve, and it will also move you spiritually. You will likely feel better because you attempted to make a difference.
I have found as I noted in my original post, they often leave before getting fired to propagate their inadequacy without internal change.
I was added to a project a couple years back because it was in trouble. The programmers where from a mainframe COBOL era and trying to make a J2EE based web application.
Interestingly when I tried to introduce ideas like code reviews and even the idea that programmers should compile at least before the release data. Response from management was that we didn't need to do this with other languages so there must be problems with Java, certainly it was the wrong choice.
Post a Comment