It’s faulty, short-sighted logic though. If every company trained juniors, only for them to jump ship in two years, there’d be a pool of trained juniors to hire from. Yes you wouldn’t get your investment out of that particular person, but you’d be hiring someone else’s investment.
Beyond that, there’s work that is better suited to more junior employees because it’s literally a waste of the senior employees’ skills.
Your points are sound and wise, which means the people in upper- and mid-level management have already stamped those forms of reasoning out of their heads to get where they are.
If every company trained juniors, only for them to jump ship in two years, there’d be a pool of trained juniors to hire from.
I mean… That’s only if they trained juniors. Juniors have an incredibly hard time getting their first job in programming. Each company is incentivized to snipe juniors from everywhere else instead of train their own.
Beyond that, there’s work that is better suited to more junior employees because it’s literally a waste of the senior employees’ skills.
As a staff software eng - nothing is beneath me. There are some things that only I can do (in theory) but in practice I do everything from minor copy changes to architecting new services. If I need to do something I’m happy to do it.
It’s a lost opportunity when you, a staff engineer, spend your time doing something that a junior engineer could do – instead of doing a task a junior engineer can’t do.
I think it’s important for seniors to be in the trenches.
I’d expect a senior to be doing “junior” work even if juniors were available to take it on.
It’s not all about efficiency: it’s about keeping grounded and in touch with the ongoing state of the code base. Which I’d argue you can’t get just from reviewing PRs.
I can see what you mean as far as false economies go for the company but in order to have a task fully scoped for a junior to do you need significant amounts of managerial and engineering time spent grooming tickets, updating AC, explicitly enumerating changes… All of which could be cut through by more senior devs that handle ambiguity better.
Its hard. I’d rather have juniors to delegate to, sure. But I’d most like to have juniors to train. Even if they didn’t do anything useful for 6 months.
It wasn’t my intention to put words in your mouth. Everything I’ve said has been an honest reflection of my experience in corporate programming and represents the things I hear managers saying about team composition and division of labor. I’m in meetings with members of the c-suite talking about these things specifically.
I get you don’t think it makes sense for a corporation to do. I’m trying to say regardless of that - the executives are acting in what they see as very rational self interest.
juniors are a way bigger risk than seniors and usually leave a company right around the time that they’re getting good.
Personally, as a manager, I find the opposite.
It’s always the juniors that exceed expectations. You never hire somebody senior and find they can do twice as much as you thought. Juniors are often eager to learn if you are willing to teach them. They want to be good at their job, because they know they are laying the foundation of their career. Seniors often have all the bad habits baked in.
Then, if you get a good reputation for developing people (because they leave your team and impress their next set of colleagues) it becomes easier and easier to hire.
I’m glad some managers see it that way. I wish it were easier to get junior headcount. Our mobile team is very small so we have huge bus factor at all times. A couple of junior devs, say 1 for each of the mobile components in our stack (backend, iOS, android) would help mitigate those risks for comparatively cheap, on top of improving our overall velocity.
You never hire somebody senior and find they can do twice as much as you thought.
Generally juniors are expensive for their performance though. If they can do double what you thought it’s great but I’m not sure how much of a cost savings that is against an engineer coming in as a senior (not lead or staff - just a vetted competent programmer who works). Then again I’m not in management at all: I could have the performance-per-dollar figure entirely wrong.
We have a fairly big step up in pay from junior to senior. I can take on 2 or 3 juniors to a high senior or especially principle engineer.
We’re often also taking juniors on that we already have a relationship with through placements during their university course. That minimises the risk.
Internship placement would be great. Fighting to even get interns lately though. All management talks about is “efficiency” these days.
Using a SE 1-5 scale where 1 is junior - I’m generally talking about companies (or at least my current employer) preferring to hire SE2 rather than SE1. An SE2 is maybe 50% more expensive than an SE1 at {current employer} while an SE4 is about 3x an SE1.
A very small company I worked at basically only hired juniors right out of school but with the understanding that they’d stay on for at least a couple years to help out. The CEO was an engineer in the code though: fun shop. I trained 2 juniors there to competency… But it was a significant investment to do so.
Everyone wants to hire senior devs, nobody wants to train junior devs.
It makes sense: juniors are a way bigger risk than seniors and usually leave a company right around the time that they’re getting good.
And they have every reason to: companies aren’t loyal to workers why should workers be loyal to companies?
But to a corporation that means they spent senior dev time training juniors into seniors for another company to use.
… I’m constantly arguing that we should have more junior devs on the team but we have none.
It’s faulty, short-sighted logic though. If every company trained juniors, only for them to jump ship in two years, there’d be a pool of trained juniors to hire from. Yes you wouldn’t get your investment out of that particular person, but you’d be hiring someone else’s investment.
Beyond that, there’s work that is better suited to more junior employees because it’s literally a waste of the senior employees’ skills.
Your points are sound and wise, which means the people in upper- and mid-level management have already stamped those forms of reasoning out of their heads to get where they are.
I mean… That’s only if they trained juniors. Juniors have an incredibly hard time getting their first job in programming. Each company is incentivized to snipe juniors from everywhere else instead of train their own.
As a staff software eng - nothing is beneath me. There are some things that only I can do (in theory) but in practice I do everything from minor copy changes to architecting new services. If I need to do something I’m happy to do it.
No one said anything is beneath senior employees.
It’s a lost opportunity when you, a staff engineer, spend your time doing something that a junior engineer could do – instead of doing a task a junior engineer can’t do.
I think it’s important for seniors to be in the trenches.
I’d expect a senior to be doing “junior” work even if juniors were available to take it on.
It’s not all about efficiency: it’s about keeping grounded and in touch with the ongoing state of the code base. Which I’d argue you can’t get just from reviewing PRs.
I can see what you mean as far as false economies go for the company but in order to have a task fully scoped for a junior to do you need significant amounts of managerial and engineering time spent grooming tickets, updating AC, explicitly enumerating changes… All of which could be cut through by more senior devs that handle ambiguity better.
Its hard. I’d rather have juniors to delegate to, sure. But I’d most like to have juniors to train. Even if they didn’t do anything useful for 6 months.
Again, you’re putting words in my mouth. I’m done engaging with you as I don’t think you’re conversing in good faith.
It wasn’t my intention to put words in your mouth. Everything I’ve said has been an honest reflection of my experience in corporate programming and represents the things I hear managers saying about team composition and division of labor. I’m in meetings with members of the c-suite talking about these things specifically.
I get you don’t think it makes sense for a corporation to do. I’m trying to say regardless of that - the executives are acting in what they see as very rational self interest.
Personally, as a manager, I find the opposite.
It’s always the juniors that exceed expectations. You never hire somebody senior and find they can do twice as much as you thought. Juniors are often eager to learn if you are willing to teach them. They want to be good at their job, because they know they are laying the foundation of their career. Seniors often have all the bad habits baked in.
Then, if you get a good reputation for developing people (because they leave your team and impress their next set of colleagues) it becomes easier and easier to hire.
I’m glad some managers see it that way. I wish it were easier to get junior headcount. Our mobile team is very small so we have huge bus factor at all times. A couple of junior devs, say 1 for each of the mobile components in our stack (backend, iOS, android) would help mitigate those risks for comparatively cheap, on top of improving our overall velocity.
Generally juniors are expensive for their performance though. If they can do double what you thought it’s great but I’m not sure how much of a cost savings that is against an engineer coming in as a senior (not lead or staff - just a vetted competent programmer who works). Then again I’m not in management at all: I could have the performance-per-dollar figure entirely wrong.
We have a fairly big step up in pay from junior to senior. I can take on 2 or 3 juniors to a high senior or especially principle engineer.
We’re often also taking juniors on that we already have a relationship with through placements during their university course. That minimises the risk.
Internship placement would be great. Fighting to even get interns lately though. All management talks about is “efficiency” these days.
Using a SE 1-5 scale where 1 is junior - I’m generally talking about companies (or at least my current employer) preferring to hire SE2 rather than SE1. An SE2 is maybe 50% more expensive than an SE1 at {current employer} while an SE4 is about 3x an SE1.
A very small company I worked at basically only hired juniors right out of school but with the understanding that they’d stay on for at least a couple years to help out. The CEO was an engineer in the code though: fun shop. I trained 2 juniors there to competency… But it was a significant investment to do so.