Do you find mentoring and code review boring?

stop reigning in people and figure out how to help them grow in ways you wouldn't

No. It can be frustrating but it's always engaging. Frustrating when mentees continue to make the same mistakes over and over and don't "get it." Exhilarating when they grow and start to impress or even surpass me.

There is always a balance to be achieved between creating stuff oneself and mentoring others. The ideas which helped me on this have been:

(a) never offer mentoring/review/training if it's forced or otherwise unsolicited;

(b) reading Feynman talking about teaching: https://www.math.utah.edu/~yplee/teaching/feynman.html

Yes for mentoring, I’ve always avoided positions that would involve or expect lots of helping juniors. I’ve been told I’m good at this but I don’t enjoy it.

Code review of peers is generally fine. When people know what they’re doing it’s usually more to catch unintended mistakes and as a sanity check that what’s being done makes sense.

It's been a toss up for me. Some juniors are super self motivated and can take advice and run with it. In these scenarios I really enjoy mentoring because it feels like a back and forth process. Others need their hands held a lot and tend to just assume they can't figure things out on their own which becomes exhausting to deal with.

> but it feels like my real job is now to rein in junior developers

That's quite the paternalistic and insulting approach.

We were all "junior" at some point.

I don't find mentoring boring. I find it one of the most engaging and enjoyable aspects of becoming a senior/lead on my team.

However, code reviews can be a mixed bag. Seeing people get overly focused or "clever" with formatting when we have a style guide and an auto formatter. Just use the formatter.

Seeing mid-level engineers blindly enforcing their personal "best practices" where they don't really apply (e.g. debating about what fields should be public/private final/non-final in unit test classes).

Junior engineers completely missing the mark of how to add comments (e.g. adding inane and redundant comments on incredibly obvious code but not a single comment around really complex or important code)

I really enjoy code reviewing, and maybe I'm weird but I especially enjoy CR'ing huge PR's. It's like a puzzle to figure out what's going on and write advice in a way that is clear, constructive, helpful, and appreciated. And when it's a really good PR it's even more fun, seeing people make great progress and do great work is truly enjoyable.

It can also be challenging though, especially preventing it turning negative if there is need for big changes. Also making judgement calls of what matters and what is nitpicking. Imo it's essential to stay on the conservative side as nitpicking is a giant waste of time and incredibly demotivating.

You mention reining in, which doesn't sound fun. What you might try is to find ways to not say "no" but actually demonstrate or teach why you might or might not want to do something, or just focus on the alternative. Basically challenge yourself to find ways you can give people the opportunity to learn the lesson themselves in an engaging motivating way, instead of having to hold them back. Also maybe let some things go, not everything will cause disasters.

Few more things I find work well;

- Outside of normal work learning activities; workshops, presentations etc. (let them present as well)

- Solicit feedback yourself; Create an environment where it's normal and appreciated.

- Give "optional" advice, give them the choice to follow it or not.

To come back to your question; I find it really challenging at times, but definitely not boring. I think seeing it as a challenge might generally help to find the joy in it.

I have two techniques for getting code reviews to feel less like drudge work. First, I have another junior do the first pass of the code review. Sure, it's not always good, but it catches basic errors, and seeing the interaction between the two makes the process more interesting for me.

Second, just approve things quickly for a bit. If things start breaking, you'll be much more motivated to pay attention next time!

I understand that feeling, and everyone has different interests.

Personally I enjoy the mentoring part. I'm senior level and at this point there's only so much code I can write in a day. But mentoring someone up to a comparable level is a force-multiplier. It allows me to tackle larger problems.

Plus I see it as just a different kind of hacking. I'm hacking other engineers instead of code.

I rather see it as scaling creativity. Nowadays I spend more time with designing, refining tickets/specs, code reviews and mentoring than coding myself.

I mostly enjoy it, it feels like moving forward. It is sometimes a bit frustrating to think „I could do that in a fraction of the time“, but it's important to acknowledge how to best spend the work time, not to do what's most fun.

Probably wouldn't enjoy it if I wouldn't be able to influence in which direction the work goes, though.

This is the only way to scale your impact as an IC.

The goal isn't to always have to do the repetitive reviews. It's to mentor people up so they do them for you eventually.

When you life those juniors up enough for them to mentor the next iteration you start the flywheel. You get to mentor and review people's work who do things at a higher level, and they get to learn to mentor juniors who were in their position. Everyone, even you, get to move up.

throwaway account because... reasons. I've been really struggling with my junior recently. He joined the company during the first lockdown and so has been working fully remotely. It's been nearly two years now and I get the feeling he hasn't progressed anywhere nearly as much as I would of expected. He's extremely slow completing tickets and when he does, the work seems very sloppy. The thing is he's remote so it's very hard to gauge if he's slacking off or really struggling. By being remote he's missed out on so much of the casual conversations about why things are the way they are or when we throw around design ideas or problems with other devs in the room. Day to day I swing from "This pandemic is ruining this guys career" to "has this guy got a second full time job". To loop back to OP. My company doesn't normally hire juniors. I pushed very hard to hire a junior and was eager to give to someone else what the senior at my first job did for me. Fast forward two years I feel burnt out by it and starting to regret it.

Not really, but we shouldn't expect all senior engineers to enjoy this work. Some folks are coding machines till the wheels fall off and that ought to be rewarded too.

One tip: when you are writing code, the reward scale of time is small; you can very quickly see its effect and it's a very concrete thing. When you are doing "leadership" like teaching, mentoring or general "managing", the scale of time for the reward is much longer and less specific, so for most people who started this type of work it may not seem as rewarding. But, at the right scale of time (several months) you'll likely see your impact (somebody you helped being promoted or clearly being at a higher level for example) and it will be very rewarding.

There was a time when I would give short reviews and perform them in the most basic ways. Now I'm more Sr. so actually spend a lot more time explaining things in detail, not only for the author but also other readers/reviewers. I've also noticed my PR descriptions getting more detailed. Every writing is a learning opportunity.

I used to find it boring. I always wanted to be objective, and not just say "you have to do it because I said so". I had to dig deep on every one of my gut feelings. I had to do a ton of unpacking of my own instincts. Sometimes I had to correct my own advice when it went from good to bad due to some contextual change that I haven't predicted. Other times I had to argue against good practices that are commonly accepted, because turns out, they aren't always good. Once I realized that all of this stuff has objective underpinnings, and can be unpacked down to some foundational reasoning, the whole thing became incredibly fun. My brain became preoccupied breaking down complex subjective ideas into simple objective ones. Like I got my own source of content in my head. It got especially exciting when I succeeded unpacking some long-term architectural advice that doesn't have any short-term benefits. Not everyone is into that kind of thing though.

No but I only work with elite juniors.

Ultimately when mentoring your job is to make sure the mentee is on the right path, not on your path.

We need to make sure there some creative leeway (within reason) when programming, this allow for growth and exploration of solutions. Not all implementations are perfect but your job as mentor is to guide.