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.
It's the complete opposite for me. I enjoy the process of mentoring juniors and am usually sought out for a lot of little issues like fixing git workflows or questions on how a process works. Working with an LLM is absolutely not what I want to do because I'd much rather mentees actually learn and ask me less and less questions. My experience with AI so far is that it never learns at all and it has never felt to me like a human. It pretends to be contrite and apologises for mistakes but it makes those mistakes anyway. It's the worst kind of junior who repeats the same mistake multiple times and doesn't bother committing those to memory.
You're right, I'm probably lumping the first group over-broadly, since I understand them less well.
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'm cynical person, and IME the former are some of the most annoying and usually the worst engineers I've met.
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 depends... I've worked with hundreds of juniors & seniors during my consulting days.
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.
I’ve mentored and managed juniors. They’re usually a net negative in productivity until they are no longer juniors.