How do you coach a slow developer?

Question

What goals and resources can I give to a developer who isn't working at the speed we'd like?

We hired three developers at the same time that we considered to be at the same skill level. At this point, about a year in, one of the developers has lagged significantly behind in research & production speed. The projects they complete are done well but it takes a lot of time to get there. The delays come in the form of repeated design meetings, extensive research, diagramming systems, code reviews that result in big rewrites and more. The developer seems completely thrown off by any class/plugin/module/etc they haven't encountered before (or recently.)

Normally, when coaching someone, we set a measurable goal and then identify resources that they can use to achieve that goal. In this situation, I can't think of how to accomplish either of those tasks.

Answer 1

My best experience with these types of developers is to have them work side by side with a stronger developer. Some people have a harder time learning on their own. I guess this is called mentoring....

Answer 2

Maybe take them off a project for about a week and have them attend a training session, either done by a 3rd party (conference or something like that) or have another person (not one of their direct peers!) give a training session to them on the technology their struggling with.

Answer 3

I think you are on the right track by setting measurable goals and offering assistance to achieve those goals. For this individual, however, the goals are different than your speedier employees. Being productive in a reasonable amount of time needs to be this individuals goal, and you can measure objective results such as lines of code written, or tasks completed, or projects finished. Those normally aren't good measuring sticks given the diversity of projects, and quality of code, but it would give you some leverage to explain your issues with this individual.

My other advice is to be as open as possible about the situation. Make sure this person understands that they are lagging behind and that it's a problem. Set regular check-in meetings to report on their status. Chances are he or she will get the message and make some progress. And of course, you can't let them slip in other areas such as quality.

If they don't make progress then you might have to let them go.

Answer 4

I think your developer might need a different process involving more frequent design and code reviews. They might also be more productive doing collaborative development.

Answer 5

The problem is that you hired a born DBA (i.e. conservative to the point of obsession) as a developer. Really good developers are 40% brains, 10% training, and 50% cowboy.

Something like 40% of developers "drop out" of the game within the first 5 years. Doesn't make them lesser people, it just makes them "not developers".

Cheers. Keith.

Answer 6

How about a high voltage delivery device installed in their chair, rigged up to a remote-control activation button. That way when you pass their chair and ask "How are you progressing" and you don't get the corect answer, press the button.

It may also be worth installing some form of cake or confectionary dispenser later for the correct answer.

Mind you the whole thing may be a bit ineffective unless you also add in some form of lockable seat restraint but I believe they are frowned upon by health + safety. :(

Answer 7

I can also recomend pair-programming. Let the one with the dragging progress curve, work alongside someone who have a easier time adapting to new techniques and challanges.

Some people are more adapt to learn working alongside others where personal initative is not needed. I have worked with alot of developers who are good at what they do but lack the will to learn or excell with waht they are doing.

My tip is to talk to this person and see what he feels towards personal development and reaching your expectations.

Answer 8

It seems that the problems you are facing with this developer occur towards the end of a phase of development where time was already wasted ("code reviews that end in big re-writes"). By this point he/she has already spent a good amount time, including the research, etc.

Perhaps you should focus at the start of the process on clearly defining each deliverable with this developer, and breaking them into sets of easily manageable tasks with estimates. These deliverables should be tracked for time and reviewed as completed.

This sort of micro-management is often tricky and if not handled well, could ultimately result in loss of morale triggering worse performance. It would be imperative to articulate your goals and ensure your developer agrees with them before you start.

Answer 9

Warning, football metaphor follows:

Well, it depends what type of team you have. If you are working on open source project, then you are coaching a recreational team and you've probably have to work with the players that you've got. However, it sounds like you have a professional team that you are coaching and thus you have a responsibility as a coach to acheive the best results.

You've had try-outs and this player made the cut, but after his rookie year he is not producing. If you are not satisfied with his level compared to the rest of the team, then you really have two choices. Either trade him (transfer to another group where he contribute) or release him to free agency (if you doubt he's going to be able to contribute anywhere to the organization).

One important axiom in coaching is you can't teach speed.

Answer 10

The joke answer is "slowly." Some people are slower than others, though you might find interesting ways to turn that around. If you do not, you might decide to hire someone else...

On the other hand, it might be a round-peg, square-hole problem. I would suggest trying to find out what the dev is actually good at (if anything) and perhaps taking advantage of that.

Answer 11

Is he happy with the level of supervision and clarity of instructions he's getting? Some people can be given requirements/goals on the back of an envelope, and they'll come back in six months with working product. Others need a lot more personal involvement with requirements clearly spelled out.

One thing I learned from teaching English as a second language is to never ask "do you understand?", because they'll smile, nod and say "yes", all the while thinking "I'll ask my friend standing next to me, and then I'll understand". And their friend is thinking exactly the same thing. Instead get them to explain back to you what you just said, to use it, make up their own examples, etc.

I'd try using this approach when setting him tasks, and also try to find out how much supervision he needs to get the best work out of him.

Answer 12

This may be a separate line of work but could you give the developer some new class/plugin/modules to do a few things:

1) See what they are doing when they have to learn something new. How difficult is it for this person? Do they know how they learn things quickly? Do they do an academic overview and then start practical things or jump in with both feet? Is there a learning disability for this individual that may make them of a different skill level that wasn't noticed before? This is mostly something to note and investigate in a sense.

2) Practice these skills. Learning something can be a skill in many ways and is something that requires use to be any good at it. By giving constant exposure, the developer will either sink or swim. Some of us may have done this more than others so that it is more natural in a sense.

It may take a few months of repeating this process as there may be issues with confidence, learning new material, or something else that will be found for the reason why things aren't working as well as expected.

Answer 13

As someone who has been both the most admired programmer in my group and also the one let go because of performance (separate companies), this issue is near and dear to my heart.

Begrudgingly I agree they should be let go if performance does not change. However if performance improves but not exactly at the rate expected, I believe you should give a little more slack than you would otherwise. Your efforts may have unclogged unrealized potential and the improvement may even exceed your expectations in the long run. Plus the fact that you gave this person a second chance may go a long way in employee loyalty.