Assign them small fixes first, and provide feedback through code reviews. When I think they’re ready for bigger tasks like taking ownership of a feature, I ask them to document their design (just a quick informal doc) and talk me through it, and we review it together.
I also used to have informal brown bag sessions for teaching soft skills like how to write emails professionally.
How can I get you as my manager 😅
The soft skills and proper code review would be so nice to be taught. It often feels like walking in the dark with a hand out when it comes to communicating with people and company culture (this is my first tech job)
If you haven’t read it, Clean Code by Robert Martin is a good read for devs. And write code in such a way that you can understand it/explain it if someone asks you how it works 3 years later.
Give them the confidence to fail
**Tasks**
* Start with 'automatable' tasks: give them really easy wins
* Over-define initial tasks, again: more quick wins
* Gradually reduce effort in task definitions
**Autonomy**
* Know when to send a git patch to unblock, and when they should work things out themselves
* Make sure they have an area of the codebase they can feel ownership of
* And make them feel that ownership
* Ask about pairing preferences and explain your reasoning when you work with them
* Know when to answer, and when to tell them "this is a learning experience"
* If you've dug them out a hole, show them, but don't labor the point
**Skills**
* Have a rough roadmap of skills that you want them to improve
* git rebase and debugging are the obvious ones
* bring them in to review your code, pair if possible
----
* Tell them when they do a good job. Informal check-in from time to time
* Give negative feedback, rarely, when warranted and make sure they follow through
Psychological safety: You know you've done a good job when they can come to you and tell you that they made a bad call
Don't take on too many mentees
Letting people fail in a low stakes situation is one of the best learning tools we have.
Even with all my experience, all I do all day long is fail and keep trying different things.
I don't read professionally anywhere near as much as I should, and I'm often disappointed when I do. Search for "Psychological safety" on [hbr.com](http://hbr.com) and pick the good stuff. Apply [Sturgeon's law](https://en.wikipedia.org/wiki/Sturgeon%27s_law) liberally
Find a good mentor who's been through it before, and find a few peers who understand the context of your workplace
I let them fail on their own. I don't correct every little mistake they make. People learn better when the training wheels are off, and they also feel more accountable and responsible. At my current job, when I started I worked under a lead for a little bit as I was onboarding. He spent soooo much time on PRs, correcting so many stylistic things and inane details. We spent hours going over if empty API field responses should be undefined or null. And guess what? His team is terrible. They never get better because they've been so demoralized trying to get through this guys gauntlet of perfectionism.
Point is, let them become individuals with their own style and opinions. The more you control them, the less they will improve. Most people dont learn simply by being told what to do. They have to experience it. No idea if this is what you're doing, but it's the pattern I've noticed when engineers fail to improve.
I personally just don’t think everyone is cut out to be a software engineer like some people like to parade. Some people will just never “get it” no matter how much time you spend with them. I had two juniors I worked with last year, one is absolutely killing it and the other has made essentially no progress.
With that being said, I like to do a lot of paired programming. I’ll usually start off driving and explain my thinking out loud so they can see how I approach problems. Then I’ll let them drive and make them verbalize their thinking out loud and if I notice any flaws/issues with their approach to a problem I’ll address it. I’ll also ask a lot of questions when they’re doing something wrong rather than just telling them, that way they need to think about why what they’re doing may not be right.
Code reviews can be okay, but I think at least with fresh grads you should be essentially knowing exactly what their first few PRs are containing before they even make it to the review stage.
Also identify small areas that they can become a subject matter expert in super early so they can have ownership over something. IMO that really helps teach them a lot about what it means to actually own your code.
You sort of have to experiment, find out how they learn and teach appropriately.
In this case, for whatever reason, pairing isn't working for them. It might be the way you pair or it might be something about their personalities. As an example, if you have never paired it can create a lot of anxiety and our monkey brains have trouble with forming (and retrieving) short term memories when we are anxious. No short term memories leave nothing to turn into a long term memory.
If you pair, you have to ask a lot of questions and modify your strategy accordingly.
Other people learn in a myriad of ways. We have a really odd trend within software organizations. The majority of people who work in software do it because they developed really solid learning strategies on their own and in their own environments. Then they come to work and we tell them to adapt to our styles and chosen environments.
What are they lacking? Clean code? Coding efficiency (knowing git, ide shortcuts, etc.)? Business knowledge? Code domain knowledge? What does "not skilled" mean?
It is going to vary on individual. Some just do what they are told. Those are probably the ones who you see with no progress 6 months later. There are some that genuinely enthusiastic that you give them a project and they spend way too much time that it is considered toxic. You have to curb their enthusiasm when they are putting in 14-16 hours a day; simply because they are that excited.
But a lot of it boils down to interest. The project/task has to be interesting enough and that is usually something out of their wheelhouse. It can be a small task.
I have a recent example of one junior and I gave him a task and he really went all in. It was a post-upload processing. He had this CMS and I uploaded a NASA stock image, 25MB that was like 17,000x17,000 and told him that it is not useable on a webpage. No one is waiting for a 25MB hero image to upload. The main thing I taught him *was the pain point, the why*. That gave him a vested interest in solving a problem versus taking instructions.
I gave him some general hints and a week later, he delivered a full RESTful microservice API that produced multiple versions for desktop, retina 2x , mobile, and even handled HEIC files. He learned more than he needed. Like creating a REST contract, building out the deployment to handle large buffer size, so he learned nginx & k8s ingresses, memory usage for node microservice because images could be 2GB in size. And he learned some bureaucracy like registering his API in the gateway.
I gave him enough latitude and general direction. No hand holding required and that is what works. Just give them the support they need (answering questions like HTTP headers, how to write a Swagger file) but the majority of the work, he did on his own.
I try to give them enough latitude and challenges they can solve on their own. Versus doing the normal factory CRUD assignments.
This is what I did for the juniors on my team (in steps):
1. Reducing the scope of task a lot and focusing on kind of copy pastable stuff. Example are reading a swagger doc and implementing endpoints and types on the frontend. This is mostly to get them familiar with reading the doc and other people code to understand it well enough to slightly modify if necessary
2. Implementing utilities (I need a function that takes this input and does this). This is to get them familiar with the language syntax and tools
3. Pairing a lot when designing a new component API (where do I put the state, what data do I need), and leaving the implementation to them
4. Giving precise specs on a new component, and leaving to them both design and implementation. In this phase I expect a small design docs or message where they discuss their proposed approach
5. Giving vague specs on a new component, and leaving to them scouting the requirement, design and implementation. In this phase I expect them to ask questions to make the requirement well defined. By this point I assume they are autonomous enough on implementation and most of the time is spent in teaching communication.
Also trough the whole process I never spoonfeed a solution to a problem, I always try to give clues and let them think as much as possible, and then ask question to get how much of what they are doing they are really understanding. If I spot some knowledge gap I prefer to fill that before continuing on the task.
(For example they say something that makes me think they do not really understand the data fetching library we are using, I’ll make them read through the relevant piece of the doc, and the types, and then ask if they still think the approach is valid and why)
We are a remote company so during the whole process I spent a lot of time teaching them good efficient communication, starting with basics like the article “how to ask good questions”, and making summaries at the end of discussion on what info they could have included from the start to avoid some back and forth. I also make sure to be clear that they can DM me whenever they feel like to, and that I’m always open to pair if they need some help.
Break it down... try to remember what it was like for you in the beginning. Explain why not just how.
Be prepared to change your approach if it's not working. Maybe they need to be launched on a mini project, let 'em go wrong fast and reel 'em in during code review. I find that sometimes give them both context and some sort of 'ownership' even if it's just a simple bit.
I try to give them well defined tasks that aren't overly complex. As I do their code reviews, I will give suggestions, pointers, and constructive criticism until it is up to snuff. I've tried the learning by osmosis route as well, but it never seemed to work out.
Some fraction of the work you assign to juniors must be on the cusp of too difficult for them to handle. Let them struggle, but don’t let them drown. Breaks between to find their footing again.
I like some of the other suggestions in here.
Something I would add is find a book that you think will help them in whatever skills they're missing. Then do a reading group with them. Read a few chapters every week and then meet up for 30-45 minutes to discuss. Make sure they're coming with questions and/or topics to discuss themselves. On top of learning something new it's a great way to feel more connected to your colleagues.
Assign them small fixes first, and provide feedback through code reviews. When I think they’re ready for bigger tasks like taking ownership of a feature, I ask them to document their design (just a quick informal doc) and talk me through it, and we review it together. I also used to have informal brown bag sessions for teaching soft skills like how to write emails professionally.
How can I get you as my manager 😅 The soft skills and proper code review would be so nice to be taught. It often feels like walking in the dark with a hand out when it comes to communicating with people and company culture (this is my first tech job)
My goal in my professional life is to not have to say “oh god, no” or “wtf” when I read my direct reports’ work or email 😅.
And quick tips for a newbie?
If you haven’t read it, Clean Code by Robert Martin is a good read for devs. And write code in such a way that you can understand it/explain it if someone asks you how it works 3 years later.
Give them the confidence to fail **Tasks** * Start with 'automatable' tasks: give them really easy wins * Over-define initial tasks, again: more quick wins * Gradually reduce effort in task definitions **Autonomy** * Know when to send a git patch to unblock, and when they should work things out themselves * Make sure they have an area of the codebase they can feel ownership of * And make them feel that ownership * Ask about pairing preferences and explain your reasoning when you work with them * Know when to answer, and when to tell them "this is a learning experience" * If you've dug them out a hole, show them, but don't labor the point **Skills** * Have a rough roadmap of skills that you want them to improve * git rebase and debugging are the obvious ones * bring them in to review your code, pair if possible ---- * Tell them when they do a good job. Informal check-in from time to time * Give negative feedback, rarely, when warranted and make sure they follow through Psychological safety: You know you've done a good job when they can come to you and tell you that they made a bad call Don't take on too many mentees
Letting people fail in a low stakes situation is one of the best learning tools we have. Even with all my experience, all I do all day long is fail and keep trying different things.
Thanks for your response! Can you please recommend any good books for newbie team leads?
I don't read professionally anywhere near as much as I should, and I'm often disappointed when I do. Search for "Psychological safety" on [hbr.com](http://hbr.com) and pick the good stuff. Apply [Sturgeon's law](https://en.wikipedia.org/wiki/Sturgeon%27s_law) liberally Find a good mentor who's been through it before, and find a few peers who understand the context of your workplace
Let them work on their own more.
I let them fail on their own. I don't correct every little mistake they make. People learn better when the training wheels are off, and they also feel more accountable and responsible. At my current job, when I started I worked under a lead for a little bit as I was onboarding. He spent soooo much time on PRs, correcting so many stylistic things and inane details. We spent hours going over if empty API field responses should be undefined or null. And guess what? His team is terrible. They never get better because they've been so demoralized trying to get through this guys gauntlet of perfectionism. Point is, let them become individuals with their own style and opinions. The more you control them, the less they will improve. Most people dont learn simply by being told what to do. They have to experience it. No idea if this is what you're doing, but it's the pattern I've noticed when engineers fail to improve.
I personally just don’t think everyone is cut out to be a software engineer like some people like to parade. Some people will just never “get it” no matter how much time you spend with them. I had two juniors I worked with last year, one is absolutely killing it and the other has made essentially no progress. With that being said, I like to do a lot of paired programming. I’ll usually start off driving and explain my thinking out loud so they can see how I approach problems. Then I’ll let them drive and make them verbalize their thinking out loud and if I notice any flaws/issues with their approach to a problem I’ll address it. I’ll also ask a lot of questions when they’re doing something wrong rather than just telling them, that way they need to think about why what they’re doing may not be right. Code reviews can be okay, but I think at least with fresh grads you should be essentially knowing exactly what their first few PRs are containing before they even make it to the review stage. Also identify small areas that they can become a subject matter expert in super early so they can have ownership over something. IMO that really helps teach them a lot about what it means to actually own your code.
You sort of have to experiment, find out how they learn and teach appropriately. In this case, for whatever reason, pairing isn't working for them. It might be the way you pair or it might be something about their personalities. As an example, if you have never paired it can create a lot of anxiety and our monkey brains have trouble with forming (and retrieving) short term memories when we are anxious. No short term memories leave nothing to turn into a long term memory. If you pair, you have to ask a lot of questions and modify your strategy accordingly. Other people learn in a myriad of ways. We have a really odd trend within software organizations. The majority of people who work in software do it because they developed really solid learning strategies on their own and in their own environments. Then they come to work and we tell them to adapt to our styles and chosen environments.
What are they lacking? Clean code? Coding efficiency (knowing git, ide shortcuts, etc.)? Business knowledge? Code domain knowledge? What does "not skilled" mean?
It is going to vary on individual. Some just do what they are told. Those are probably the ones who you see with no progress 6 months later. There are some that genuinely enthusiastic that you give them a project and they spend way too much time that it is considered toxic. You have to curb their enthusiasm when they are putting in 14-16 hours a day; simply because they are that excited. But a lot of it boils down to interest. The project/task has to be interesting enough and that is usually something out of their wheelhouse. It can be a small task. I have a recent example of one junior and I gave him a task and he really went all in. It was a post-upload processing. He had this CMS and I uploaded a NASA stock image, 25MB that was like 17,000x17,000 and told him that it is not useable on a webpage. No one is waiting for a 25MB hero image to upload. The main thing I taught him *was the pain point, the why*. That gave him a vested interest in solving a problem versus taking instructions. I gave him some general hints and a week later, he delivered a full RESTful microservice API that produced multiple versions for desktop, retina 2x , mobile, and even handled HEIC files. He learned more than he needed. Like creating a REST contract, building out the deployment to handle large buffer size, so he learned nginx & k8s ingresses, memory usage for node microservice because images could be 2GB in size. And he learned some bureaucracy like registering his API in the gateway. I gave him enough latitude and general direction. No hand holding required and that is what works. Just give them the support they need (answering questions like HTTP headers, how to write a Swagger file) but the majority of the work, he did on his own. I try to give them enough latitude and challenges they can solve on their own. Versus doing the normal factory CRUD assignments.
This is what I did for the juniors on my team (in steps): 1. Reducing the scope of task a lot and focusing on kind of copy pastable stuff. Example are reading a swagger doc and implementing endpoints and types on the frontend. This is mostly to get them familiar with reading the doc and other people code to understand it well enough to slightly modify if necessary 2. Implementing utilities (I need a function that takes this input and does this). This is to get them familiar with the language syntax and tools 3. Pairing a lot when designing a new component API (where do I put the state, what data do I need), and leaving the implementation to them 4. Giving precise specs on a new component, and leaving to them both design and implementation. In this phase I expect a small design docs or message where they discuss their proposed approach 5. Giving vague specs on a new component, and leaving to them scouting the requirement, design and implementation. In this phase I expect them to ask questions to make the requirement well defined. By this point I assume they are autonomous enough on implementation and most of the time is spent in teaching communication. Also trough the whole process I never spoonfeed a solution to a problem, I always try to give clues and let them think as much as possible, and then ask question to get how much of what they are doing they are really understanding. If I spot some knowledge gap I prefer to fill that before continuing on the task. (For example they say something that makes me think they do not really understand the data fetching library we are using, I’ll make them read through the relevant piece of the doc, and the types, and then ask if they still think the approach is valid and why) We are a remote company so during the whole process I spent a lot of time teaching them good efficient communication, starting with basics like the article “how to ask good questions”, and making summaries at the end of discussion on what info they could have included from the start to avoid some back and forth. I also make sure to be clear that they can DM me whenever they feel like to, and that I’m always open to pair if they need some help.
Break it down... try to remember what it was like for you in the beginning. Explain why not just how. Be prepared to change your approach if it's not working. Maybe they need to be launched on a mini project, let 'em go wrong fast and reel 'em in during code review. I find that sometimes give them both context and some sort of 'ownership' even if it's just a simple bit.
I try to give them well defined tasks that aren't overly complex. As I do their code reviews, I will give suggestions, pointers, and constructive criticism until it is up to snuff. I've tried the learning by osmosis route as well, but it never seemed to work out.
Some fraction of the work you assign to juniors must be on the cusp of too difficult for them to handle. Let them struggle, but don’t let them drown. Breaks between to find their footing again.
throw them into the fire with a water hose attached to your hip.
We don't hire juniors
I like some of the other suggestions in here. Something I would add is find a book that you think will help them in whatever skills they're missing. Then do a reading group with them. Read a few chapters every week and then meet up for 30-45 minutes to discuss. Make sure they're coming with questions and/or topics to discuss themselves. On top of learning something new it's a great way to feel more connected to your colleagues.