I love being creative, but it feels like my real job is now to rein in junior developers, and it’s honestly pretty boring a lot of the time.
Does anyone else feel this way? And does anybody have tips to make this type of work more interesting?
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)
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.
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.
Integrate a linter which automatically checks against your style guide when someone sends a pull request and you will never have this problem.
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.
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 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.
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 don't have any affiliation beyond that I applied, seemingly unsuccessfully, but this may interest you: https://app.pullrequest.com/signups/reviewer
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.
(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
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 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.
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.
Second, just approve things quickly for a bit. If things start breaking, you'll be much more motivated to pay attention next time!
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.
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.