What are some good, holistic approaches for helping train up-and-coming developers all the way to “senior developer” skill level?
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.
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.
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.
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.
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.
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.
I know there were some issues with the program in the past (for instance, at one point you had to maintain at least an 80% "grade" in the program or you'd be cut loose from the company) but Bloomberg has really invested in the program recently and it's much more trainee-friendly these days. Lots of emphasis on cooperation and teamwork, and even though there are some solo timed "assessments" they're about the right level of challenge, and the goal is understandable -- they're there so the trainers can get a feel for what lessons work and what lessons need fixing.
Anyway, it was invaluable to me. I can't imagine jumping straight into a dev role at a company fresh out of college.
Alas, due to cost (airfare and accommodation for everyone for 3 months adds up to a lot!) they've now scaled it down to just within each region rather than globally - so all of the NA graduates will train together, all the EMEA ones etc. Not quite globe-spanning as before, but still 3 months long and with people from other locations, just not all locations.
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.
Very interesting to see this applied at a university level!
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.
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.
However, pair programming has shown to accelerate growth when both peers are roughly at the same level. For some companies this means hiring two juniors and having them work together, but this isn't as common of a practice as it could be.
One solution I've found to this is to subtly pretend to be forgetful and or anxious when pair programming with a junior. This lowers my level down to their level giving them growth potential. If the junior is anxious, showing anxiety about myself in a subtle way will lighten their anxiety. This works during interviews too. Being non-judgemental and friendly work too to melt anxiety away. If I am randomly forgetful from time to time, it gives them an opportunity to shine and help out leaving them feeling good and accelerating growth. Studies show that optimal learning has roughly 75% failure and 25% success. Is your jr helping you 20-25% of the time? How I encourage this growth is I start with forgetting a bit of language syntax, then a language idiom or two, then library syntax, then parts of the framework, and so on. The key here is to not show any sort of judgement. It's 100% okay if they do not know. That's part of the point. They have to look it up and figure it out and help out and grow. By doing this their level increases. My back story usually is, "Oh Python? I don't know that language. We'll have to run through it together." works like a charm as long as I start low and find their level, instead of overwhelming them.
When pair programming with a junior I find 30 minutes to 2 hours at a time works best. It's slow going at first, but by giving them something to grow on, the second you leave them to their own devices they will continue to grow in that area. You can leave them alone sometimes for a week at a time and watch the results from a 30 minute pair programming session.
It should be in the tone that the junior has a person whose highest priority is to mentor them. Upper management feels this is a tremendous waste of resources, so the term often used for this is "pair programming".
It's a way to teach a lot of the design patterns like SOLID or teach architectures in the real world. Most of these things are habits.
Sometimes they could take days just figuring out the architecture of something (where the files are). Sometimes they're stuck trying to build or compile. Sometimes the codebase has a particularly buggy thing that nobody touches, or the documentation only exists in someone's head.
Once the junior is up to par, which might take 1-3 months, they can move back to single programming. A lot of the habits are already in place.
Pair programming makes total sense when tasks are owned by the team. In that case it's in everyone's interest to improve the team's overall velocity. That means time spent mentoring juniors or working together on tasks is well spent.
When tasks are owned by individuals, it's in everyone's interest to increase their own velocity which means maximizing time spent working on their own tasks. People are disincentivized from helping other people complete their work or mentoring them, because that directly reduces your personal velocity.
In reality, pair programming happens very rarely but when it does it's very useful.
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.
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).
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.
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.
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.
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
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.
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.
I wrote some notes:
https://www.haplo-services.com/blog/2017/working-with-early-...
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.
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.
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.
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.
This is also a good way of getting new seniors up to speed on a code base they're unfamiliar with.
After 2 years I wasn't able to provide constructive feedback without being a little too brash, I couldn't have designed anything distributed, I wouldn't have been able to break up a gigantic feature into smaller problems etc. I've worked with people who were technically competent and mature 2 years after school.