3 ms·

You gotta find a way to figure out if this person is CAPABLE of delivering better code. That's gonna hinge on their talent, and their willingness to learn. At s

You gotta find a way to figure out if this person is CAPABLE of delivering better code. That's gonna hinge on their talent, and their willingness to learn. At some point, some folks make it clear, one way or another, that they can't/won't get much better, at which point you unload them. Until then, you need to be friendly and patient, for a number of reasons. Don't betray shock, and don't betray disbelief in their incompetence, but do firmly require them to sit through a lengthy code refactoring with you or someone you trust, so that they can see what is required AND how far their code is from what is required. They need to feel your pain, but not by you being testy or edgy or frustrated. Or, as the good writers say: show them, don't tell them.

Roboprog 11y ago
That was my worry: the guy who writes 400 line functions/methods/subs is always gonna do just that when nobody is looking. I am assuming 2 to 4 years training or education prior to this. If you haven't learned to subdivide long / deeply nested routines into smaller functions with defined inputs and outputs after 2 years, you probably just don't get it, and may never. That seems harsh, I suppose. But I've been doing this for a living for most of the last 30 years. When I started, I was 2 years into my CS degree. I've met too many code monkeys who might know some new API, but just congenitally cannot organize code to save their lives and write stuff I would not even have written as a 20 year old part timer going to school. Spend a few weeks to see if the guy can learn. If not, start documenting a "performance improvement plan" (there's a euphemism) so you can get rid of him.