AI Won't Kill Junior Devs – But Your Hiring Strategy Might(addyo.substack.com)
addyo.substack.com
AI Won't Kill Junior Devs – But Your Hiring Strategy Might
https://addyo.substack.com/p/ai-wont-kill-junior-devs-but-your
78 comments
The problem you proposed would be a mid level or senior dev type problem on most organizations' job role descriptions. In most organizations junior devs are not expected to design solutions for open ended problems on their own.
For Junior, problem is already triaged/scoped, low criticality, solutions to this kind of problem are provided but may need judgement or extension to identify the best approach. Design and implementation should be based on requirements gathering from immediate known stakeholders. May need low-level supervision/guidance.
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.
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.
While I would not have used the descriptor "dependencies", substitute that with the term "partners":
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.
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.
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.
In my experience, the problems given to juniors are often open ended “improve this” or “fix this” type projects, but smaller scope or lower priority things that more senior devs would just never get 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.
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.
In my experience, those are the worst sorts of jobs to give juniors if you want actually throughout though. They need direction, releasable pieces, etc. they don’t know how to break something apart into small, releasable parts yet. That’s a major thing more experienced devs can teach them.
Why not? How else do you get these skills without doing it?
Job / Position description means something more... It means that your expected to do the task and perform well at it or you will be let go.
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.
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.
None of this seems hard for a junior dev tho... it just takes time, which I'm assuming the others workers don't really have with more pressing matters making this a great issue for juniors to grit their teeth on.
Note the words "on their own". They would be paired with a more experienced dev to collaborate with.
That seems self-selected and biased toward their own experiences.
When I was a junior I was allowed and given free reign to design the test system for the product and implement a design system for the frontend team.
Junior doesn't mean stupid, it just means less experience. How else do you expect people to gain experience if you don't give them basic independent projects?
When I was a junior I was allowed and given free reign to design the test system for the product and implement a design system for the frontend team.
Junior doesn't mean stupid, it just means less experience. How else do you expect people to gain experience if you don't give them basic independent projects?
My first job out of coll, task 1 was improved query perf on our test result database. job 2 was "get performance tests working again."
Both 100 % open ended problems.
Both 100 % open ended problems.
That task seems perfect for a junior dev. It's open ended but low risk and not interacting with multiple teams as directly
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
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
[deleted]
Hiring a junior dev is a luxury for big companies that can afford to tie up senior devs tandem coding with a junior for months, then giving easy projects to the junior dev with extensive code review and hand-holding for another year.
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.
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.
There’s a lot to be said about this comment, but I’ll stick to two things.
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.
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.
> 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.
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.
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.
As a customer of these types of businesses: yes, we can tell. We do care, and we are ready to drop the shitty products of these bad companies at the first opportunity.
The issue is not that companies don't have the funds to chase these bugs (which will impact future trust/revenue), it's that they don't want to spend it chasing these bugs. Next quarter thinking leads to bad software.
The problem with this idea is that being bug free and jank free is the moat that a mature app needs. Software lives on user trust. If everyone can see that the simple things aren't being done right, why will they have faith that the complex things are?
You're right, but since when has long-term thinking been a feature of the average American business?
IMO you're way overestimating how much hand-holding juniors need. Juniors coming out of college have a decent grasp of basic tooling like git, IDEs, debuggers, and yes AI coding assistants. We just hired two recent graduates and they were both getting meaningful work done independently within 2 weeks. They still need code review and guidance, but it's not like they need a senior watching over their shoulder telling them how to write a function in python.
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.
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.
Are the two recent graduate average fresh grads, or top ones?
This isn’t a new phenomenon and not limited to software development. Companies know that people get trained and leave all the time. Most companies have plans for that.
The answer used to be pensions, reasonable reliable raises, and promotion from within. Workers are responding to the signals sent by companies, the way to make the best money is bouncing around every few years to get actual raises, so that's what a lot of people do.
This answer feels like right out of the MBA coursebook. If you ever hate your phone performance, your reservations app, your airline booking page, your... then know that this answer is the reason why.
i'm a laid off senior engineer (or at least that was my level when i was employed). i apply to junior roles all the time and get rejected without interview. feel like there are other senior engineers out there in the same boat.
this could be an amazing time for companies to pick up more experienced engineers at junior position/salary. but they aren't biting.
this could be an amazing time for companies to pick up more experienced engineers at junior position/salary. but they aren't biting.
>As Camille Fournier bluntly put it, many tech managers who shifted to "senior-only" hiring are asking for trouble: "How do people ever become 'senior engineers' if they don't start out as junior ones?"
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.
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.
It is a low likelihood and low severity risk for an individual manager/actor in any event with some potential mitigations (i.e. pay a little more if the time comes). Going by this and other forum's posts lately the mood seems to be that the tech industry is in structural decline due to AI - so as a manager who may buy into that I won't take this risk all that seriously.
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.
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.
The legal industry has already figured out that LLMs can draft routine documents (and make massive mistakes) as well as a graduate lawyer, but that’s not the point.
That industry has properly recognised that this is where people learn the skills to do more complex, higher value work.
That industry has properly recognised that this is where people learn the skills to do more complex, higher value work.
Maybe because law firms aren't managed by MBAs.
Also, a law firm partner worked all their way up as as a lawyer, but a tech company CEO probably didn't work all their way up as a software engineer (and may have never been one)?
(Understanding of the role, empathy for it, and a bit invested in thinking of the role as valuable.)
(Understanding of the role, empathy for it, and a bit invested in thinking of the role as valuable.)
They are run by partners laser focused on making money, just over a longer time horizon than private equity would be. Equity partners have most of their own wealth tied to the firm.
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.
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.
For now... some states are beginning to change their laws to allow non-lawyers to own law firms.
https://www.wsj.com/articles/kpmg-wants-to-be-the-first-acco...
https://www.wsj.com/articles/kpmg-wants-to-be-the-first-acco...
Why shouldn't a law firm be owned by non-lawyers? That limitation seems ridiculous.
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.
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.
Attorneys have a special status before the law. In particular, an attorney is legally required to act in the client's legitimate interests. If there is another person in the organization above the attorney and that person is also an attorney, the same requirement extends to them. But if that person is a random MBA or shareholder, they have no such obligation, which creates a conflict of interest.
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.
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.
That makes a lot of sense. Thanks!
It’s because there are financial and other accountability requirements unique to law firms (dealing with trust money etc) that are tied directly to the legal professional obligations of the person in charge of the firm.
Because lawyers occupy a quasi-public role in our legal system. They aren’t entirely separate from the system itself. The legal system depends on the enforcement of ethics and responsibility in a way that might be incompatible with a purely profit motive.
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.
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.
Bits About Money says similar things about banks: "A recurring theme of this column is that banks are privately funded public infrastructure." [1]. So laws around them are quite strict and different from regular companies.
[1] https://www.bitsaboutmoney.com/archive/why-is-that-bank-bran...
[1] https://www.bitsaboutmoney.com/archive/why-is-that-bank-bran...
How many things have private equity ruined?
Now imagine you are given less than judicious representation by the only law firm in town.
Now imagine you are given less than judicious representation by the only law firm in town.
This is a whole thing with pharmacies not owned by pharmacists, veterinarian clinics not owned by vets, dental clinics not owned by dentists and yes, people have noticed the perversion of incentives.
> Sometimes it works, sometimes it doesn't.
A lot of time it doesn't work, but more importantly, when it doesn't work the people who pay really can't tell. Law and medicine are very complex and ultimately are near total trust industries. When I go to the hospital I relinquish complete control to a bunch of people I don't know. Often literally - I could be under general anesthesia and couldn't fix the problem myself even if I wanted.
If the healthcare outcomes are worse in pursuit of a small increase in profit, I, the consumer, wouldn't know. There's so many corners to cut and I think a lot of them you could cut with only a small loss in quality. Probably nobody would notice.
A lot of time it doesn't work, but more importantly, when it doesn't work the people who pay really can't tell. Law and medicine are very complex and ultimately are near total trust industries. When I go to the hospital I relinquish complete control to a bunch of people I don't know. Often literally - I could be under general anesthesia and couldn't fix the problem myself even if I wanted.
If the healthcare outcomes are worse in pursuit of a small increase in profit, I, the consumer, wouldn't know. There's so many corners to cut and I think a lot of them you could cut with only a small loss in quality. Probably nobody would notice.
Or because bad légal documents become obvious immediately, while bad code has a 2-3 year incubation period.
Not always. Contracts for example sometimes contain landmines that lay undiscovered for a decade or more.
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.
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.
I’m pretty fluent in both worlds and they are actually highly equivalent on this one specific point.
In both cases it looks perfect and it works right up until it doesn’t, usually for the same reason, entering an unanticipated state.
In both cases it looks perfect and it works right up until it doesn’t, usually for the same reason, entering an unanticipated state.
I would argue they are pretty similar. It's not hard for a bad clause in a contract to get overlooked at first and then become a problem years later. Example:
https://www.nbcnews.com/news/us-news/think-commas-don-t-matt...
https://www.nbcnews.com/news/us-news/think-commas-don-t-matt...
Unfortunately that's not always the case. Bad _arguments in a case_, sure, but bad contracts? I'd fully expect that in 30 years some unfortunate lawyer will be attempting to untangle nonsense drafted by a 2020s LLM.
(Actually, it only just occurred to me, lots of laypeople are going to use these to draft _wills_, aren't they? That should be entertaining.)
(Actually, it only just occurred to me, lots of laypeople are going to use these to draft _wills_, aren't they? That should be entertaining.)
I am not understanding the joke.
They're saying that the language in such a document could be read and discovered almost immediately, whereas the logic bomb sitting inside a bunch of poorly written code may take years before it finally explodes.
...while ignoring that flaws in legal documents are not always immediately obvious, and bugs in code are not always difficult to discover.
> Indeed, companies that try to staff only with experienced devs face a pipeline problem. Without juniors today, there are no seniors tomorrow.
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.
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.
Provide an environment and incentives so that people enjoy working for your company and don’t want to leave.
[deleted]
> 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?
But if companies aren't hiring juniors like they used to, shouldn't retention be a lot easier?
> 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.
I find these statements so damning and self-incriminating. It's an open admission that the junior should expect to be treated poorly.
I find these statements so damning and self-incriminating. It's an open admission that the junior should expect to be treated poorly.
This is the way.
Our company hires a bunch of juniors from different fields every year, we keep the best ones and let the others off with recommendations (if warranted and in most cases they are).
Our company hires a bunch of juniors from different fields every year, we keep the best ones and let the others off with recommendations (if warranted and in most cases they are).
This aligns with my thinking that juniors can leverage AI to become seniors much faster than people without AI but there are important concepts about learning debugging, learning how the underlying technologies work, etc. that is crucial to becoming a senior dev. Just using AI to pump out code without knowing the details of how it works will not end up going well for the long haul.
Seniors can also leverage AI to become juniors too.
Dogfooding is encouraged for our top dogs, underdogs, and even random strays we find. In our vision of the future on the internet, everyone is a dog.
I know you kid, or at least that gave me a chuckle, but this might be why seniors don’t find a lot of usefulness with AI, because we see blatant issues immediately and think it’s a waste of time sometimes.
I sort of kid, I sort of don't. There's a process seniors go through when approaching problems that vibe coding short circuits by removing some of the elements that act as triggers to the critical thinking process. Without those cues, less critical thinking winds up happening.
Personally, I think it's more a matter of remapping those triggers onto this new process, but for now I think it's a real phenomenon.
Personally, I think it's more a matter of remapping those triggers onto this new process, but for now I think it's a real phenomenon.
> Traditionally, new developers cut their teeth on small, repetitive tasks – fixing simple bugs, writing unit tests, churning through minor feature tweaks. These tasks were mundane but crucial for skill-building. Now, a lot of that grunt work can be handled by generative AI.
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
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
I'm curious just how much of this "senior only hiring" stuff is a _narrative_ thing vs an actual reality.
Many small startups _never_ really hired junior people, preferring to only take people who had some experience. To some extent, taking juniors and _turning them into_ seniors has always been more of a big-company thing than a small-company thing (which makes _sense_; it's expensive). I'd be curious whether there's actual data showing a shift, or if it's just vibes.
Many small startups _never_ really hired junior people, preferring to only take people who had some experience. To some extent, taking juniors and _turning them into_ seniors has always been more of a big-company thing than a small-company thing (which makes _sense_; it's expensive). I'd be curious whether there's actual data showing a shift, or if it's just vibes.
I feel like I've worked with (and heard about) more companies trying the senior only thing in the last few years (Covid and beyond).
That could be a bias in my sampling of people I know and work with though.
I do think hiring only seniors is generally a bad idea unless you want only seniors who are content cranking out tickets and code. That, to my mind, isn't what you want a senior for, but apparently much of the market disagrees with me.
That could be a bias in my sampling of people I know and work with though.
I do think hiring only seniors is generally a bad idea unless you want only seniors who are content cranking out tickets and code. That, to my mind, isn't what you want a senior for, but apparently much of the market disagrees with me.
Using AI certainly isn't expected in any teams I'm leading; not that I'm going to forbid anyone to use a tool, but I will warn everyone about depending on it and the requirement for verification/understanding.
This has led me to wonder if this is the last generation of "senior" devs. The thinking goes, if it takes a couple of years to educate and train a junior dev on average and LLMs can increasingly replace junior devs... There is no need for a company to hire junior devs, starving the ecosystem of talent that would have otherwise gone onto becoming senior.
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...
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...
We have one junior dev in a team about a dozen. They have had other roles with us, both at the current job and previous ones. We know they are smart, reliable, and motivated. It's a no brainer to spend time on training because, combined with the skills from other roles, they are likely to have a lot of leverage.
But it's hard to imagine committing to the training without the history.
But it's hard to imagine committing to the training without the history.
>We know they are smart, reliable, and motivated. It's a no brainer to spend time on training because, combined with the skills from other roles, they are likely to have a lot of leverage.
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 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+.
>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 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?
Maybe they played the interview game well? Or knew the right people at the right time?
I find it quite naive that senior devs think this will stop with juniors. TFA says "No juniors today means no seniors tomorrow ... juniors must focus on higher-level skills like debugging, system design, and effective collaboration" and yet he believes AI won’t be doing all of that by the time those juniors somehow upskill on their own.
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.
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.
> 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.
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.
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.
It won't just kill junior devs - it's killing senior roles as well - right now. Of course, developers are still needed, but the people who are doing the hiring and firing don't really care about that, they just expect more productivity with a smaller workforce, something that's been pretty common even prior to the advent of LLMs.
The real issue is wage expectations. In 2 ways
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.
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.
Not only does your fancy AI junior randomly spew bullshit back at you; that happens with humans as well; but it keeps doing it, never learning anything.
Managing one or several of these idiots has to be the worst job ever invented.
Managing one or several of these idiots has to be the worst job ever invented.
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).