How to correct a junior, but encourage him to think for himself? [closed]

Question

I am the lead of a small team where everyone has less than a year of software development experience. I wouldn't by any means call myself a software guru, but I have learned a few things in the few years that I've been writing software.

When we do code reviews I do a fair bit of teaching and correcting mistakes. I will say things like "This is overly complex and convoluted, and here's why," or "What do you think about moving this method into a separate class?" I am extra careful to communicate that if they have questions or dissenting opinions, that's ok and we need to discuss. Every time I correct someone, I ask "What do you think?" or something similar.

However they rarely if ever disagree or ask why. And lately I've been noticing more blatant signs that they are blindly agreeing with my statements and not forming opinions of their own.

I need a team who can learn to do things right autonomously, not just follow instructions. How does one correct a junior developer, but still encourage him to think for himself?

Edit: Here's an example of one of these obvious signs that they're not forming their own opinions:

Me: I like your idea of creating an extension method, but I don't like how you passed a large complex lambda as a parameter. The lambda forces others to know too much about the method's implementation.

Junior (after misunderstanding me): Yes, I totally agree. We should not use extension methods here because they force other developers to know too much about the implementation.

There was a misunderstanding, and that has been dealt with. But there was not even an OUNCE of logic in his statement! He thought he was regurgitating my logic back to me, thinking it would make sense when really he had no clue why he was saying it.

Answer 1

Short Answer:

Engage them (put the puzzle in their mind), empower them (trust their answers).

---

It is the question that drives us! - Matrix.

Generally, in my observations, that juniors have their own world - their own limited view of how they think and in some part their own enthusiasm/favorites/opinions about things.

There is nothing wrong about telling them head-on that you are wrong - but best is that you make them think. Why? Are there any other ways? Are there better ways to do the same thing? One of the anecdotes I always use is - "Give me three solutions (to this problem)!"

By the time they think about these solutions, they begin to realize many issues. It takes them some investment of time - but over time they tend to visualize the limitations and shortcomings of their thinking. They begin to see that more as "I didn't think of it!" which is much better than going home with the feeling that "I was wrong!" or even worse "I was told/proven wrong even when I had valid viewpoints".

In general, very young kids will tend to be more adept related to technical issues (such as which design pattern works better!) over process issues, but over time when you coach them, it works.

---

However they rarely if ever disagree or ask why. And lately I've been noticing more blatant signs that they are blindly agreeing with my statements and not forming opinions of their own.

This generally is an outcome that you do take their suggestions but later overrule them and they are equally unconvinced about your views; just because you are senior they are avoiding a fight!

The best thing I learnt from one of my past bosses: He will ask team members to debate first (they feel fairly equal here), and hopefully after all the arguments being exhausted, he would enter the room with only one question - "What were the points of disagreement?" - The point is, people always like to participate in debates and discussion, but if their (valid) points are not taken up to action next time they feel it's not worth it to participate in discussion.

Not only in software, but everywhere ultimately only the most empowered teammates will dare to reply let alone question the system.

Answer 2

If you want your juniors to think for themselves, don't correct them: get them to correct themselves.

Instead of telling them what you think is wrong about their solution, ask them pertinent questions about it. In your example, you could ask them about what someone using the extension method would need to know to create the lambda. Keep asking questions like this until they suggest that it's a problem. That way, you know they have understood why their solution could be a problem and furthermore are more likely to learn from it - if you simply tell them that their solution is wrong, that's an external judgement, and easily ignored. If they come to the realisation on their own (with a little prompting), they will realise how well-grounded it is and be much more likely to learn from their mistake.

In addition, this gives your juniors a chance to defend their design - perhaps they have thought of the problem and have a good justification that addresses your concern, meaning there's no need for you to do any correcting. That reduces any perception (however unintentional) that you're ruling by executive fiat.

Answer 3

Since you have multiple junior developers do code reviews as group not 1 one 1.

Open by ask the group "How else could the problem be solved?", and allow the other junior developers to suggest their implementations first. Only add your implementation after the other team members have spoken and if none have suggested something similar to what your idea is.

Then have a roundtable discussion about the relative advantages and disadvantages of different implementations with the intent to guide the junior devs to picking the best implementation without being told what it is.

As a confidence builder for the junior devs you could start with some cases where they picked what you think was the best option and make your alternative a strawman that has an semi-obvious flaw and direct the discussion toward why the original implementation is best.

Answer 4

When I first started working in a programming job, I did the exact same thing you described: when told about something I could be doing, I would always agree. It was mainly because I didn't have enough experience to say otherwise.

What gave me the ability to actually discuss methodologies and ideas was learning from experience as well as reading about different approaches and new technologies. In order for your team to think for themselves, they need to actually know about what problems can arise from things like "overly complex and convoluted" code, and the only real way they will find out is through experience.

A good way to facilitate individual thinking is by having them look into programming websites like Stack Overflow or Programmers SE. I know that these helped me learn about the different techniques that were out there and allowed me to have discussions with senior members of the team, instead of blindly agreeing with them.

The point is that without experience, suggestions from senior members will always sound right to them.

Answer 5

The interaction from your post demonstrates a key principle to teaching almost anything: ask them to explain what they think you said, and listen carefully to the response: it will tell you precisely what needs to be corrected.

I have shamelessly stolen copied this trick from my math tutor some 25 years ago, and it has not failed me since. I used it in class during my brief stint as a teaching assistant, at work when talking about software design, and with my eight year old when talking about her school assignments.

Of course you cannot always be blunt about asking them to repeat what you just said, so you need to adjust your strategy. For example, here is how I would re-phrase your follow-up statement from the OP as a "probing" question:

I like your idea of creating an extension method, but I don't like how you passed a large complex lambda as a parameter. Do you see how this complex lambda forces others to know too much certain things about the method's implementation?

This question is impossible to answer correctly without understanding the issue that you are trying to highlight. I found that ending my explanations with a question that requires analysis of what I just said speeds up the learning process, and gives me feedback that I need to make corrections.

Answer 6

Usually when people aren't saying what you want, it means you need to work on your listening. Listening means hearing the reasons for their design before passing judgment. It means not just telling them it's okay to dissent, but proving it by honestly considering what they have to say, and not just correcting them. Look for the good things about their solution, and modify your solution to incorporate those things.

You also need to lead by example. I don't mean by writing uber-awesome code, I mean by asking them for their opinion on your own designs. Don't wait for code reviews after the fact, but work together all along the way. Say things like, "My interface seems too complex, but I'm not sure the best way to simplify it." And give them time to answer without biasing them to your own ideas first.

Answer 7

When I have had to deal with this, I have said (honestly) things like:

You know, that's a really creative solution which I would never have thought of. How does it scale?/Do you think there might be an approach which is conceptually simpler, to make development faster or maintenance easier?/Unfortunately, I don't think it really fits in with the rest of the project's architecture./What will the configuration look like?

This has usually been enough to point people in a new direction.

Answer 8

Responsiblity is one thing that can help them.

I've led a team or two in the past and one of the things that made juniors shine was the burden of personal responsibility. When one realizes that his actions may implicate on him at one point, he/she usually commits a wee-bit-more of himself in what he does. No to mention that when they feel their work, the good results are much more satisfying.

Answer 9

I wouldn't worry too much about the fact that they blindly follow you, this is what they should be doing as juniors. The thing is that they are likely not going to understand the true reasons for the items you address in code reviews until they are gone and working somewhere else that has terrible software developers, terrible management, and terrible code.

By that time they will have learned good practices out of habit and will have to live through the coding and design mistakes that others make and they are FORCED to make that they now have to work on poorly designed and implemented software.

This will be an eventual inevitability at some point in their careers. You are doing them a great service by getting them used to good coding standards and practices. Unfortunately most of us had to learn the hard way.

Answer 10

Based on the example given I would say following up your comments with questions would probably be the best way to go. If you ask a question along with your comments it doesn't leave them to simply agree or disagree they at least have to think about how they may implement something.

e.g. "I like your idea of creating an extension method, but I don't like how you passed a large complex lambda as a parameter. The lambda forces others to know too much about the method's implementation. Can you think of a better way to implement this extension method that doesn't expose as much information?"

This allows them to see the faults in what they are developing while at the same time giving them the opportunity to solve the problem they introduced into the application.