Coder-friendly

I trained in project management few weeks ago. The speacker had a great culture in this domain and he gave us a lot of case studies: two of them were on software management. The first one was how to manage a ..BIP.. At this time, I don’t want to influence your opinion on the category in which I put this person, I keep the “..BIP..”

So, the story is:

You are the project leader of a mid-sized software. You have hired a great programmer, Tim. During the interview, he seems pretty good and he answers well to your questions, you identify a big technical background.

After some months, you are not sure that you have made the right choice. Tim can be qualified as an asocial: he’s not a team member, he doesn’t participate to the discussions with other team members.

Yes, it is a case study. It is a surprise that the human resources don’t detect such a comportment. Note that we don’t know which questions the project leaders asked to Tim. Then, the story continues with the following points:

• Tim spends too much time at work. He works the week-ends but sometimes and he takes free-day without your permission.
• Tim knows everything on Java, he is often consulted by phone: he spends many hours on phone.
• The Tim’s tasks are well done but he doesn’t respect the naming convention of the project.
• Tim doesn’t write any unit tests. He writes directly and he never asks the help/validation of somebody else.
• Tim’s module are not documented.
• Tim is efficient! He develops four times faster than any other team member (tests and documentation are not taken into account in this comparison)

At this step, we understand that it seems Tim doesn’t like to work as a team. He has no respect for the rules of the project, unit tests and documentation are useless. He has a very good quality: he codes 4 times quicker than the others. But it is not the end of this wonderfull story:

You have a meeting with Tim and you make the mention of your observations. He listens to you and he answers: the other team members are friendly BUT they don’t understand anything to programming.

You tell to Tim that he must respect the rules: tests and documentation are part of his job. He replies that these things have been elaborated by non-programmer and that it’s a waste of time for a real programmer!

WWWOOOOWWWW. Now, it’s official: Tim has a high opinion of himself. But the biggest problem in this story is the last sentence: how can a good developer respond this kind of absurdities? Having a test coverage of 100% is hard (and useless?), but 0% is terrible! At least, published types have to be tested to avoid breaking customers on every changes. When I begin this post, I’ve written “The first one was how to manage a ….”: yes, we can replace the “a….” with “a pretentious coder”. His work can’t be maintained and nobody can understand his modules. He puts himself in a high pressure state: when a bug is found in his modules, he’s the only guy who can fix it.

Then, the case study ends with:

What are you doing to improve the situation?

I have been surprised by the reaction of the other persons. We were 10 and 7 of us have chosen to… FIRE HIM! So, I hope you don’t recognize yourself as Tim, because now, you know what other people may think about such a behavior! Personally, I answer that I would recognize Tim’s ability to code and then, suggest him to practice code review. If he’s so good (and we know he’s not), he can review the code of another member and say why it is bad code in order to improve it. In exchange, the other member can give feedback on Tim’s code. If Tim accepts, he will admit (in the future) that his code is not good enough. Else, I wouldn’t like to keep him in my team and I would propose him to move on.

And you, what would you do in such a situation?