Fog Creek Software
Discussion Board

How to deal with team members' mistakes

Recently, I "outsourced" some work on my project to a team member on another project who had some slack time.

The team member in question is enthusiastic but inexperienced, so he makes mistakes which aren't trapped at a simple unit test but are uncovered when it comes to integration.

My moral dilemma is this : I can fix the bugs myself quickly and get on with integration (which is holding up the rest of the project), or I can get him to fix them. Which is less quick in the short term and also involves him being pulled off his current project he's moved onto since completing unit testing. It would be a good move in the long term as he'll gain some programming experience.

What do you recommend?

Better Than Being Unemployed...
Monday, September 15, 2003

Why don't you work-with/mentor this programmer?  Lead him to find/fix the errors.  It'll be quicker than letting him do it on his own and he'll still learn something valuable.  Don't point him directly at the problem(s) - make him think.

Monday, September 15, 2003

Fix the bugs yourself, then when you both have some time after your projects finish go through the changes with him.

Matthew Lock
Monday, September 15, 2003

Point out and explain his mistake to him before fixing them, even if you need to go through and fix them yourself. Otherwise you'll just need to do the same thing again next time he makes the same mistake.

Mr Jack
Monday, September 15, 2003

Are they really "mistakes" or is it just that you don't like the way he coded something?

Monday, September 15, 2003

If he seems like the type to genuinely appreciate the learning experience and you both have the time, I think you should have him fix them. 

Monday, September 15, 2003

Demonstrate how you found the errors at integration that didn't get caught by his unit tests, which should help him write better and more devious unit tests.

Helping him see the problems should make everyone's lives incrementally better.  It's up to you whether you do this concurrently with fixing the problems yourself, but of course it'll be a better learning experience if you let him make it go.  (This is like Joel's practice of making the person who most recently broke the build responsible for running it.)

Sam Livingston-Gray
Monday, September 15, 2003

They are bugs that appeared at integration time, it happens, and they are expected. That is the attitude. Just place comments/change histories around the source about what you changed, and possibly an objective statement of intent, so he knows you have changed stuff if he comes back to it and why.

Tuesday, September 16, 2003

If this Junior programmer produce to many bugs per day then maybe he's not ready for writting production code and should be assigned only to bug fixing for a while,
this would improve his solving skills and hopefully coding skills too.

If the rate of bug per week is fairly low, mentor him as he's almost there.

Good Luck with your project anyway!

Saturday, September 27, 2003

Are the instruction/requirements/documentations well kept and readily available?

Often we find new developers to the project, irrespective of their experience, make mistakes if the above are not taken care off. Also it takes some time to get up to speed on creating modules that integrate with others in the project.

The new developer is focusing on the local level - if he/she is also assigne to follow-through on the integration testing - it will help them see the errors.

Just a thought - obviously every project/team is different :)

Ram Dass
Monday, September 29, 2003

*  Recent Topics

*  Fog Creek Home