Menu
Dealing with laziness is ultimately a problem of motivation. If a developer is lazy, management must figure out what would motivate them to work. One of the more effective techniques is to tie part of their compensation to job performance, combined with rigorous, transparent, and objective performance reviews.
The best way to do it is by asking questions and showing your colleague the respect you would want if the situation were reversed. By asking questions instead of immediately criticising their bad code, you prompt them to self-evaluate their coding practices.
In my opinion somebody doing such stupid things as you have described above can't be a star developer! To me it seems like he intentionally makes things more complicated as they are, so that nobody else than himself can maintain the code. This makes himself more important than he really is! Talk to him. He has to change it! If he doesn't, replace him with a real star-developer!
I promise you, in even half a year he will not know how his own code works! Fire him and you can save a lot of time and money.
The CVS part is easy - an "accidental" hard drive failure will teach him a lesson for a life (make sure you have a backup though so you won't actually lose code)
That sounds like a tough situation.
Personally, I would let him go. He may be a star developer, but he isn't a team player. And you need to have a cohesive team that can work together if you want to make a good product.
Failing to document is a (very bad) way to ensure job security.
You can do several things to counter this:
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...
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With