51–60 of 74 posts
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.
I would leave, if someone made me do pair programming.
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.
Earlier quoted context omitted.
I don't think it's about years of experience -- someone who does the bare minimum for five years and never provides input could very well still be categorized as "junior"
Would that also work the other way? Someone providing a lot of input within 2 years is to be considered senior?
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.
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.
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 so…
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.
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.
I would leave, if someone made me do pair programming.
Earlier quoted context omitted.
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.
Yep. Pairing a senior with a junior has showed that it does not often help juniors beyond the rate they'd normally grow at on their own. It appears like pair programming is accelerating learning when in reality it can actually hinder progress. 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 to…
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.
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.
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.
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.