I don’t think anyone has the budget for that anymore - not even the big companies. It’s two years of negative $ output for the $ you put in and after those two years the junior dev leaves anyway for a more senior position.
1) it’s a waste of resources for seniors to be doing the work that the juniors and 2s can do. Hunting down infrequent or low priority bugs, fixing small layout issues, etc. they’re perfect for someone paid less and growing and learning the codebase.
There is *always* plenty of junior-ready work and the day a week of work to schedule, prep and help those juniors to do it pays dividends.
2) a Junior leaving because you won’t pay them, have a toxic culture or won’t give them a promotion when it’s time speaks more about a broken company culture and one of a style that’s rampant in the tech industry and business at large than it does about loyalty and willingness for the employee to stay at the company.
Good leadership and skilled organizers can easily solve the problems you’ve listed; and, even better, create a culture of longevity for all the employees at a company, not just the juniors.
Speaking as someone that has worked for companies that give a shit about their workers and who helped raise me up from a low SDE.
These are tasks that in the current environment often get pushed back for "later" indefinitely. These tasks aren't un-resourced because the company isn't hiring juniors, the company isn't hiring juniors because they no longer have the funds for small fixes.
You're going to have to teach them about the unique frameworks and processes at your company, but you have to teach seniors about those things too. Unless you're doing something really unique, juniors don't need to tie up senior devs "for months". Remember they can help each other, too.
1) For the last decade many juniors have had unreasonable salary expectations that have often still been met. Now there is an alternative that's a lot cheaper and doesn't come with an attitude.
2) It's generally agreed that for the first year or 2 in your career you aren't that useful; after that you start to add lots of value quickly. But salary expectations don't double when you go from a junior to an intermediate - maybe they go up 25%. It's clearly much better value to hire only seniors if you can find them.
I'm not saying these are right or wrong but a whole article about juniors that doesn't mention wages, and just tries to implore companies to "do the right thing", misses the point.
Managing one or several of these idiots has to be the worst job ever invented.
But it's hard to imagine committing to the training without the history.
This is the problem, early career devs are extremely bimodal in skill distribution.
You can luck out and land the 1 in 10 who just gets it and has the knack and has been coding since they were 12. But 9/10 times you end up with someone who has trouble even making a commit or with writing basic syntax, who just "picked" software as a career at some point in college for the salary. This has been my experience anywhere that doesnt have FAANG level cash to be hiring the top graduates at 150k+.
This is crazy to hear as someone who has been coding in one form or another since 14, and was driven into becoming a scrappy freelancer because no one would give me the time of day. Where are these kids who can't make a commit, or know basic syntax even coming from?
This one seems like a classic Prisoner's Dilemma. Defecting (hiring only seniors) is rational in isolation, but if everyone defects, everyone loses. What incentive for a smaller company to hire and invest in training the junior if in two years they'll leave for a larger company anyway.
But if companies aren't hiring juniors like they used to, shouldn't retention be a lot easier?
I find these statements so damning and self-incriminating. It's an open admission that the junior should expect to be treated poorly.
I was just testing the newly released Copilot Agent Mode in VS, and it already looks quite capable of debugging things independently (actually, it's not much different from VS Code Agent Mode, which came out a couple of weeks earlier).
System design? Not all seniors need Google-scale design skills. Most systems designed by seniors are either overdesigned, badly designed, or copied from an article or a case study anyway. There are plenty of seniors whose only real qualification is the number of years they've been working.
The author is from Google. I’m not sure if effective collaboration is something given there, but in many companies, especially outside of tech, it's not something you see often. And it's usually inversely proportional to the company’s age.
What seniors learned by doing is now written down and available to LLMs, often in multiple sources, explained by some of the best minds in the field. Any given senior likely knows only a fraction of a domain, and even less when you start combining domains. LLMs probably already there for some of the seniors, only they never checked.
It may shock you to learn that this was true before LLMs. There was a website called "Google" which acted as a front-end for almost all recorded knowledge in human history, and putting a phrase like "best design patterns for web APIs" as a search query (the primitive name for prompts) would give you hundreds, if not thousands of real-life examples and explanations of how to accomplish your goal.
Somehow senior developers kept their jobs despite the existence of this almighty oracle. LLMs do a better job of filtering and customizing the information, but seniors will still keep their jobs.
Our service occasionally gets especially expensive requests that amplify to our dependencies, one of those dependencies have started complaining that our bursts of traffic are impacting other users, talk to them and propose a solution that aligns with our different requirements. Possible directions are X, Y, Z.
AI is pretty far from able to do this. A cracked out vibe coder maybe could have just added a one-off naive rate limit algorithm pulled from stack overflow or maybe pulled in an unmaintained 3rd party 'rate-limit' package and called it a day. And that would be fine for a MVP but in large organizations figuring out what to build, how to build it, and getting agreement with stakeholders is way, way more work that doing than actual implementation (which still rarely can be one-shotted and needs a lot of hand-holding and iteration to get decent solutions).
Generally you don't put those skills in a Junior PD, but you would expect a Junior to take on these tasks if they hope to progress. The Mid level PD would have it listed and as the junior shows they can meet each and every additional skill, the option of a promotion becomes available.
Both 100 % open ended problems.
It's different from the one described above
> talk to them and propose a solution that aligns with our different requirements. Possible directions are X, Y, Z.
I'm sure some junior devs could do this but the majority wouldnt be able to
I will say though, needing to socialize across other teams to understand the problem and drive the correct solution does strike me as more mid/senior level work.
Our service occasionally gets especially expensive requests
that amplify to our partners, one of those partners have
started complaining that our bursts of traffic are
impacting other users, talk to them and propose a solution
that aligns with our different requirements.
> The problem you proposed would be a mid level or senior dev type problem on most organizations' job role descriptions.With the clarification above, I believe a junior dev could perform this task, even if the proposed solution is known to be a learning exercise.
The immediate value to the team is the collection of partner concerns.
For mid-level, they are capable doing more of the problem triaging/classification and can handle vaguer, larger scoped problems. They can identify the correct stakeholders to engage with and, ideally, influence. Can identify the most likely best approach amongst a set of possible approaches. Guidance is high level- like a weekly or bi-weekly 1:1. Better design taste as far as how to measure outcomes or rollout changes safely.
For senior you're ideally solving classes of problems rather than specific problems. You're charting a longer term roadmap that generates work and exerts influence amongst number of teams to drive long-term business outcomes. You are mentoring juniors/mid-levels so they're setup for success and have the right work at the right level of guidance at the right time to grow in their careers.
In a world where the average work is the first to be displaced (due to training data availability), the last to be replaced are the ones furthest from distribution mean...
To me, this is the salient point. There are more juniors coming through now who aren't learning the fundamentals, because there is a ready shortcut around the mundane tedious work. Which means they're trying to move onto higher value, higher risk areas without understanding the foundations
If I were a betting man, I would wager that those managers either don't care, or are gambling that by the time senior engineers are in short supply, AI will be good enough to replace them as well.
Anyway as an average single company anything you do won't move the needle much - those people you train can move on anyway so that isn't a good way to cover that risk. Even if I have to pay more later, which is an unlikely outcome potentially given AI, that's tomorrow's problem and it affects my competitors and other companies as well most probably so I'm not at a relative disadvantage. Unless I'm a very big employer of tech I'm not going to affect future market dynamics either way as a single team.
However if the market is in structural decline and jobs will whittle away - maybe its better we don't hire juniors? They may thank us when they settle in another career with better long term prospects if what many posts are starting to say - that AI will kill the industry slowly. Better the hiring pool shrink to adjust to future expected demand than have higher unemployment and worse issues later.
bigfatkitten•6h ago
That industry has properly recognised that this is where people learn the skills to do more complex, higher value work.
bogzz•5h ago
RhysabOweyn•5h ago
https://www.wsj.com/articles/kpmg-wants-to-be-the-first-acco...
echelon•5h ago
Hospitals are owned by non-doctors. Engineering firms are owned by non-engineers. Sometimes it works, sometimes it doesn't. Sometimes the ones that fail are owned by the practitioners and the ones that succeed are led by former outsiders.
Toymaking companies are owned by adults, gynecology practices can be owned by men, wheelchair companies can be owned by those who can walk, record labels can be owned by non-vocalists, etc. Most sports teams...
Why should lawyers get special treatment?
If someone is a good operator, that's orthogonal.
Most ICs are not good at leadership, logistics, product, long term vision, etc. or at least not everything that a well-rounded CEO or owner might be. While hiring leadership from within the ranks works, it's not a necessary condition for success.
bigfatkitten•5h ago
CPLX•5h ago
This point is arguable of course. On one hand legal services are expensive and often inaccessible for many. On the other hand more aggressive competition and consolidation has absolutely ruined society in a couple situations, medicine being the obvious example.
So there’s more than one point of view on this.
abdullahkhalids•5h ago
[1] https://www.bitsaboutmoney.com/archive/why-is-that-bank-bran...
tomrod•5h ago
Now imagine you are given less than judicious representation by the only law firm in town.
morkalork•4h ago
jltsiren•4h ago
Other true professions have similar but lesser requirements. Some leadership positions in a hospital require an MD. Not because the MD makes you a better leader, but because the position involves making medical decisions. In an engineering company, some decisions must be made by a civil engineer. And so on.
The requirements for attorneys are stricter, because the law is a special case before the law. While other fields exist within the system, the law is the system itself.
echelon•4h ago
hengheng•5h ago
i_am_jl•5h ago
arcanemachiner•5h ago
i_am_jl•5h ago
bigfatkitten•5h ago
A key difference is that law is an actual profession. It has qualification, continuing professional development and licensing requirements, and personal consequences for getting it wrong. None of these things are true for software development.
margalabargala•5h ago
https://www.nbcnews.com/news/us-news/think-commas-don-t-matt...
CPLX•5h ago
In both cases it looks perfect and it works right up until it doesn’t, usually for the same reason, entering an unanticipated state.
bigfatkitten•5h ago
Grads are cheap. Partners can dangle the future senior associate/partner carrot over the head of a hopeful junior for many years while that junior brings in money that goes into the partners’ pockets. The junior brings in more money as they grow professionally.
neilv•4h ago
(Understanding of the role, empathy for it, and a bit invested in thinking of the role as valuable.)