Monday, October 12, 2009

On Teachability in Team Development

EDIT: Note that the terms "architect" and "developer" below are used loosely. This post deals most directly with the teachability of a specific team member, whether that team member is an architect, developer, tester, etc. This post assumes that the teacher, regardless of his role, is competent in teaching. The architect/developer dichotomy below is use purely as a convenience to the purpose of the post.

Software craftsmanship is more than just a set of intellectual know-how. Character traits also affect your ability to do the job. The biggest barrier I see to excellent programming is often a lack of teachability. It doesn't matter how smooth the software architecture is; if the developer can't or won't learn the architecture, it's of no use - the architecture will go by the wayside.

So in that vein, here are the top few barriers to teachability that I've seen:

Arrogance - The arrogant developer always has a better way, and his way is never wrong. He'll fail to be teachable, because he already believes he knows it all. According to him, his code is perfect, so he spends most of his time blaming others or outside factors for bugs that show up. He'll never implement an architecture properly, because the architecture, in his opinion, is not as good as he could have made it. Sadly, the arrogant developer was teachable at one point, but his success made him arrogant and he lost his ability to learn.

Laziness - A certain amount of laziness is a wonderful trait for a developer to have. It's this laziness that makes a developer say "There's gotta be a better way". Unbridled laziness, however, ignores the architecture "because it's too much work". It's not that he can't learn it, it's that he doesn't want to, and ugly code ensues.

Ability - Sadly, through no fault of their own, there are those developers that simply lack the ability to think logically, which is a needed trait for a developer. I don't believe that anyone can program, just as I don't believe that everyone can sell or perform scientific research or manage people. Different people have different strengths. Typically people who are not teachable in one thing are often teachable in another. These people should be encouraged to find those areas in which they excel. Luckily, these people are typically filtered out early on.

Apathy - This is related to laziness, but this developer isn't lazy - he's tired. He may be worn out on a particular project or with a particular technology, and he just doesn't care enough anymore to implement excellence.

In any of these situations, it's important to keep the team fresh. An infusion of new blood can often help to renew the team and make it into something vibrant again.