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.
Monday, October 12, 2009
Subscribe to:
Post Comments (Atom)
Posts
2 comments:
I think this is a very single sided/narrow minded article as it doesn't way up the problems with teachability from both the architect and the developers POV – but I suspect it was never intended to as this is afterall your personal blog.
Nevertheless it essentially makes it a list of things that an architect can use as reasons for a failing project or to deflect attention from himself and/or possibly a poor architecture.
Clearly I am a developer and not an architect. I have worked on project which in my opinion had a theoretically brilliant architecture but the project failed miserably simply because no one could understand the architect because he communicated virtually in binary!
You're absolutely correct. I've appended my post.
As a side note, I use the term "architect" loosely. I'm not an architect - I'm a developer. That being said, there are times when a developer (senior, lead, whatever) takes the reins in architecting an application, in which case, the developer is playing the part of the "architect". In a good team, at various times, each member of the team will play this role at some point or another.
The point here is the developer's ability to learn from other team members. The terms "architect" and "developer" here are used as a convenience, and I should have specified that more clearly.
Thanks for the post!
Post a Comment