I still don’t get why I should want that.
I’ve mentored and managed juniors. They’re usually a net negative in productivity until they are no longer juniors.
I’ve mentored and managed juniors. They’re usually a net negative in productivity until they are no longer juniors.
People who enjoy mentoring juniors are generally satisfied with the ROI of iterating through LLM code generation.
People who find juniors sort-of-frustrating-but-part-of-the-job-sometimes have a higher denominator on that ROI calc, and ask themselves why they would keep banging their head against the LLM wall.
The first group is probably wiser and more efficient at multiplying their energies, in the long term.
I find myself in the second group. I run tests every couple months, but I'm still waiting for the models to have a higher R or a lower I. Any day now.
Most people who "mentor" other people (like, make it a pride and distinction part of their identity) are usually the last people you want to take advice from.
Actual mentors are the latter group, who juniors seek out or look up to.
In other words, the former group is akin to those people on YouTube who try to sell shitty courses.
It would make sense for there to be subgroups within the first group. It sounds like you prioritize results (mentee growth, possibly toward long-term contribution), and it's also likely that some people just enjoy the process of mentoring.
I've had ups and downs in this situation, but on most cases it's about showing the light to a path forward.
In most cases, the software development was straightforward, and most of the coaching was about a how to behave in the organisation they were functioning in.
One can only have so many architecture/code quality reviews, typically we evacuated the seniority of the devs on their ability to cope with people (colleagues, bosses, clients, ...)
We did have a few very bright technical people as well, but those were about 10 on a 2000-person company.
The reason I explicitly mentioned the slightly autistic junior person, is because I've worked with one, who was about to be fired, because other people had issues dealing with him.
So I moved desks, sat next to him for over a month, and he ended up becoming the champion for one of the projects we were doing, because he was very bright, precise and had a huge memory, which mattered a lot in that context.
Other stories are similar, once they were about to throw out a colleague because he was taking days to do something that should have taken a few hours max. So I say next to him, to see what he was doing.
Turned out he was refactoring all the code his feature touched because he couldn't stand bad code. So we moved him to quality control, and last time I checked he was thriving...
I guess what I'm saying is that -just like with people -, you need to find a good modus operandi, and have matching expectations, but if you can figure it out, it will pay off dividends.