> 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)

It’s funny that you take offense with my use of “rein in”, then proceed to complain about the “inane and redundant” comments that junior developers write, amongst other pretty minor complaints about your colleagues.

What is it you thought I meant by “rein in”? To crush their dreams and impose my will on them? What I meant was that it can take a lot of work to make sure they produce good designs and high quality code, because they don’t have the experience to do it on their own a lot of the time.

> 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.

Integrate a linter which automatically checks against your style guide when someone sends a pull request and you will never have this problem.

People have different preferences. You like mentoring; OP doesn't.

Maybe it should be voluntary. Like, if some people want to do code reviews, they should be allowed to do it even outside their teams... which would mean that the senior developer in the other team does not have to.

It's insulting now to not want to mentor people?

It's exhausting and frustrating. I don't get any joy from it. In fact I want to write my own code, not look at other people's code at all.

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.

Good advice! I think it would make it more interesting to challenge myself to help junior developers grow as much as possible.

I guess sometimes I feel like people will grow on their own, and that my mentoring doesn’t really make a difference. But maybe I’m misjudging how much I could help if I really applied myself to it.

And to be clear, I think using “rein in” was bad wording on my part, due to the negative connotations, and I regret not writing that differently.

I do give advice and try to teach rather than to just say no or criticizing, and I’ve gotten a lot of positive feedback for how I work with junior developers. It just hasn’t been something really fulfilling to me.

Sure! I got that from your post, and I also recognize it btw; it can feel like you have to "rein in", which is not very enjoyable.

But yes, you can have major impact on individual people and on the team as a whole, and if you got positive feedback in the past you are probably already doing that.

Instead of designing code/product, you are designing an environment and culture where people can feel good, improve themselves, and do their best work. Really challenging, but really fulfilling if it goes well.

Good luck! I hope you can find the joy in it.

> I really enjoy code reviewing, and maybe I'm weird but I especially enjoy CR'ing huge PR's

I don't have any affiliation beyond that I applied, seemingly unsuccessfully, but this may interest you: https://app.pullrequest.com/signups/reviewer

Thanks for the link! I was not aware this was a thing, it looks very interesting.

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.

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.

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.

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

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.

In my experience, I've found that if you are a small company or don't have 8-10 seniors, hiring juniors is extremely risky, specially if you are not in the U.S. (or anywhere you can't fire them instantly when you realize your mistake).

One junior per 10 mid level to senior devs, and they can add value (given they are good) without taking anyone's time significantly.

One junior for 5 seniors can still work (specially if you arw a much bigger company and can move the juniors to different teams), but be prepared to have times where one of the seniors is spending way too much time with the junior... but hopefully, in a year or two, the junior will be mostly independent or at least will learn how to make best use of their time they spend bothering the seniors... if they don't leave the company in that time, that is, which they most likely will do because someone with a +1 year experience becomes much more valuable, specially as a junior.

This advice is too generic of course. I have also encountered juniors who have been a pleasure to work with, who will make sure to listen, understand and incorporate your ideas in a fast-paced way (juniors have the advantage of not knowing or caring about ALL the different things) and come back to you prepared with the right questions to make the best use of your time. But then these are not very common.

I can relate. This was pre-pandemic but I was a mentor of a junior who I quickly identified as someone who was struggling. To compensate I spent a lot of time with them, meeting multiple times per week. Looking back after two years I can't honestly say I saw any improvement and think I just wasted all that time. I used to hear about companies that require junior devs to reach a certain level within 2 years or they're let go and think that was harsh. Now I think it's necessary. If someone hasn't shown improvement in 2 years, it's highly unlikely they'll change. I think I also learned the lesson that if you need to spend time on people, spend it on the people who are worth spending it on.

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.

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.

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.

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!

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

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.

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.

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.

No but I only work with elite juniors.

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.