What is the best way to prepare to coach a junior in software development? [closed]

Question

I've recently been asked by my superior to coach a junior developer. I'm thrilled about it and love the prospect. I have a bit of experience in coaching a Junior (once in the past) but I would like to up my game and bring the best out of him (and possibly for next Junior for me to coach).

The previous experience was good but unprepared, I looking for an analytical approach and maybe some milestones for the Junior to reach.

How can I best prepare for coaching a junior software developer?

[Edit to answer comments]

It is not as I'm facing a problem per se. I have been very fortunate with my first experience as the Junior was very curious and had a mind very much logic oriented (awesome combination!). My 'coaching' was more about reassuring him about his capabilities and permits his confidence to grow. I'm also very lucky now with the Junior as he is very independent and tend to crack his skulls on problems long enough before asking some help. At the moment, I feel my role is not so much on a technical coaching as a 'work environment' coaching and setting standard of professionalism. I didn't want to go too much into details to not influence the answers but it seems I have to give my own guess and ask for guidance on those:

The answer I would have expected would have been something like that: There should be 3 axis of improvement for a Junior. 1 - The Technical part 2 - The understanding of the (software) shipping flow 3 - Work behaviour

As for the first one, the Junior will be asked to follow the project at hand with precise set of goals to achieve linked with some bonus goals. (Ex. in software engineering, we are making web services so we are expecting basic understanding of the messages flow, actual use of the architecture, etc. Bonus goals would be: challenge of the architecture, recognition of room for improvement part of the code, and implementation of new architecture for a 'in scoped' project)

As for the development in the team, the understanding of the shipping flow is very important (more over if the Junior does not see himself as a long term developer). The understanding of the business, tests, deployment, etc. All of these things have to be integrated full in the first 4 months. Bonus point for pointing out problem in the flow and ways to improve.

Finally, the work ethic. For a Junior to enter a new company will define his behaviour for the rest of his carrer. It's important to spot short coming in communication (verbal, writing etc.) and encourage certain kind of behaviour (sending a mail to re confirm an oral decision for instance). It's also interesting to develop his curiosity toward all of those soft skills as it would greatly help him later.

TLDR; No apparent issue at the moment, just need some overall guidance in coaching. Axis I thought I would follow being:

• Technical part
• Understanding of the (software) shipping flow
• Work behaviour

Answer 1

Coaching a junior is a very delicate task. Each junior is different in how they approach problems, how they arrive at solutions and (more importantly) how they learn. You need to be able to address these things about your junior or at least be very cognizant of them. Some things to look for:

1. Is your junior resistant to new ideas?
2. Does your junior have any specific "tells" that indicate they've just reached their information overload?
3. How does the junior process new information? Are they a linear thinker or do they thrive in a more theoretical thought process?
4. What kind of time will you have to work directly with them versus work you'll expect them to do on their own?
5. How applicable will the coached material be? Will you be doing throw-away projects or real world hands on things?

Since you haven't coached much, be ready to learn. Be receptive to feedback from the junior. When they get frustrated (and they will), don't take it personally. Recognize that it is simply a failure to communicate effectively for both of you. Try something new if that happens.

Anecdotally, I previously had to coach 2 junior developers simultaneously while leading a massive project (to which they were assigned and not necessarily prepared). One of them was very receptive and eager, but she had a finite capacity for new information. The other had incredible capacity for new information but was extremely resistant (I think her favorite word in the world was "No").

In each of them, I had to learn to recognize their signs and learn how to proceed effectively. For the one with information overload, I would simply write down a few instructions regarding the topic, and say, "Ok, that's enough for today. I'm going to let you smash your face on the screen for a little bit. Think about these things in between regular tasks, and we'll come back to it later." Inevitably, 2 or 3 hours later she'd have given it thought, had an epiphany and would be ready to proceed to the next topic. Sometimes we'd have to revisit a topic, but as long as we recognized our communication failures we proceeded well.

The other one was different in that allowing her time to think about it wasn't going to get it done. I had to smash through her resistance with a hammer by just telling her "Ok, type what I tell you to type, and when we're done we'll build it, test it and review it." She'd argue the entire time, but obediently type. When we were done and what we'd built worked (or maybe it didn't sometimes) we would discuss the new technique. I'd let her explain why her way was "better", and then we'd casually go over the technique again and why the new way superseded it. Often it would take a few sessions to cover a topic before she began to embrace it, but once she did she would master it quickly after that.

TLDR; All of your juniors will be different. You have to be the flexible one in order be an effective coach/teacher/leader. Be open to what they need and less concerned with what you might need. If something isn't working, assume it is a problem with your communication. If you're both becoming frustrated, take a break. If you're stuck, seek help from your supervisor/manager or other senior developers who might be good coaches.

As a last resort, ask the Internet.