How do I help senior team members improve?

Question

I have a pretty good team. We are all friends and get along well. When a problem does occur it is usually patched up rather quickly. However, one of the senior members of the team has become a little reluctant to suggestions for improvement. And in an angered moment lashed out with "It always has to be YOUR way!"

I will be the first to admit that I am not the best coder. I have questions from time to time. I get things wrong... often. But I would have to say that my code is pretty clean when I am finished with it. I am the team lead, so improving the team is one of my responsibilities.

How do I help this developer improve without upsetting them again?

Edit: to clarify, the developer is older, there had been a change in attitude that day ( probably was a bad day), and this happened during a code review. I am now a little afraid of reviews because I respect this developer and don't want to upset them.

Answer 1

• suggest pair programming
• suggest reading books s.a. code complete 2 or domain driven design
• suggest team study sessions of design patterns
• have everyone learn and present a new tool or methodology

Answer 2

Did this happen as a consequence of a code review? If so, perhaps if you offered your own code for review - especially by this colleague, it would seem fairer?

Alternatively, perhaps use pair-programming where code is reviewed collaboratively whilst it is being written, rather than after the fact, when more ego is involved.

Finally, if the code is working, then why worry. If you feel it needs refactoring, then refactor it yourself, and show your colleague the results?

Answer 3

Create situations where the problematic developer can make constructive suggestions to the other team members regularly. Senior developers love doing that.

That way, he/she can feel accepted as part of a collaborative effort, not a dictatorship, and will probably be more receptive to (gentle) suggestions from other team members when needed.

When making suggestions, do so in a non-attacking manner. Be constructive. Make it clear that you understand the other point of view -- don't just say "You're wrong, do it like this."

That said, an extreme reaction like the one you cite is indicative of a long-term problem. Is this an irreparable personality conflict, or was he/she just having a bad day with too much nagging?

Answer 4

You could help the entire team improve (not just that one senior member) by encouraging code reviews. Both the reviewers and "reviewees" benefit from this. One of the most effective ways to improve code quality is to have others read it. And one of the most effective ways to improve one's own programming skill is to read others' code (and not just find problems, but also be surprised by new ideas and techniques).

Consider a policy (like Google's) where code is not submitted until it has been reviewed by X others. There are open-source tools to help you automate this. See http://www.review-board.org/ and http://codereview.appspot.com/.

There may or may not be justification to that senior team member "lashing out", but it's a sign that he or she feels "picked on". You may want to encourage other team members (than yourself) to review that person's code (to assuage those feelings). It may also make that team member feel valued (and encourage buy-in to the process) if you compliment him or her on his or her review comments.

Answer 5

People issues are one of (if not THE) biggest issues in any profession.

So, do you do code reviews? Design reviews? How are those handled? The real goal with those is to improve the product and not bash the developer. Hopefully you are doing that right.

Do you have team standards that are followed and enforced? By who and how?

You said that this developer 'has become a little....', which I take to mean that there has been a change. Or was it always this way? Is there some deep-seated frustration with the pecking order? I've seen this on my teams in the past.

Also, do you think that maybe this developer might be having issues outside of work? It could be the case. Stuff from work and home can affect the other place. Might be worth having a heart-to-heart with the dev and seeing if everything is OK.

Answer 6

Are you younger than this team member? It sounds like it may be so, since you refer to him as "senior" (but imply his output isn't necessarily "senior").

Look at the way you communicate with him. You don't need to defer to age, but you shouldn't be cocky or condescending either. People of all ages can be condescending to those older or younger, sometimes without being aware of it. And it can go both ways -- he may feel condescending to you because of your relative youth.

Encourage his input, listen to him, and expect quality work from him. Team programming and reviews, working back and forth, give and take: all are important.

Answer 7

"It always has to be YOUR way!"

Anyone who says that must be thinking that the choices you are arguing over are arbitrary or purely a matter of taste. In fact the longest arguments are almost always over things that don't matter (there's a name for that law but I can't remember it).

If, in all honesty, they are a matter of taste, then stop having the argument.

But if you have a rationale for your suggestion, explain it. If they still say "It always has to be your way", then you need to explain something else to them: it doesn't have to be your way; it has to be the way that has the best rational justification, which is why you didn't just give them an order. You're not imposing your view; you're asserting your view, and assertions can be contradicted, and when that happens you will gladly alter your view.

Don't expect real people to take naturally to such a purely rational way of thinking. Real people bear grudges, they sulk, they gang up on each other, they work in marketing. if I stand up for you in the argument about where to put the curly braces, maybe you'll stand up for me in the argument about thread pools. Who cares if we end up contradicting ourselves? We're a bunch of apes trying to figure out who's going to control the mating. This just happens. You can practise it tactically by "letting the other guy win" in a dispute where the outcome isn't that important to you.

But for the stuff that matters, you have to make it an interesting discussion about why one approach is better than another, to get everyone out of ape-mode.

If anyone says:

• "We're not going to do X. It's just wrong", or
• "We're going to do Y. That's the way you do these things. Everyone knows that"

... don't let them get away with it! It's the road to insanity. And if you hear yourself saying things like that, you're part of the problem.

Answer 8

Ask him to choose, or recommend him, a technical topic or a book to read and to spend one hour presenting it to the team, perhaps during a lunch-and-learn session.

Perhaps also the root of the problem lies in your code review process ; as a team lead, you may have to step back and let the team decides. Did the team define its coding standard, or guideline that can be referred to during the reviews ?

Answer 9

I've found that a simple change in terminology during code reviews makes the world a much better place.

I do all I can never to ask a question like this:

Why did you do that?

A much better question is:

Why did we do that?

The goal of a code review is twofold:

• Ensure code is good.
• Let everyone learn.

Notice that these two are not on that list:

• Place blame for bad code
• Give praise for good code

Every piece of code generated by the team was generated by the team. If the team messed it up, it is the team's job to fix it. If the team did it well, it is the team that should receive the credit. Simply changing the occurrences of "I" and "you" to "we" and "us" makes that emphasis clear, and solves many of these kinds of problems.