views:

270

answers:

7

How do you deal with situation if someone who is as new as you on a project starts complaining about implementation details of stuff you are currently implementing.

Work is not done.

He certainly wants to help, but just distracts you from progressing.

So how to tell the person to hold his jets and not getting him offended? If tell at all? What do you do in this type of situations?

+2  A: 

Do some pair programming with him if he's got nothing better to do.

You could also specify the interface for him to use and leave it as non-working code for now.

Joe Philllips
It's open source project, we are not in same location.If we would be in same location pairing would help for sure.
Hubert
Ah, missed that tag!
Joe Philllips
+10  A: 

Well if it is work in progress it sounds like the a good time to change it. First of all take a step back and breathe out and have a good think if he is right. If he is then I suggest it might be time for a re-design. This might be worth discussing with someone more senior or with more experience of the project itself if you are not certain. If he is wrong you should tell him you disagree and try and explain why. If you feel it could be done both ways then you tell him to save time it is being done this way.

Tell him that you appreciate the feedback and that he should keep doing that.

willcodejavaforfood
He is right. But he is talking about aspect that is on my todo list, after I finish some essential features.
Hubert
Perhaps you should just tell him it is on your todo list then? Your coworker probably is just looking for some acknowledgment that he's at least being listened to. Simply doing that can work wonders at times.
Jason Baker
A: 

What I would do is invite the guy to a design discussion or two to clarify in detail what I am working on and his opinion on it. This might even help you get your ideas straight. Once you reach a conclusion, even if it's not final, you can get coding without changing the plan until the current iteration is done.

Only asking for contributions to ongoing work, especially from someone with different ideas, is likely to result in conflict, since you won't be able to merge his code with yours. On the other hand, if you first agree on a common path, you two could split the work.

Tiberiu Ana
A: 

It might be a good time to start a regularly scheduled meeting. Then you can designate that time for problems, and grievances. Leaving the rest of the time to code.

I think willcodeforjava had some good points. Ultimately the goal is to get him to stop disrupting your work. If this is a job, let him know that he's disrupting work, and just politely have it out with him once. Then don't let him complain again.

J.J.
+1  A: 

Let the person know (diplomatically) that you cannot implement anything until left alone.

Jim Anderson
A: 

Release early, release often, correct frequently.

When it comes to a fellow dev team member, this might be a great opportunity for you to sit down with the complainer for an hour or two of pair programming every work day. Let this person participate in the work with you. They will either catch on to your superior methods :-) or make a reasonable independent contribution. In either case, the project comes out ahead and at least one of you learns something.

catfood
It's open source project.
Hubert
+1  A: 

Honestly consider his opinion (he may very well be right) but if you still feel that you're correct or that your implementation will be just as good then tell him that you'd be glad to get his thoughts and feedback when you've finished implementing X, because right now it would just be a purely academic discussion.

SnOrfus