What to do with star developers who don't document their work? [closed]

Answer 1

We had a similar problem when I started my current job a little over 3 years ago, our lead developer was a cowboy. He was really smart but very erratic, some of his stuff was very well documented, but so overly complicated it was imposable to maintain, or code first and figure out what he was building later, he would throw out code to see what would stick.

He left about 2 1/2 years ago, and it's still haunting us when we find some of his old code, and in his defense that's how the development shop here was run back then, in the last 3 years I have been on a crusade to change that mentality.

When you become a star developer it stops being so much about how well you know the system, code, framework, architecture, etc. and more about

1. Writing elegant, maintainable, flexible, readable code
2. Working with the rest of the team: using source control, leading by example, etc.
3. Documenting what each method, class, object, etc is doing
4. Researching new and better ways to do things for yourself, and your team

if your not following all four of these at some level your not a star developer, more so if you refuse to try/learn to use them then it's time that that should find other employment opportunities one way or another, I hear starving artist is popular with this time of person (the whole misunderstand genius thing)

Answer 2

This question makes me nervous, because while the person you're describing sounds egregious, I can see a little bit of myself in him.

I think I'm a pretty good team player, and I'm lucky to be on a very good team. However, I do use methods that my colleagues don't understand, though I've tried pretty hard to explain them. There just is a pretty large experience gap, which is no reflection on any of us.

Documentation is a broad and tricky subject. I try to follow the DRY (don't repeat yourself) maxim. Documentation that is separate from the code can amount to repeating yourself, so it is liable to get out of date unless you slow yourself down to keep it up to date. My usual approach is to touch it up afterward.

Often the problem I'm working on is so tricky that I can advance plan and document all I want, but when it comes to the code I often discover that I was wrong and have to re-think it. So the idea that you can document stuff in advance, and just follow that, only works for pretty straightforward problems, it seems to me.

Anyway, I think this is an excellent question, and the answer is not at all simple.

Answer 3

I think this is pretty typical in any environment. How do you get someone to do what you want? This is exactly what "How to win friends and influence people" is all about. Dale Carnegie was not about manipulation, but managing people.

It sounds to me like he's just inexperienced and needs some experience and guidance.

Do you think you can sit down and talk to him about these issues? Telling someone they're doing something wrong often seems like the wrong thing to do (especially in today's western society where we don't want to hurt other people's feelings) but I think you can get very far by calmly and honestly explaining the issues and talking them through. It helps if the person respects you and your opinion, which is a whole other issue and is talked about in the book mentioned above. Make sure he understands that these are serious issues. Also, that in any future development jobs he'll be expected to do these things too so it's a good idea to practice them now.

I don't think waiting until the next performance review is a good idea. Piling up a bunch of negative feedback and delivering it all at once is just a bad idea and I really disliked it when that was done to me.

Answer 4

In my opinion, you need to drop this guy. It sounds like his code is unreadable and he is definitely not a team, nor a safe, player.

It is also a very bad practice to allow someone to see themselves as indispensible. If you let him keep this up, his practices will get worse, not better. When he leaves, for everyone does, you will be left with an enormous headache of tangled code. You need to cut your losses now if he will not shape up.

Finally, keeping this developer without reigning him in sets a poor example from junior developers. If you force them to work correctly, you risk resentment from the "why him and not me" crowd. If you don't, you get a bunch of hacks who work like your "star."

In short, unless he shapes up very, very quickly, it's time to drop him, for the health and sanity of your entire development staff.

Answer 5

Play the bad cop/good cop sketch you have seen from the movies. Let the management be the bad cop and you be the good cop. Let the managament ask for over-kill documentation and per-minute ZIP backups of his work. But you offer him moderate documentation (by doxygen for example) and usual source control check-ins...

Answer 6

Trying to change things? What do you prefer, a poorly documented working piece of software or a well documented junk? Some people is capable of writing software that requires little to no comments, that is not a reliable indicator of quality.

I'm afraid you're going to lose a good developer.