Ask HN: Strategies for mentoring junior developers?

[PaulStatezny]

Software development companies are often willing to hire developers who need a lot of guidance and direction. (Developers who can’t excel without help.) But a large segment of these companies have no strategy or program in place to help such developers reach proficiency and independence.

What are some good, holistic approaches for helping train up-and-coming developers all the way to “senior developer” skill level?

[bertil]

Junior developers and newbie in general have one incredible quality: they don’t know and they are not supposed to. You absolutely want to tell them that their role is to criticise and occasionally write the documentation. Start from things that are obvious and leverage their question: anything they ask, tell them it’s now their role to document it. How the business makes money, what that metric means, what is TDD, what happens with this fails, whether the company actually ships bug-free code.

One pattern that I use:

- pair program initially; I would do that even for principal, just to be familiar with the code base, but for probably one or two days, after that, they should be autonomous; for very junior developers, a week make more sense, but rarely more;

- gradually replace that with code review, but more than once a day for more junior people; ask them kindly to commit; make sure to point out one or two issues in each very small PR: linting, method naming convention, then testing patterns, structure, etc.

- have scheduled 30 minutes 1:1 meetings, preferably thrice or twice a week; make sure there is something nice at some of those: ice cream, walk out if it’s sunny, and have that meeting have four very explicit parts: what they have done, what blocked them; what they have learned; what they have taught (or documented). The last one is often overlooked but it’s very important for them to realise that they start owning some code, that they should think not of they direct impact but how to empower people. React to blockages by offering solutions, both from them and from you: they need to learn to unblock and that’s how you do it. Move that meeting to once a week for senior developer, once a fortnight for principals.

[humanrebar]

> ...make sure to point out one or two issues in each very small PR...

And try to bring up one or two improvements or good ideas. Being a proper critic involves praising things as well as panning them. If they weren't good at something, you wouldn't have hired them.

If the entire review is straightforward an unsurprising, that's actually a good thing. Say it's very clear and easy to work with.

[afarrell]

> anything they ask, tell them it’s now their role to document it.

Depending on how you interpret it, this advice is either great or terrible. If you read this to mean that the new person to a project should start out by documenting the things they don't know, then this is bad:

- There are definitely Open Source projects which have this attitude and don't write user-facing documentation, expecting new-joiners to write it. This makes it both hard for a new person to join a project and hard for the project to market itself.

- If you are just starting out on a project, it can be hard to know what are the key concepts that a person should really know in order to be efficient and what is incidental. It may or may not be a good idea for them to spend a bunch of time documenting ways in which your test setup uses selenium after running into some really weird end-to-end test bug.

- If you don't know something, it is really hard to write a coherent explanation of it. You have to both empathize with ignorance and have the knowledge. Otherwise, you can just end up stuck/lost. If you don't have anyone willing to help you un-stick yourself...

But that doesn't sound like the interpretation you mean.

From the rest of your post, it very much sounds like you mean that the new person should turn a vocal explanation into a written one as a way of both confirming their knowledge and passing it on to others. This sounds great. It will generate lots of draft docs though, so you probably need some habit or person to keep them organized and keep them from getting stale.

[mdn0420]

In my experience, pair program is especially valuable for learning workflow, tools, debugging tricks, etc. For instance, I remember learning how to efficiently navigate a project with an IDE through pair programming. For ramping up on codebase/architecture, I prefer a brain dump then go off on my own and ask questions as needed. Every person has their own method and preferences of course.

[bpowell]

One of the best ways I found is to hire in pairs. Don't just hire one junior (or entry level) at a time. Hire two or more at once so they can help each other learn your stack. At the university I work at, this is how we handle it. We hire a lot of students to help develop our application. These students are far from entry level when we hire them. Most have taken maybe one CS class at the university level.

It takes a lot of time to mentor these students, so one of the ways we handle that is have some of the more "seasoned" student developers help train. This works out very well for us, in that we have two seasoned student developers that help train the four fresh students we have. The questions that the newly hired students have can generally be answered by another student, because they probably had the same problem. While these seasoned students help out a lot, I still have to spend time mentoring and training. Be prepared to spend more time than what you think, but the rewards pay off in the end.

Also it helps if you find what the developer is passionate about and maybe find work that aligns well with that. We had a former student that once we found out they wanted to do iOS development, we put them on that task and they really shined. It does take some work to find out what they want to get into, but it has worked well for us.

As for getting up to the "senior developer" skill level, that is not something that we have baked into our student program. Once a student graduates, they can no longer work with us. It takes more than the typical 4-5 years to graduate university to hit that level.

[monocasa]

As somone who started the same day as another junior developer in my first job, I second this.

Just having someone who's also junior who you don't feel any shame about asking stupid questions to is killer. You shouldn't feel any shame either way, but that's sort of one of the things you learn transitioning out of a junior role.

[lambda_lover]

My employer does a 3-month training program that covers our full development stack, which is rather specialized for our industry.

My first team didn't use any of those technologies. But the 30-some fellow students in the training program have become some of my closest friends and, in some cases, trusted teammates and mentors/mentees with various technologies.

Peers are an absolutely underrated part of the mentorship puzzle, and I'm glad your company takes strides to incorporate peer learning even at a small scale.

[dbg31415]

I like the suggestions to hire more than one at a time. But, realistically, it's not always possible -- budget, timing (you may need to stagger hiring), different projects... lots of reasons that may not work.

Regardless, there are other things that will work well for any team:

1) Dedicate time with experienced staff for meaningful code reviews. Everyone should have their code reviewed, and review other code -- senior reviews junior, junior reviews senior -- and 1:1 time to talk through every code commit. This shouldn't be just a "training" exercise, this should be ongoing.

2) Dedicate time for sprint retrospectives. Get feedback, give feedback, and make sure bad behavior isn't being pushed on to junior folks. If you see process flaws, or know you cut corners -- call it out as something to improve on next time. Make sure the juniors know what's good to do, vs. what we have to do to meet deadlines. They're going to follow the examples we set.

3) Dedicate time for "group therapy" sessions for devs. We have a once a week meeting where the only people in the room are devs; just a time for devs to talk about issues they see with the code, project, company -- so the juniors know it's not just a "junior" issue, and other people can weigh in on how they solved similar issues. Make sure to set the expectation that it's totally OK if people don't have solutions for everything.

[theyinwhy]

What you describe here is the core essence of the Montessori teaching method: https://en.m.wikipedia.org/wiki/Montessori_education

Very interesting to see this applied at a university level!

[songzme]

Don't write code. Break down a feature into tasks that you would take 30 mins or less to accomplish. Have them build each task one by one. If they take longer than 1 hour, you know that they are stuck on something so you can go help them. While they are working on 1 task, you are figuring out the next 2 tasks. Your job becomes quick prototyping to make sure the tasks are feasible.

Eventually, after many small merge requests, junior developers will be comfortable to take up entire features. After a few features, you teach them how to break down tasks for other junior devs, just like what you were doing before.

We have been actively following this method for the past 2 years and have taught engineers with 0 coding background all the way to become tech leads in our org.

[jbhouse]

Sounds super interesting, though it's not something I've heard of before. Is this a common practice I haven't heard of or a process unique to your company?

[muzani]

Pair programming for sure. Senior designs the code, junior writes it. Senior doesn't touch keyboard. It's real time code reviewing.

The senior's time is rarely wasted. They can always do time consuming high level work like designing test cases, planning out the next part of the work, seeing if the API supports stuff.

[ctvo]

Pair programming works for specific people, for others it's an exercise in anxiety. Especially in the scenario you're suggesting with a senior watching a junior write code.

[nunez]

Your company has to have the right culture for this. Companies like this are rare. Most just assign whatever's in the queue to whomever's going to take it, meaning that everyone has "something" to do at all times.

[donttrack]

I would leave, if someone made me do pair programming.

[nerdy]

How you mentor has a lot to do with the particular topic and the relative knowledge and skill levels of the people involved.

For example, if you're trying to teach TDD strategy then pairing might be best because there's a lot of nuance to how things are done. Environment setup. Tests come first. Make sure all the tests pass before moving on. Refactor between. So for TDD it would be difficult to provide a big list of dos and don'ts and expect someone to navigate them.

Some skills are contextually less rigid than TDD. Debugging a problem for example: if a developer is trying to use an internal API but they are getting a timeout response instead of any actual output. You could simply tell them to see if the HTTP server is running, but it's probably better to ask questions and explore the problem vicariously. "What do you think the problem could be?" Then you can arrive at gaps in their understanding about how the system or HTTP servers work.

Asking questions when there's that too-familiar "we've gotta get this stuff done" atmosphere can be challenging. It's tempting as a senior developer to just provide the answer without slowing down and exploring the problem with your junior counterpart.

There's also institutional teaching. Is the junior developer asking questions which should be addressed in documentation? If so, you should probably commit those answers to the documentation and have the developer act as a litmus test for the completeness of the information.

So teaching can be showing, sometimes it's a matter of explaining, and other times it's more important to just ask the right questions. I think one of the most important parts of teaching is perspective-taking. You want to explore the areas just adjacent to the person's knowledge.

Also, blameless postmortems. It's easy to point fingers when shit goes wrong. Don't.

Developers junior to me ask questions which I find border on alarming sometimes but I suppress that reaction because I would rather fill those dangerous gaps than have a developer be too scared to ask.

[Hydraulix989]

The best thing to do is teach them to dig into problems, learn on their own, and think for themselves. They will have to learn how to deal with missing documentation and unclear/messy code. They will have to learn how to unblock themselves when they are blocked, rather than just getting stuck. They will have to learn how to work around obstacles and think outside the box whenever the immediate initial solution that comes to mind turns out to not be a working one.

Coworkers shouldn't be treated as StackOverflow unless absolutely last resort because it is incredibly distracting to answer mentees' easily-Googled questions about built-in language API calls every 15 minutes or so. A lot of programming is just professional Googling. Once they can function independently, they are no longer junior developers IMO, but this is a learned skill.

When I started programming, I had enough people on IRC berating and insulting me for asking about standard C library calls that I learned how to research and solve my own problems the hard way (the acronym "RTFM" is toxic). It felt awful, and I can imagine a lot of people getting discouraged and just giving up.

I was in high school trying to write my own malloc just for fun, and random strangers on the Internet kept calling me an "idiot" because I was still learning pointer arithmetic and needed help (and nobody IRL could help me).

[DougWebb]

I've always been a fan of assigning maintenance tasks to junior devs (or anyone who's new to an existing codebase.) These are tasks that are often lower priority so there is less time pressure to get them done right, and they give the devs the opportunity to learn the codebase. Working on existing code you don't know yet is also a lot easier than new development on code you don't know (and coding standards you don't know), so that makes it a better introduction for the new devs too.

[ManlyBread]

I understand the rationale, but after getting the "maintenance" role a few times it feels me with dread. Usually when I get maintenance tasks it's for a system no one else wants / dares to touch. Evey time I feel like someone punched me in the face because it's always accompanied with the words like "we need someone else to know this system", "it's only for a little while" and the truth is that if you gain minimum competency in such a system you can say goodbye to more fun tasks - the maintenance of this old crap is your life now. No company will let someone with a knowledge of some obscure shit stop maintaining the obscure shit and move that person to a project that doesn't suck. Currently this is the 4th time I'm tied up in such a situation and while I was promised to be allowed to work on the "more fun" project "after 6 months so I can get my feet wet" the very last day of these six months I was told that one guy is leaving the company and that I can't work on the fun project because the obscure shit won't have enough manpower. The corporate machine works so slow that it will take at least another six months before someone gets hired. Hell, they're so incompetent that they don't even have a job posting yet.

[chrisper]

This works, but guidance is needed otherwise frustration and demotivation could occur. New developers need to be told that it is ok to not figure out everything right away and asking for the solution is not "failure" but rather part of the learning.

[b3arlythere]

As a Junior - Intermediate Dev, I'd say these are usually pretty good places to start. These usually give the codebase some easy wins and help the junior build up confidence.

In addition, since they're not part of the main project, it's not very stressful on the junior's side (assuming they realize that their work isn't blocking or holding up someone else). Probably one of the most stressful things I remember is trying to get up to speed as quickly as possible since I felt like I was holding back the work.

[stronglikedan]

Not to mention the smaller chunks of code to be reviewed, which has it's own set of benefits.

[sixhobbits]

I've seen several people mentioning pair programming, which I haven't found useful (too much time wasted while one person is coding the "easy" parts, and not enough time for the more experienced person to think about the difficult parts. YMMV.)

In my experience, the most helpful way is

1) code review. Several iterations of all new code. Efficiency, style, correctness, smaller functions, don't repeat code. This takes time, and as the person doing the reviews, you might feel like you aren't getting anywhere, but a few months done the line it will be very rewarding when it finally "clicks".

2) Looking at code and theory in 1:1s. Normally I spend about 10-30 minutes on HR type stuff and the rest of the ~1h 1:1 is spent on training/mentorship. Sometimes looking at specific code reviews and explaining reasoning behind the comments in more details. Sometimes it's to fill in gaps in the person's theoretical knowledge about syntax, algorithms, style, unit tests, caching, whatever weaknesses were identified.

1:1 time and code-review should form the basis of all coding education at all levels IMO.

Shameless plug for HyperionDev[0], the coding bootcamp provider I'm working with where we focus on 1:1 time and code review both for our customers and for our dev team.

[0] https://www.hyperiondev.com

[therapeutic]

As a junior dev, I've appreciated small signs that other people in the office are looking out for me and my progress. This can be anything from regular one on ones with my direct manager, to other engineers asking if I have any questions when working in a new codebase. I'm the only junior in my office, so at first it was kind of horrifying asking questions and looking for help. Since other people have been more proactive in making sure I'm set up properly I've felt a lot more confident in taking steps on my own to figure things out and I think it's helped a lot.

[Dannymetconan]

As a junior dev one aspect of mentoring which I have always valued is being given time to explain to a senior dev how I am about to go about implementing a solution. This coupled with feedback on how I should change my code and why is great.

[Jach]

I think the lack of explicit programs is because the path is often "stick around long enough to have enough things you can point to that look similar in complexity / effort as other things people with the Senior title have done." If all those things require relatively little hand-holding then the solution is just progressively less and less hand-holding, often in the form of "toss them in the deep end and only go hold their hand once they ask for it". That has some negative incentive structure of course, but so do other suggestions proposed here...

Maybe instead focus the mentoring on becoming a better dev. Have them join your book club (or paper club, talk club, blog club, whatever) that you in theory already have going on where engineers at whatever levels get together and discuss a topic and how it can be applied to make them better engineers or have better team dynamics etc. Maybe do some applying exercises / experiments too.

The "junior" and "senior" distinction isn't very important beyond salary negotiation, and often the "needs guidance to excel" or "not fairly independent yet" criteria can be misleading too because it's somewhat sensitive to the work and work environment in question. If you really want to mentor a junior into a senior you just need to make them more like the what-does-this-company-mean-by-senior person, which might not correlate very well with good engineering at all and can differ quite dramatically from company to company.

[ccccccccccccc]

As a junior dev, keep us on the edge of just enough work and too much work. Too little work seems to cause disdain of the company (questioning why we were even hired) among my other junior peers. On the other hand, too much work causes us to burn out too quickly since we are still solidifying our time management and prioritization skills.

[d0paware]

I think probably one of the most valuable things you can do with your junior developers is to set expectations around how to ask good questions. Your goal is to help juniors strike the right balance between spending time figuring something out on their own versus spending too much time and going way off track. You also don't want your juniors to ask too many questions that they should have first spent some time investigating on their own.

There's a good link on this: How to Ask Good Questions (https://news.ycombinator.com/item?id=13293301)

Other than that, I think having a junior shadow you while you debug a bug or help them debug one of theirs while explaining each step you are doing is also very helpful.

Something else that's pretty good is to give juniors a shining example of a high quality SPIKE task on a new technology or design consideration. You want them to learn by example.

And here are some other links that I've found personally helpful: https://softwareengineering.stackexchange.com/questions/1383...

For you:

Ask HN: How to manage developers who "aren't very good" (because let's be honest, we've all had this sentiment before whether or not the developers were actually bad or not) https://news.ycombinator.com/item?id=9008845

For your juniors, to give them something to aspire to:

On Being a Mature Engineer https://www.kitchensoap.com/2012/10/25/on-being-a-senior-eng...

Ask HN: How to Be a Good Technical Lead? https://news.ycombinator.com/item?id=10395046

[rdsubhas]

(assuming mentoring them with the objective of becoming "engineers" rather than staying developers)

Many code pairing/reviewing strategies assume that the mentor is the one who has to teach everything on the job. Its not true, it slows everyone down and leads to "lots of talking" and less coding.

Don't by shy of making them have a follow up learning checklist. When you are pairing or reviewing, leave them links that have helped you on the past, or give them concepts that they should learn in order to more effectively do the same task. The next day, ask them if they have had a chance. Not as a way of "control", its totally fine if they don't, and its also totally fine if they have "glanced through" theoretically. If they are eager to learn, they'll be asking you more questions back, and you can fill in the gaps (or point in more directions). Its as much an effort of the mentee as the mentor.

Junior developers often just need "direction" because they don't know what they don't know. But they're quick to explore further only if pointed the way. Give them the resources they need to learn, not necessarily the learning itself and keep following up. Contrary to many opinions, juniors like having tough mentors (which is why mentor should not be a reporting figure).

Communication and social skills are a large part of development. You should also be guiding them specific to the organization context, whom to reach for what, how to communicate better in different circumstances, how to reinforce basics (writing tests), make them present something they learned, help them build visibility by attending meetups, how to make decisions on technology, how everything has tradeoffs, how to negotiate their salary, how to talk product stuff with product (biz to biz, qa to qa, executive to executives), how to escalate from personal > IM > emails > calls > meetings, habits like task tracking and learning to estimate by slowly working on complexity points and matching up with their "self velocity", how to say no to more tasks and avoiding burnout, etc.

The mentor only provides useful guidance, but in the end, the execution is up to the junior and the context of the problem they're working on. Ideally they should also not be having one mentor, but many with different styles and opinions.

[Insanity]

You can ignore pretty much everything I wrote underneath, but if one thing, I feel like this video really helped me as a senior engineer: https://www.youtube.com/watch?v=m6G8f9pZZRM&t=1594s

Don't see them as a 'nuisance' or something that's not "part of your job". As a senior developer, it is at least implicitly part of your job to mentor junior developers.

It helps to really take out time to help them, I schedule some sessions in which they can ask anything about anything related to programming. The language we are working in, the program we work on, general computer science questions. This has received quite positive feedback overall.

Often junior developers are scared to ask questions because they 'know' they are 'wasting' your time with their questions.

[btbright]

I was going to post a link to that video, too. Great talk!

[bensummers]

My company has put a lot of effort into helping junior developers get a really good start to their careers. To a certain extent, you have to structure your work to enable this. I'd suggest seeing the support as a wider thing than just the activity of mentoring.

I wrote some notes:

https://www.haplo-services.com/blog/2017/working-with-early-...

[xsmasher]

Make sure you foster a culture of asking dumb questions. It should be clear to all of your developers that they should ASK whenever they are stuck, or don't know something, or when they need a rubber duck.

We have a "stupid questions" chat channel at work, and juniors and seniors alike are expected to use it when they need advice. If new developers see everyone putting their egos aside and asking for help, they are likely to follow suit.

[eysquared]

I think this largely depends on where in their career they are and how familiar they are with coding in the environment they just found themselves in (large org, small company, startup, tech stack, etc).

In general I find pairing a new hire with a less senior but relatively new hire to be a good way to get them ramped up quickly. Ideally this person has recently gone through the same process and can help get the new person unstuck. It also very much helps in the first few weeks to have a single point of contact to ask all the basic questions to get them up to speed before they feel comfortable reaching out to the larger org.

After this its all about knowledge transfer and task management. Helping them understand why things are the way they are, not just how. There is a tendency for new devs to come in and want to change everything to be "better" without understanding the reasons for the current state of the world.

Once they are up and running, giving them larger and larger tasks with less and less guidance will get them out of their comfort zone and needing to get better integrated into the team. They will need to ask for help from an area expert, sync with PM, and be responsible for something end to end (though likely already pre-defined by someone more senior).

If they've made it past that point they should start becoming more autonomous and a great candidate to be a mentor for new devs coming in. Once they hit this stage, I find giving them more responsibility and less guidance can help them grow, fail, and learn.

I could write a lot more about this subject but thats a general idea of how I look at the ramp up process. Getting to Senior is a whole different topic, but for context I've only ever worked at large tech firms so thats the only definition of Senior I know.

[scarface74]

I very much struggled with training a junior developer that cane out of a boot camp. I couldn't teach him how to logically find an issue just by tracing the data flow.

While I stagnated for years and became an "expert beginner" (https://www.daedtech.com/how-developers-stop-learning-rise-o...) at one company, I've never been a "junior developer". By the time I got my first job at a small company, I already had 10 years of experience as a hobbyist and knew how to program.

It's easy to mentor someone who knows the fundamentals of how to logically break an issue down and throw out some ugly code to get them to a "clean code" stage or even teach them a language.

But if they already know the fundamentals of development as a junior developer, it's pretty easy to get to the next step with time, lunch and learns and reading a lot.

[proverbialbunny]

It's rather easy to teach these basic skills. Breaking a problem up is as easy as that: your description of it teaches it.

The trick with newer programmers is to take an abstract concept, such as that, and then bridge it to a concrete pattern that can be visibly seen and explored. You have to demonstrate, often out loud, your thought process while you're working through a problem, much like a job interview. Also, you'll want to go slow enough they're comfortable asking questions, taking notes, and doing google searches and what not, or only having very small talks at a time like 5 min at a time small slices.

Usually you'll want them at the keyboard to learn debugging with you over their shoulder, but if their skill level is absolutely basic, then you might want to be at the keyboard, and just run over problem solving of a easy 5 minute problem. By watching you run through a debugger and watching you google search for help (bonus) will give them enough idea to start doing it themselves, then in a couple of days you can switch and have them at the keyboard.

[crdoconnor]

Pairing. Ideally let the junior drive.

This is also a good way of getting new seniors up to speed on a code base they're unfamiliar with.