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

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
5
down vote

favorite
2












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






share|improve this question














closed as too broad by Garrison Neely, Stephan Kolassa, Telastyn, gnat, user8365 Feb 3 '15 at 15:42


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.














  • possible duplicate of How do your busiest people transfer their knowledge?
    – gnat
    Feb 3 '15 at 14:57






  • 1




    @gnat: This question is about how to coach. The question you've linked to isn't even close to a duplicate.
    – Joel Etherton
    Feb 3 '15 at 14:59











  • The question is still on hold even if I tried to narrow the spectrum with a field and maybe some directions (milestone). Can somebody help me unlock the question please?
    – François Gautier
    Feb 6 '15 at 12:10






  • 1




    I edited your post to focus on the problem of being unprepared. If you can explain why you felt unprepared and maybe describe the problem you faced in your last mentoring session, I think we may be able to narrow down the exact problem you're facing. Hope this helps you get started!
    – jmort253♦
    Feb 12 '15 at 13:39










  • I hope I made my questions clearer. Please react to help me unlock the question.
    – François Gautier
    Feb 17 '15 at 14:48
















up vote
5
down vote

favorite
2












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






share|improve this question














closed as too broad by Garrison Neely, Stephan Kolassa, Telastyn, gnat, user8365 Feb 3 '15 at 15:42


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.














  • possible duplicate of How do your busiest people transfer their knowledge?
    – gnat
    Feb 3 '15 at 14:57






  • 1




    @gnat: This question is about how to coach. The question you've linked to isn't even close to a duplicate.
    – Joel Etherton
    Feb 3 '15 at 14:59











  • The question is still on hold even if I tried to narrow the spectrum with a field and maybe some directions (milestone). Can somebody help me unlock the question please?
    – François Gautier
    Feb 6 '15 at 12:10






  • 1




    I edited your post to focus on the problem of being unprepared. If you can explain why you felt unprepared and maybe describe the problem you faced in your last mentoring session, I think we may be able to narrow down the exact problem you're facing. Hope this helps you get started!
    – jmort253♦
    Feb 12 '15 at 13:39










  • I hope I made my questions clearer. Please react to help me unlock the question.
    – François Gautier
    Feb 17 '15 at 14:48












up vote
5
down vote

favorite
2









up vote
5
down vote

favorite
2






2





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






share|improve this 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








share|improve this question













share|improve this question




share|improve this question








edited Feb 13 '15 at 12:49

























asked Feb 3 '15 at 14:28









François Gautier

1,041818




1,041818




closed as too broad by Garrison Neely, Stephan Kolassa, Telastyn, gnat, user8365 Feb 3 '15 at 15:42


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.






closed as too broad by Garrison Neely, Stephan Kolassa, Telastyn, gnat, user8365 Feb 3 '15 at 15:42


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.













  • possible duplicate of How do your busiest people transfer their knowledge?
    – gnat
    Feb 3 '15 at 14:57






  • 1




    @gnat: This question is about how to coach. The question you've linked to isn't even close to a duplicate.
    – Joel Etherton
    Feb 3 '15 at 14:59











  • The question is still on hold even if I tried to narrow the spectrum with a field and maybe some directions (milestone). Can somebody help me unlock the question please?
    – François Gautier
    Feb 6 '15 at 12:10






  • 1




    I edited your post to focus on the problem of being unprepared. If you can explain why you felt unprepared and maybe describe the problem you faced in your last mentoring session, I think we may be able to narrow down the exact problem you're facing. Hope this helps you get started!
    – jmort253♦
    Feb 12 '15 at 13:39










  • I hope I made my questions clearer. Please react to help me unlock the question.
    – François Gautier
    Feb 17 '15 at 14:48
















  • possible duplicate of How do your busiest people transfer their knowledge?
    – gnat
    Feb 3 '15 at 14:57






  • 1




    @gnat: This question is about how to coach. The question you've linked to isn't even close to a duplicate.
    – Joel Etherton
    Feb 3 '15 at 14:59











  • The question is still on hold even if I tried to narrow the spectrum with a field and maybe some directions (milestone). Can somebody help me unlock the question please?
    – François Gautier
    Feb 6 '15 at 12:10






  • 1




    I edited your post to focus on the problem of being unprepared. If you can explain why you felt unprepared and maybe describe the problem you faced in your last mentoring session, I think we may be able to narrow down the exact problem you're facing. Hope this helps you get started!
    – jmort253♦
    Feb 12 '15 at 13:39










  • I hope I made my questions clearer. Please react to help me unlock the question.
    – François Gautier
    Feb 17 '15 at 14:48















possible duplicate of How do your busiest people transfer their knowledge?
– gnat
Feb 3 '15 at 14:57




possible duplicate of How do your busiest people transfer their knowledge?
– gnat
Feb 3 '15 at 14:57




1




1




@gnat: This question is about how to coach. The question you've linked to isn't even close to a duplicate.
– Joel Etherton
Feb 3 '15 at 14:59





@gnat: This question is about how to coach. The question you've linked to isn't even close to a duplicate.
– Joel Etherton
Feb 3 '15 at 14:59













The question is still on hold even if I tried to narrow the spectrum with a field and maybe some directions (milestone). Can somebody help me unlock the question please?
– François Gautier
Feb 6 '15 at 12:10




The question is still on hold even if I tried to narrow the spectrum with a field and maybe some directions (milestone). Can somebody help me unlock the question please?
– François Gautier
Feb 6 '15 at 12:10




1




1




I edited your post to focus on the problem of being unprepared. If you can explain why you felt unprepared and maybe describe the problem you faced in your last mentoring session, I think we may be able to narrow down the exact problem you're facing. Hope this helps you get started!
– jmort253♦
Feb 12 '15 at 13:39




I edited your post to focus on the problem of being unprepared. If you can explain why you felt unprepared and maybe describe the problem you faced in your last mentoring session, I think we may be able to narrow down the exact problem you're facing. Hope this helps you get started!
– jmort253♦
Feb 12 '15 at 13:39












I hope I made my questions clearer. Please react to help me unlock the question.
– François Gautier
Feb 17 '15 at 14:48




I hope I made my questions clearer. Please react to help me unlock the question.
– François Gautier
Feb 17 '15 at 14:48










1 Answer
1






active

oldest

votes

















up vote
6
down vote













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.






share|improve this answer




















  • Fabulous answer! +1 for "All of you juniors will be different". Everyone processes things differently and being able to identify how they learn is extremely important.
    – Brian
    Feb 3 '15 at 14:54










  • I wish my manager would think like you, or far from it, atleast read things like this before coaching someone.
    – user1502
    Feb 4 '15 at 17:25






  • 1




    @user1502: One of the huge problems with coaching is the implication that simply knowing the subject matter is enough. Patience and communication are what make a good coach, not subject expertise, but many people seem to feel that because they're experts they should also be coaches.
    – Joel Etherton
    Feb 4 '15 at 17:28

















1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
6
down vote













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.






share|improve this answer




















  • Fabulous answer! +1 for "All of you juniors will be different". Everyone processes things differently and being able to identify how they learn is extremely important.
    – Brian
    Feb 3 '15 at 14:54










  • I wish my manager would think like you, or far from it, atleast read things like this before coaching someone.
    – user1502
    Feb 4 '15 at 17:25






  • 1




    @user1502: One of the huge problems with coaching is the implication that simply knowing the subject matter is enough. Patience and communication are what make a good coach, not subject expertise, but many people seem to feel that because they're experts they should also be coaches.
    – Joel Etherton
    Feb 4 '15 at 17:28














up vote
6
down vote













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.






share|improve this answer




















  • Fabulous answer! +1 for "All of you juniors will be different". Everyone processes things differently and being able to identify how they learn is extremely important.
    – Brian
    Feb 3 '15 at 14:54










  • I wish my manager would think like you, or far from it, atleast read things like this before coaching someone.
    – user1502
    Feb 4 '15 at 17:25






  • 1




    @user1502: One of the huge problems with coaching is the implication that simply knowing the subject matter is enough. Patience and communication are what make a good coach, not subject expertise, but many people seem to feel that because they're experts they should also be coaches.
    – Joel Etherton
    Feb 4 '15 at 17:28












up vote
6
down vote










up vote
6
down vote









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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










answered Feb 3 '15 at 14:46









Joel Etherton

8,1062838




8,1062838











  • Fabulous answer! +1 for "All of you juniors will be different". Everyone processes things differently and being able to identify how they learn is extremely important.
    – Brian
    Feb 3 '15 at 14:54










  • I wish my manager would think like you, or far from it, atleast read things like this before coaching someone.
    – user1502
    Feb 4 '15 at 17:25






  • 1




    @user1502: One of the huge problems with coaching is the implication that simply knowing the subject matter is enough. Patience and communication are what make a good coach, not subject expertise, but many people seem to feel that because they're experts they should also be coaches.
    – Joel Etherton
    Feb 4 '15 at 17:28
















  • Fabulous answer! +1 for "All of you juniors will be different". Everyone processes things differently and being able to identify how they learn is extremely important.
    – Brian
    Feb 3 '15 at 14:54










  • I wish my manager would think like you, or far from it, atleast read things like this before coaching someone.
    – user1502
    Feb 4 '15 at 17:25






  • 1




    @user1502: One of the huge problems with coaching is the implication that simply knowing the subject matter is enough. Patience and communication are what make a good coach, not subject expertise, but many people seem to feel that because they're experts they should also be coaches.
    – Joel Etherton
    Feb 4 '15 at 17:28















Fabulous answer! +1 for "All of you juniors will be different". Everyone processes things differently and being able to identify how they learn is extremely important.
– Brian
Feb 3 '15 at 14:54




Fabulous answer! +1 for "All of you juniors will be different". Everyone processes things differently and being able to identify how they learn is extremely important.
– Brian
Feb 3 '15 at 14:54












I wish my manager would think like you, or far from it, atleast read things like this before coaching someone.
– user1502
Feb 4 '15 at 17:25




I wish my manager would think like you, or far from it, atleast read things like this before coaching someone.
– user1502
Feb 4 '15 at 17:25




1




1




@user1502: One of the huge problems with coaching is the implication that simply knowing the subject matter is enough. Patience and communication are what make a good coach, not subject expertise, but many people seem to feel that because they're experts they should also be coaches.
– Joel Etherton
Feb 4 '15 at 17:28




@user1502: One of the huge problems with coaching is the implication that simply knowing the subject matter is enough. Patience and communication are what make a good coach, not subject expertise, but many people seem to feel that because they're experts they should also be coaches.
– Joel Etherton
Feb 4 '15 at 17:28


Comments

Popular posts from this blog

What does second last employer means? [closed]

Installing NextGIS Connect into QGIS 3?

One-line joke