What you should do if your junior did not adopt your suggestion? [closed]

Question

I am leading a team of 3-4 junior developers. My job-- besides writing code-- is to provide supervision and guidance for the juniors.

But, I fully understand how much developers cherish autonomy in their work, and I don't want to destroy their intrinsic motivation by spoon-feeding them with my thoughts and my algorithms; I want them to explore the problem in their own ways, and think about it themselves and only come to me when they are really facing insurmountable issues.

When they do come to me, sometimes I would have to propose a completely different algorithm to solve the problem because their algorithm isn't robust enough ( remember, I am the senior and I have seen more than them). Of course I would explain this in a nice manner so as not to hurt their feelings, and I would gently outline how my solution is vastly superior than theirs, no condescending tone or condemning words.

But still, they are sometimes reluctant to accept my suggestion, partly because they have invested so much in their own algorithm, or partly because of the fear that using a new method would entail more learning time and make them appear to the management as if they are going nowhere. But deep in my heart I know very well that my algorithm is much better than theirs and they should just adopt it.

What should I do if they didn't adopt my suggestion? Should I just ask them to follow my way, or should I just let them have their heads banged on the wall many many more times and wait for them to come back to me? Doing the former makes me into a dictator, but doing the later would cost us precious development time and incur bug fixing cost. I am really in a dilemma here.

Answer 1

Help them to understand why they should make your suggested change. And listen to them if they have a good reason not to make the change. Have a discussion, and come to an agreement on the basis of what is the best thing to do.

This approach is important for the following reasons:

• You want them to be making the change because of solid business/technical reasons. It's important to be clear on what these are (any remember that you could also be wrong, so be humble....).
• You really want to convey the reasoning behind your suggestion - that way the recipient will learn to solve similar problems themselves in the future. You'll also have a better relationship if your juniors feel that they are learning some good insights from you.
• You won't be respected if you use your seniority and can't demonstrate that you actually have good reasons.
• Your boss would presumably like to be confident that you are using your juniors' time effectively on things that create real value, not just "doing it my way" for the sake of it.

If you are smart, you can also get them to come to the answer just by asking questions. Done right, your junior will come to the correct conclusion themselves (and therefore be much more willing to implement it). Example questions:

• Your code assumes access to the production database. How could we change that so that it will still work and can be correctly tested by JUnit in a disconnected development environment? (potential answer: ah! we should use dependency injection....)
• What will happen if an attacker deliberately sent some cleverly constructed SQL in your online data entry form? (potential answer: ah! perhaps we shouldn't construct SQL statements by concatenating unverified text from the internets)

EDIT: If you succeed in persuading your junior that the right thing to do is to follow your suggestion, but they are still reluctant than here is some additional advice:

• Explore why they are reluctant. It is possible that they need to come to a personal realisation that it doesn't matter if you throw code out, provided you get the result. Or it could be that they feel under time pressure because of some deadline. You need to know, otherwise you can't help them.....
• You can make the point that they can treat the change as a way to improve their refactoring skills. Once refactoring skills are good enough, you should be able to re-purpose even a fairly large and complex code base relatively quickly.
• You should emphasise that everything will be in source control, so they can always revert back to an old version if needed.

Answer 2

I hated my last Team Leader's overbearing attitude but respect him for the fact that he had superior technical knowledge and he taught me a lot without lecturing me. Most importantly he never forced me go with his plan. He would play Devil's advocate with my plan, forcing me to prove that my plan was flawless. He would look for loopholes and wait for my explanation as to why it isn't a loophole or is a less expensive solution. He would ask me if there are any alternative solutions and propose some ideas if I didnt have any. I would have to evaluate his ideas and that his plan wasnt optimal or If he was convinced that my plan was right or at least had the same risk-reward ratio as his, he would give the go-ahead. If I failed with my idea I would have to try his solution.

There has to be a tradeoff between liberty and deadlines. You dont have the luxury of extending the deadline and you cannot let your juniors breach it. You must be polite but firm with them that once they have tried their algorithm and didnt get it working, they have a duty to listen to you. Prove by example that you know your stuff. But, equally important make them learn, dont teach them.

Answer 3

If it is a requirement, then note it as that. If it is only a suggestion, as you note, then they should be free to do it otherwise. Some questions I would ask:

• Do you have the authority to push for specific solutions?
• What is the extent for that authority?
• Is there solution bad or just different?

I am sure you could ask more, but the first two focus on your authority and the last on whether the issue is really worth pushing.

The following answer has some great additional points and I would add here that you need to treat it more as a collaborative process where you work through at least some of these with your "team" rather than just issuing dictates to them. They will learn as they work through the issues with you more than just being told, "consider doing it this way."

Answer 4

Learning really only happens where failures occurs, because failure is a motivator and provides memory cues for recall in the future. This is essentially what we call experience, and good experience in the workplace will come from having failed and learned from the failures. If your juniors were capable of getting everything correct first time, either they wouldn't be learning anything, or they wouldn't be juniors.

If you have too many juniors messing things up, perhaps your company has staffed incorrectly, with too many junior grade developers where time constraints require better experienced people to minimize your risks, yet even then you can have problems and delays, as senior developers make mistakes to learn from as well.

Your juniors will need to learn and gain experience in order to be able to cope in an environment where the deadlines are tight. As a team leader, it is your job to set an example and inspire your juniors to work efficiently, however the reality is that you have to set aside concerns of personal pride and concerns for your tight schedules if you want your juniors to actually learn something, and therefore you need to allow them to fail. Therefore, it is your job to make a call. Sometimes you need to give the junior the space to fail, and then take them patiently through a review process to show them where they could improve their ideas. At other times, you need to put your foot down, but do it in a way that allows you to show that doing so is out of a genuine need which doesn't reflect poorly on your junior's abilities per-se. If however you do head down this path, you must expect a certain amount of hand-holding and therefore it is up to you to decide if the extra burden on your time is worth it, or if you'd be better of just leaving your junior to fail and learn.

As for the issue of tight deadlines, this is where you need to schedule and allocate your work according to the relative strengths and weaknesses within your team. Ultimately the buck stops with you. When you are in charge of others you're not there to be everyone's friend, you're there to get a difficult job done under difficult circumstances. How you keep everyone on your side comes down to talking people through your concerns and issues, making a reasonable case for why you need your team members to do something in a particular way.

From my own personal experiences, you need to reserve a set amount of time with your junior to discuss the strengths and weaknesses of both ideas and then collaboratively look forthe best solution that will solve the problem at hand - even at the risk of allowing yourself to be proven wrong - and then move forward. If you both can't reach a consensus by the end of your allocated time, then at that point you need to wind up the meeting with a summary that takes into account the concerns discussed and notes that no consensus has been reached. Regardless of the outcome of your meeting, you thank your junior for the time spent, and indicate that you will return with your decision shortly. After careful consideration of your discussion you will have the option to either allocate additional time for further discussion, or instruct the junior to go ahead with whichever plan you have settled on subject to the outcome of your meeting.

Yes, time is precious at times, however when you choose to take on juniors you need to accept that you are taking on a responsibility to invest in and nurture their professional development, and you need to accept that as a result it will for a while at least cost you time.

Answer 5

I would question if you're actually presenting your suggestion in a way that isn't condescending. When you're using phrases such as:

my solution is vastly superior than theirs

and

deep in my heart I know very well that my algorithm is much better than theirs and they should just adopt it.

it makes me think that you could be coming across with an attitude of "my way is superior". No person likes being given that attitude. When I've received it in the past, I've actively gone out of my way to use a different algorithm to prove the person wrong. It could be that your juniors are doing the same.

A better way should be to sit down with the person and discuss their algorithm. Point out why you don't think it will work, and listen to the answers that they give you with an open mind. See if their algorithm can be modified to work correctly.

If what you junior has definitely will not work, then explain to them why it will not work. What parts are incorrect, or will involve rewrites later on, or don't fit the business model. Ensure that they have a good understanding of your reasons. Then explain your algorithm to them, pointing out the pieces where it would work and their code would fail.

Answer 6

First of all, do you know the real reason why your junior didn't adopt your suggestion?

Sometimes you know, a junior may actually write something better than his senior due to newer perspectives and a more up to date CS education. Although as a senior you may have seen more real world examples. But a bad trap I often see my seniors sometimes falls into is forgetting that best practices could change over time. I'm sure this does not apply to you however as you have been updating yourself on sites such as these. ;)

I would suggest try approaching your juniors without any (or little) "aura" of a senior, try to talk in level terms with them, show curiosity in the code they have written. Ask questions, hear their responses. Don't ask in an accusing manner such as:

"Your code is pretty inflexible, you need to change it to this..."

instead ask

"I'm just wondering, what if someone were to...does your code manage to handle that?...I think a strategy pattern might help here. what do you think?"

This I believe will help you in engaging with more healthy conversations with them than like a professor/lecturer looking down at them like a know it all. It will also help you to better see their reasoning and perspectives.

Answer 7

Do you control push access to the repository?

In open source, push access is always controlled by a gatekeeper who is in charge of enforcing quality. If you are actively monitoring the commits they're pushing, you should be acutely aware of where they can improve.

Do they get to hack on or improve your code. If they get a chance to see the internals about how your code works they may learn how to adapt to your style better. If you're pushing your suggestions without accepting suggestions with an open mind then they will be less inclined to listen to your opinion.

There are some circumstances where there's no right answer (such as coding style preferences). In that case, try to establish (or enforce) a company-wide policy so they understand that the style of the code should be geared to be consistent with the main codebase. Using an already-established style guideline (like Microsofts style guide for C#) is the best way to go, especially for new developers on the team.

If you're making blanket statements about their coding techniques, there's a pretty good chance that you don't completely understand the reasoning behind their choices. Just the tone of your question makes you sound arrogant. What do you gain/sacrifice by pushing your approach on the younger developers?

The key question you need to ask yourself is, are your suggestions geared to maintain/improve the quality of the codebase or to assert your dominance/superiority over your peers? The former is simple quality control and can be justified as such, the ladder is detrimental to the team dynamic whether or not your right.

Either way, if you want to push your solution onto your peers you should have concrete proof that it is, in fact superior. A magnitude increase in performance should be easy enough to improve, anything less isn't worth the effort (excepting performance critical applications). Forcing your work on others to justify your personal sense of superiority will end with you being singled out as the 'crotchety old guy'.

Note: The best and most talented programmers I have encountered over the years always seemed to be the ones who were willing to stop and explain the back story behind where they originated their approach.

Answer 8

Well this seems interesting and very much natural with young programmers very much attached to the code they have written, maybe they have spent quite some time in arriving at the same or they picked it from some good site (SO indeed, Hey Jon skeet wrote this man ! !).

Nonetheless the basic string attached here is there attachment with the code which is where you would need to concentrate and i think you would need to put in some considerable effort in making them understand that the execution and expected outcome is of more significance then their name being etched on the source repositories for pushing in this code. You will have to draw lines as why your code is better and is also good in terms of maintaining it for future works.

Take into consideration that a few failures is eminent (need a few heart breaks for any attachment) but with gradual effort i think they would come around and would be able to appreciate your efforts better. A bit of time and few failures is what i think you would need. Forcing it upon them would be other way round few success stories and then doomsday and revolt.

Answer 9

Everyone has a different style. If you find 10 different people and present them with a nontrivial problem they're going to give you 10 different approaches using 10 different "coding standards" styles.

The point being: pick the stuff that matters. If something is presented to you by a junior which doesn't produce the correct solution, does it grossly inefficiently (+1 order of magnitude, not an instruction here or there), or creates a security hole, then explain your issue and why. If it's a "I would have done this" comment, well that's great, you would have done "that" and she did "something else" but the problem is still solved sufficiently (see the above points). Move on to the next feature or fix.

Part of learning to be a good leader is learning to recognize what really matters and what really doesn't. Plus you remove yourself as a potential bottleneck to your group's performance if they have to vet everything through you.

EDIT: make sure your suggestions are genuine and not veiled requirements. A suggestion is just that- a suggestion which one is free to follow or not. If it's a requirement, state it as such.

Answer 10

As some of the others have pointed out, if you really are just proving the junior developers with suggestions and they are phrased as such then you really don't have much grounds for getting annoyed at them if they don't follow it because they may not see much reason for doing so. Likewise, you really can't go an berate them for not following your suggestion because they aren't actual direction to do things a certain way.

In regards to trying to get the junior developers to do things as you would prefer to do them:

• Control your terminology, making a suggestion is not the same as making a recommendation which is definitively not the same as providing direction. Use terminology accordingly to get your point across and if you think that your way of doing something is a better way of doing it, tell them that it is your recommendation to do so. Likewise, if it absolutely critical that things be done a given way (i.e. can't withstand a time delay) then just be blunt and give them direction in how it should be done.
• Junior developers are still going through the learning process regardless of how you are phrasing things, always provide some sort of reasoning behind what you are telling them unless there is a specific reason you cannot. Even in that case, most people will understand if you say something along the lines of "It has to be done this way, I don't care for it myself but the decision has already been made." they tend to be fairly reasonable.
• If it is truly is just a suggestion then make sure that your idea is actually better than how did it. If you don't think it is the case then sit down with the developer and do a code and concept review so that they can justify their solution. It may be that once they start explaining it to someone else - and you ask the right questions - they will see a better way and want to recode things on their own.
• Don't quibble over the details if their solution is similar to what you originally suggested, it may be that they took what you told them into account and did things slightly differently or changed their original concept based upon your suggestion.

Answer 11

This is a perfect introduction to unit testing. If your junior devs have a solution, it should be testable. Have them produce a unit test to stress their code. Then review the unit test. If you can show holes in the test, then it is easy to have them rerun the test and see their solution break under the pressure.

That allows you to show them why your solution is better, gives you a unit test that you can reuse when the code changes, and gives the junior devs a valuable learning experience. And who knows, you might find out that their solution is fine.

Answer 12

At some point you have to be in charge. You sound like you're making an effort to let them voice their opinions. Your suggestions may not be perfect. The other devs may not understand/agree with you. They probably don't agree with each other. If you are in charge, it's not a democracy. They knew that when they took the job.

If there are no situations where they must follow you, you don't deserve and serve no purpose as their boss. Change your role in the team to be a resource and not an authority if you don't plan on using it. At some point you have to ship the best code you can under the time constraints that are available and can't debate, research and debate again every line of code until the end of time.

Give the orders. Live with the consequences. Learn from experience. Respect is a two-way street. You're demonstrating it and they're not.