Hacker News Reader

Comment by nradov | Hacker News Reader

There is the ideal, and then there is the reality. Only the very largest enterprises have the scale necessary to develop comprehensive engineering training programs. Doing it right is tremendously expensive, so it can generally only be justified in organizations that onboard hundreds of new engineers every year. And even then, some level of program specific training will always be needed after completing the initial standard training.

Another perspective is to consider training junior engineers to be a core job responsibility of senior engineers. There are always going to be tasks that need to get done even if we don't "derive energy" from them. That's just part of being a professional. Most engineers who complain about teaching and mentoring shouldn't be promoted to senior level in the first place; in the long run they would probably be happier and more successful as independent consultants.

View on HN

"Another perspective is to consider training junior engineers to be a core job responsibility of senior engineers. There are always going to be tasks that need to get done even if we don't "derive energy" from them. That's just part of being a professional. Most engineers who complain about teaching and mentoring shouldn't be promoted to senior level in the first place; in the long run they would probably be happier and more successful as independent consultants."

All fine and good but you need to actually get the time and be recognized for the time you put into mentoring. In the companies I have seen senior devs are still measured by their output and setting time aside for mentoring younger devs doesn't really help their ratings. A lot do it anyways but the incentives are against doing so. .

I think the advice can be more general than just "make a training program", too, because the point is that you can't stick a junior next to a senior and hope knowledge will transfer by osmosis. That's lazy management. Instead, responsibilities should be clear ("Bob will spend 4 hours a week mentoring a junior") and employee strengths should be factored in ("Steve prefers not to mentor, but knows the software internals very well and will spend some time improving documentation for Bob").

I don't think "4 hours mentoring per week" works well. From my experience some weeks you need way more and some weeks way less. I would much prefer if I would get evaluated by the progress of the people I am mentoring.

> Another perspective is to consider training junior engineers to be a core job responsibility of senior engineers.

This is, I believe, a major reason why software sucks. Just as a person becomes somewhat competent at writing software, they're told to stop the very job they're finally good at, and focus on helping juniors become... teachers for the next batch of juniors. Unless you have a point in the process at which seniors stop teaching and go back to writing code, your software ends up being written entirely by juniors, putting a cap on the quality and delivery speed of your product.

> Most engineers who complain about teaching and mentoring shouldn't be promoted to senior level in the first place; in the long run they would probably be happier and more successful as independent consultants.

Most engineers who complain about this would be even more happy and more successful as "independent consultants" with an employment contracts and a monthly salary. I.e. those engineers are just asking to be allowed to continue to do the work they're finally proficient in, under conditions they worked so far (i.e. employment contract). Instead, they're being offered a choice of pivoting to unrelated activities they're likely not good at - either teaching or managing financial risk.

Come on, real organizations aren't asking senior engineers to spend all their time on teaching juniors. It's like 10% time on average.

Growth and turnover is a fact of life for any healthy organization. Someone has to teach the juniors or else forward progress will grind to a halt. And usually the senior engineers are the only ones with the skills and knowledge necessary to do that teaching, even if they don't particularly enjoy it and it impacts their other work.

I think a good startup (I might even persue this idea) is a corporate-mentoring program that basically does code reviews w/ junior/mid-level team members esp - ones that maybe are having performance issues to go over code, or maybe even soft skills or productivity skills like communicating better or prioritizing and staying on scope.

The mentor would maybe take on 10 people in an org, and every other week go over some of their code 1:1 and offer suggestions, etc..

Basically Uber for Senior Devs (but only as mentors/training purposes).

Company could also help businesses build their own internal training systems to make juniors grow faster.

Construx does something like that.

https://academy.construx.com/

There's probably room in the market for others, so if you want to start a business in that space then go for it. But what you're describing wouldn't really be considered a "startup" because that high-touch model can't scale up rapidly and there are minimal economies of scale. Companies doing training and coaching can only grow slowly because the service can't be automated and consistent quality depends on hiring the right type of employees. There aren't a lot of senior engineers who have the necessary experience and want to be full-time mentors, and those who do exist are expensive.

I do some of this in data science when I'm giving strategic support to teams. Be aware that managers generally see you as a cost who doesn't bring financial benefit to the team (whilst the team are desperately asking for practical training so they can deliver quicker). Find ways to couch your offering in business benefits - you've helped teams avoid expensive bugs or via pragmatic refactoring they've responded to market change faster. Finding believable examples IMHO is actually quite hard. I've found managers far more open to strategic support (to help the team "go in the right direction"), with things like teaching code reviews and best practices bolted on as secondary benefits.

A "training program" starts with good onboarding. It might even start during the hiring process. A company with 10 devs can be training less experienced folks.

Yes, even the smallest organizations can have a decent onboarding process in terms of making sure new hires understand company policies and have the tools they need to work. But at that scale it's impractical to run a formalized engineering training program with assigned instructors teaching a defined curriculum. Realistically most of the training will have to be 1:1 mentoring delivered as needed by senior engineers. All senior engineers should be expected to participate, but of course that takes time and competent managers will plan for some temporary reduction in team velocity.

This is why pair programming is so popular, but this is presuming that the more senior in that relationship is maybe good at teaching/coaching/mentoring.

A better solution might be have a set person, or even outsource the pair programming with some mentor-in-the-middle who has teaching experience and also can build more user-centered training for that person. Like a vocal coach for music, but for software.

Reply on news.ycombinator.com