Related Questions:
How your coworkers and Jerry both feel:
Should I tell my boss that my coworker’s work is of poor quality?
Colleague keeps trying to set me up to fail and discredit me
What can you do:
When you have passive aggressive co-workers
How to explain business priorities to a programmer?
TL;DR:
- Document all of Jerry's improvement ideas ( good or bad ) in a "Suggested Improvements" folder in your project management software to be worked on when best practices allow. Your other team members should also be contributing to this folder!
- Any of these suggestions that are of questionable technical or business merit should be discussed with either technical or business managers.
- Continue to help Jerry. Your boss told you to help him and your team's negative attitude towards him is most certainly part of his current frustration.
- Make it clear to your boss what you're helping Jerry on. You can include this in the "Suggested Improvements" just as part of the initial explanation - "Jerry and I looked at {x} for { length of time } and { Jerry / I / we both } decided that {y} might make a better {z}". This clearly documents what you helped Jerry understand, when it happened, while also clearly crediting and documenting his ideas. If you disagree with his idea, write that down too. It makes the discussion clear for other technical team members to review.
- When helping Jerry, be sure that you are trying to explain in microcosm what he actually says he does not understand, not what you think the code in question does or what you think he needs to understand.
- Be sure that he fully understands or dismisses you before you leave him on his own.
- Try to clear up your team's negative attitude towards Jerry. It doesn't help anyone, and will only makes everyone's job more difficult and less pleasant until Jerry quits, and there is no guarantee that Jerry will quit.
- If Jerry's short temper remains after your team has resumed helping him and his ideas are being taken seriously, take it up with your manager.
Full Answer:
I started work with Jerry to help him by giving suggestions, ideas, solutions and some times code snippets also. ... And last week a technical discussion with the current lead becomes severe argument and went to the extent of shouting and yelling. And in that argument he emotionally yells that “No one is helping to understand current code base”. The next day I asked my manager “Am I helping Jerry qualitatively”. And in that discussion I learned that he never tells my manager about the help I am giving and he never gives the Credit.
It might be the unfortunate case that he doesn't find your explanations helpful. This might be a failure of understanding on his side, communication on yours, or a bit of both. To be frank, judging by your question, your written English communication could be better. It's readable, but there's grammatical errors and it's not very focused. I'm not saying it's entirely your fault and don't want to make assumptions, but if Jerry is a native English speaker and a significant part of the dev team is not, this communication barrier could be part of his frustration. It is not your fault, but it is your job to make sure you're clearly understood. It is Jerry's job to do his best to not get frustrated while you attempt to explain things to him. His short temper is something that can be taken up with him - "Jerry, it's very difficult for me to stay focused on explaining this concept when you become angry. It's stressful and does nothing to further {the current business goal we are working on}.", or with management if he doesn't improve.
- The next time he needs help understanding how something currently works, make sure he has clearly stated "Yes, I understand" or "I no longer need your help" before you leave him alone with it.
- If he has to ask you for help as frequently as you make it sound, ask yourself if the code base really IS good enough. If the code is clean, with well-written documentation and comments to explain the difficult parts, any competent programmer should be able to muddle through it.
- If he is incompetent, make note of these clearly documented concepts that he doesn't seem to understand, if only for your own reference as far as things he might need more guidance with or that might trip him up later.
He even doesn’t made good impression with whom he worked past and I didn’t find one person who likes him/who are neutral about him except my current manager.
What is your current manager's like based on? Are they old friends? Does he think Jerry is a better programmer than the rest of the team? If your boss is blithely thrusting an incompetent, abrasive, and unwanted member into a team, then he sounds like he's doing a pretty poor job himself, but you don't imply anywhere that you're blaming your boss for Jerry.
Now the situation becomes more sensitive and people who don’t like him start preaching and trying to influence me not to help him further as he is using that knowledge to attack us.
This is unprofessional and a bad idea. You should help your coworkers, especially those your boss has explicitly asked you to help. Your coworkers' attitudes is probably a large part of Jerry's current frustration.
- Make sure you document and that your boss understands the help you're applying if Jerry isn't mentioning it. This can be very detailed to attempt to show where Jerry ( or the code base ) are lacking, or it could just be a general time-log like: 9-1 worked on widget. 1-3 Helped Jerry understand widget.
The problems he found, some of those are real and some of those are unreal. For real problems the approach he choose to fix those, escalate those and educate others is causing big mess.
You don't go into depth about how he is attempting to deal with the "real" issues from a software development standpoint. It probably warrants a separate question on Stack Overflow or Code Review if it's part of your overall complaint.
- If he is complaining about shortcuts that were taken for business reasons, clearly explain the business reason for the lower quality code ( if those reasons are anything except time constraints, they should already be thoroughly explained in the code comments or documentation ).
- If the code base is perfect and Jerry is complaining because he is incompetent AND this is negatively impacting productivity ( that last part is important, see this question ), you should take this complaint to management with as many members of the rest of the team as agree with you.
- What are the "unreal" issues? Is this Jerry's incompetence complaining about fictitious issues? Or are these issues that you have decided are not important? For example, common issues that developers might minimize the importance of are poor UX, poor documentation, or poor test suites. Is it something like that? Because those are all serious issues, even if "the code works".
He is not escalating first to his team members. He is directly escalating to managers, MDs.
Did he attempt to escalate to team members a few times and things were not handled to his expectations? Regardless of whether he's right or wrong, he'd be foolish to keep making requests that were ignored.
- Next time he escalates a problem past the appropriate team member to a manager, ask him "Why did you not escalate this to {team member}? Did you feel they were unable or unwilling to deal with it?"
- ARE they unable or unwilling to deal with it? You say that some of your team members are recommending you not help Jerry, so they are probably not providing adequate answers to his questions. I would certainly stop trying to deal with developers stone-walling me after the first few attempts, and complain to management if it continued for several months.
Some parts the clients/managers are happy the way it is. But he still try to influence them by saying the ways he has are better.
ARE the ways he has better?
- If the current software work and clients are happy, you can clearly explain how it's not a business priority to change them. But maybe you could placate him by documenting his ideas in an "Improvement" or "Backlog" folder in your project management / bug tracking software.
- If his ideas are about changing code to be easier to work with, AND those ideas are good, AND that code is worked with frequently to meet business needs - you can evaluate the business case for updating that code. See this question