The thing people miss in these “replace juniors with AI” takes is that juniors were never mainly about cheap hands on keyboards. They’re the only people in the org who are still allowed to ask “dumb” questions without losing face, and those questions are often the only signal you get that your abstractions are nonsense.
What AI does is remove a bunch of the humiliating, boring parts of being junior: hunting for the right API by cargo-culting Stack Overflow, grinding through boilerplate, getting stuck for hours on a missing import. If a half-decent model can collapse that search space for them, you get to spend more of their ramp time on “here’s how our system actually fits together” instead of “here’s how for-loops work in our house style”.
If you take that setup and then decide “cool, now we don’t need juniors at all”, you’re basically saying you want a company with no memory and no farm system – just an ever-shrinking ring of seniors arguing about strategy while no one actually grows into them.
Always love to include a good AI x work thread in my https://hackernewsai.com/ newsletter.
"without losing face"? What culture are you referring to? The Western companies I have worked at do not discourage such questions -- in fact, it's often the sign of someone very senior when they ask a seemingly 'dumb' question that others have taken for granted.
Yep, I fully agree with this view and I find that it's seniors who ask the 'dumb' questions. Everyone is worried about losing face in this precarious economy... But seniors are able to ask really smart questions as well so even their dumb questions sound smart... They can usually spin dumb questions into a smart questions by going one level deeper and bringing nuance into the discussion. This may be difficult to do for a junior.
My experience as a team lead working with a lot of juniors is that they are terrified of losing face and tend to talk a big game. As a team lead, I try to use language which expresses any doubts or knowledge gaps I have so that others in my team feel comfortable doing it as well. But a key aspect is that you have to really know your stuff in certain areas because you need to inspire others to mirror you... They won't try to mirror you if they don't respect you, based on your technical ability.
You need to demonstrate deep knowledge in some areas and need to demonstrate excellent reasoning abilities before you can safely ask dumb questions IMO. I try to find the specific strengths and weaknesses of my team members. I give constructive criticism for weaknesses but always try to identify and acknowledge each person's unique superpower; what makes them really stand out within the team. If people feel secure in their 'superpower', then they can be vulnerable in other areas and still feel confident. It's important to correctly identify the 'superpower' though because you don't want a Junior honing a skill that they don't naturally possess or you don't want them to be calling shots when they should be asking for help.
The fact that you mentioned Claude (LLMs) is interesting! I definitely feel like there is a parallel; maybe because AI sometimes hallucinates, people have built up a tolerance for this kind of speculative use of language from people as well.
About finding the superpower of each team member; after working with someone for a few months, I start to notice certain patterns in how they think. Sometimes there might be something they say once or a question they ask which makes me view them more favorably than before. Maybe they're fast, good at assembling stuff or slow but good at building stable core components. Maybe they're similar to me or maybe they have a skill I don't have or a certain interest/focus or way to approach problems that is different from me but is beneficial to the project and/or team.
It's a bit like playing a weird game of chess where you can't see the pieces properly at the beginning so everyone looks like a pawn initially; But then over time you discover that one person is a knight, another is a bishop, another is a queen... And you adapt your strategy as your visibility improves.
Completely agree with this. I got to work closely with an IBM fellow one summer and I was impressed by his willingness to ask "dumb questions" in meetings. Sometimes he was just out of the loop but more often he was just questioning some of the assumptions that others in the room had left unquestioned.
Unfortunately, I found that the culture of "think." at IBM is not matched at many other organizations. Most days, I miss it.
But forced RTO and only 10 days off per year is enough to keep me away ;)
100% agree and more credit if I could give it!
Even as a lead I ask the dumb question when no one else does just because when i can see the look in people faces or realize no one is chiming in the dumb question is needed to ensure everyone drives the point home. I've never been met with any sort of looking down upon nor do i discourage any of my staff - quite the opposite - I champion them for being willing to speak up.
in fairness, these do not sound like "dumb" questions.
Some questions really are dumb and bring no value to the table.
The key is knowing which is which, and that is the part that comes with experience.
> Some questions really are dumb and bring no value to the table.
They do tell you that the person asking them either isn't getting it, which is valuable information, or that they are trying to ask questions for the sake of it, which is also valuable information.
Which is exactly what the OP was saying - these are the kind of questions that are often needed, but that seniors won't ask because it'll make them lose face. Juniors are the ones allowed to "not get it".
It depends on the company and the people around you. At one company, my quarterly feedback was that I don’t ask too many questions in meetings, which was mostly due to the fact that the project was pretty straightforward and requirements were hammered down on a document. In another company, asking questions got me the feedback that I was maybe not experienced enough to manage the project by myself, which I was completely capable of. It’s a double edged sword.
But yes on a personal level, being senior enough in my career, I’d rather be thought of as less skilled by asking questions before the s hits the fan, than execute and mismanage a project that I didn’t ask enough questions on. The latter has more consequences tbh.
> my quarterly feedback was that I don’t ask too many questions
Sounds like your manager felt that he need to provide at least some feedback and it is best/safest he could come up with.
Company culture. Some companies I worked for would fire you for questioning decisions. Others, welcomed criticism. You don’t really know which environment you’re in until someone says something. Are you going to take the risk and be the first?
> Are you going to take the risk and be the first?
Absolutely. If the company I work for happens to be one that's so crappy that I'd get fired for questioning things, it's better to find that out as soon as possible. That's not a company that's worth my time and attention.
Yes, because i would rather not work at such company and go somewhere else.
In this market you might not have a choice but to stick it out a while
Think of highly competitive environments where looking foolish can be weaponised against you. They definitely exist here (my experience in UK and Australia)
IBM Aus discouraged it, Accenture, Concentrix, EY, CommBank, ANZ, and others all encouraged it, for myself.
I wouldn't say discouraging it will be the norm across most places in Australia.
Somewhat, but not exactly the reverse, is Tall poppy syndrome:
https://en.wikipedia.org/wiki/Tall_poppy_syndrome
I had read it about AU and JP and had read about the Jante thing, but the article says it is there in some other countries too. Probably exists everywhere in some form.
I wonder if people here have experienced anything like that. My guess is yes.
That, I have certainly seen.
But that is about attacking success stories, not about attacking you for not knowing something. I know you said reverse, just spelling out they're different.
Win an award? Get a callout for effort? Rest of the office will probably dunk on you. Varying in scale from a day or two of jokes to career ruining.
But... Ask the meaning of an acronym in a meeting, or say you don't know how to do something, and you'll probably just be given a name to ask.
>I know you said reverse, just spelling out they're different.
Hey. Sup. :)
I didn't say reverse.
I said:
>Somewhat, but not exactly the reverse, is Tall poppy syndrome.
Next time, and forever after, check points better before commenting, including the point that is right above the comment that you replied to, aka mine.
Pinky promise? :)
Welcome to the AI (r)age, where people comment without thinking or reading.
Oops, mea culpa.
Entschulding!
It was happening much before that, and not only on HN.
In fact, it has been happening forever, and anyone who doesn't know it is a rotten egg.
<Jumps into the pool ahead of others. (last one in, etc.)>
Well, this is some fun irony. An attacking comment, for offering an explanation, and acknowledging the prevalence of that particular cultural item.
You just attacked an explanation, including personal slag like "anyone who doesn't know".
I did it because you misquoted me about my use of the word "reverse" in a sentence, as I clearly pointed out above. So it was like making someone (me) look like they said something they didn't say.
But maybe I went at it too strong.
>Entschulding
Typo, entschuldigung.
My entire career - New Zealand, and Australia - asking questions is weaponised (as I stated above)
Graduate, Junior, Senior, Team Lead, - my title hasn't mattered to the response
You're working in toxic workplaces. Most of them aren't like this.
(I believe you when you say that most of yours are like this.)
I bet most workplaces are toxic in exactly this way.
Unionize
some of the descriptions above of thoughtful supportive work places where people are free to explore different ideas and question assumptions sound like paradise.
Or judged via rose coloured spectacles.
There are kinds of questions that you can ask to signal your seniority and matureness. There are other kinds of questions that, should you ask them, will leave people wondering what the hell have you been doing for the past N years and why they're paying you senior-level salary.
A lot of early signs of problems, such as critical information becoming tribal knowledge instead of being documented, are revealed when asking the second kind of questions.
I am bit more senior nowadays.
Whenever I don’t understand something I say something like: "Uh, I’m probably the only one here, but I don’t get it…"
I'm the CTO and probably one of the most common things I'll say is "help me understand X"
There’s power dynamics that come into play when you’re a C level executive. You’re allowed to ask questions. For entry level employees, asking questions almost always comes with a judgement of lower skills/experience. This is often what senior and experienced folk forget, there’s a certain amount of assumed competence when you asked questions, that doesn’t get assigned to newer people.
My favorite CTO/CIO acronym is "PFM". Such as, "and then we run through the PFM process, and it comes out and does..."
PFM - Pure Fucking Magic
I've only once ever had anyone actually ask what it means... essentially it's used as an abstraction for a complex process that would be excessive to explain in context.
I asked, after the meeting.
My cousin, when he got his first job, he managed to wipe the database clean on his first day at work. (classic, I know)
The seniors were very understanding, and more importantly it raised important questions about backups, dev vs prod pipelines, etc.
But you can bet my cousin was super embarrassed by it, and saving face was a big part of it.
I totally did this! Why would I need a database named “mysql” inside my MySQL database? Delete that, good job on day one!
Seniors should be the ones embarrassed for giving anyone, let alone a new junior, such level of access
Yup, my SR Director boss often says "I'm an idiot. Can you tell me what 'X' means when most of us probably wanted to know but were too afraid to ask
There are a lot of bad places to work, and those are the types of places that do things like replace junior devs with AI.
The place I work at is in the middle of a new CEO’s process of breaking the company. The company can’t go out of business, but we’ll set stuff on fire for another 12-18 months.
That's been my experience as someone who tends to ask them regularly. I don't have a lot of hubris when it comes down to it, so I'll almost always ask. Especially acronyms or industry/insider business terms... I'll usually do a quick search in a browser, but if the results don't make sense, will simply ask.
Asking stupid questions almost goes hands in glove with "it's easier to ask forgiveness than permission." A lot of times, you're better off just doing something. Asking a simple question or making something happen saves a lot of grief more often than not. Understanding is important.
I don't think that's the same. I spitball crazy ideas, but my core knowledge/expertise is sound, and I try not to talk out of my ass. (Or I am upfront when I'm outside my area of expertise. I think it's important to call that out once your word starts carrying some weight.)
A product manager can definitely say things that would make me lose a bit of respect for a fellow senior engineer.
I can also see how juniors have more leeway to weigh in on things they absolutely don't understand. Crazy ideas and constructive criticism is welcome from all corners, but at some level I also start expecting some more basic competence.
In general there are so many different sub-fields of knowledge that it's extremely confining to stay in one area of expertise; the slow uneducated person that has been working to keep some giant build farm running and migrating projects and helping fix tickets for 5 years will have a lot of expertise you don't have if you have a more casual experience of the system.
Company culture != national culture != personal culture. Such things can be all over the place.
I've worked with people from Korea who took me 100% seriously when I said the architecture was too complex and hard to work with slowing down velocity, and although they did end up keeping it there was no outward indication of lost face and they did put in the effort to justify their thinking.
I've also worked with some British, Greek, and Russian people who were completely unwilling to listen to any feedback from coworkers, only order them around.
Even within a person: I know a self-identified communist, who is very open minded about anything except politics.
My Entire career
"Why the f*ck are you asking, you should know this"
or
"Why the f*ck can you not look that up"
edit: There's an entire chapter of the internet with "LMGTFY" responses because people ask questions.
or
"Isn't it f*cking obvious"
or
"Do I have to f*cking spell it out for you"
There's a strong chance that I am autistic, which means, yes, I need people to be (more) explicit.
AI has done a hell of a good job making it easier for me to search for subtexts that I typically miss. And I receive less of the negative feedback when I have something to ask that does help.
A completely flipped perspective:
> "Why the f*ck are you asking, you should know this"
Because you mentioned NZ: my father, a toolmaker, said there was a huge difference between Europe and NZ. In Germany/Netherlands, he'd be working under a more senior toolmaker. When he took a job in NZ and asked the boss something, as would have been the proper thing to do in Europe, he got a response just like that: because he was the expert, and his NZ boss was just a manager.
Asking questions is a good thing but that doesnt mean ALL questions. It doesnt include questions you could answer with a google search or by reading documentation, obviously.
I agree - there is a baseline amount of effort that should be expected. I was once dealing with a co-worker who was treating me like an llm. I had to encourage him that our job isn't about knowing things, but figuring things out. There's also that slack DM's don't scale like documentation does.
Got it - ask questions, but not ones that you already know where the answer is.
edit: well, except when you search the documentation and get (literally) 70+ results because you don't know the exact phrasing used in the self hosted wiki...
Or, when it's a question that is domain specific (meaning that the SME is supposed to know it, which you only know if you are... an SME...)
etc
Provide context when asking.
: “hey bob, I looked here and here and here and didn’t find the correct information. Can you show me where to look or tell me the answer so I can document it”
Because most people don’t bother doing the tiniest amount of their own research before asking dumb questions it becomes a huge headache to answer the same thing a million times.
However, if you can show that you did put in the effort to look up the answer first people will be much more willing to help.
So far I have two examples (in this thread) of people making (potentially toxic) judgements about the fact that someone asked a question
Can you show why you assumed that what you are asking for wasn't provided?
Can you also explain why your response is to make rather harsh judgements rather than work out what was going on in the first place?
You can tell that this is a toxic environment because I am getting voted down, by toxic individuals, for pointing out that people in this thread have made the massive misjudgement of claiming that the blame for the issue lies in one person - despite having ZERO knowledge of the actual context of the responses received (and spoken about in the gp), or questions being asked.
Which pretty much sums it up doesn't it.
> Got it - ask questions, but not ones that you already know where the answer is.
More of, ask do the quick google search or check the doc before asking that question. If the quick search or look into the doc does not contain the answer, ask.
I am sorry that has been your experience. I have worked in a lot of "rough/gruff/hardcore" environments, almost all of my career, at companies that are widely recognized to be fairly political and antagonistic, and none of them have ever, ever been even remotely like this.
I found this varies.
Meta? Ask questions anytime.
Amazon? Not so much.
There’s also the benefit of being naive - like, juniors can be seriously audacious when they haven’t been burned a million times. I miss having excitement and optimism.
The Facebook "little red book" had a quote in it along these lines:
When you don't realize what you can't do, you can do some pretty cool stuff
This is huge and quite underrated I think. There are some angles that are really hard to see through a weathered lens.
the flip side of this is having juniors create some wildly unrealistic expectations in other business units if we're not careful ;)
It doesn't matter if the culture encourages it, you still don't want to ask dumb questions.
Culture varies.
Best VP I’ve ever had would stop meetings with regular frequency and say, “maybe I’m the dumbest person here, but I don’t understand [insert something being discussed], can you help me get a better understanding?”
It was anybody’s guess if they really didn’t understand the topic or if they were reading the room, but it was always appreciated.
I don’t know..this seems like one of those that is admired in HN but I don’t see in any of the multiple US companies that I’ve worked in. People are definitely concerned with looking dumb. “Losing face” may be something people here attribute to Oriental Cultures, but in practice it works similarly here too.
I have worked at a place where people were routinely criticized for asking basic questions on a big all-dev DL (which was archived and searchable, so they actually added to a growing record). The preferred solution was to ask a co-worker on the same team. People were answered a lot of questions were also criticized for being helpful. In neither case was the criticism that much from devs but from managers and given in boss feedback directly to people. Also it had a problem with spreading a good culture and common technical vision to new people, for some reason ( /s )
> They’re the only people in the org who are still allowed to ask “dumb” questions without losing face
I strongly disagree, a Senior who cannot ask a "dumb question" is a useless developer to me. Ask away, we want to figure things out, we're not mind readers. Every good senior developer I know asks questions and admits when they don't know things. This is humility and in my eyes is a strong market for a good Senior Developer. The entire point of our job is to ask questions (to ourselves typically the most) and figure out the answers (the code).
Juniors could or should ask more questions, and by the time you're a Senior, you're asking key questions no matter how dumb they sound.
You're making the same point as the person you're responding to. They're saying seniors are allowed to ask dumb questions. It's junior who are often afraid to do so.
> The thing people miss in these “replace juniors with AI” takes is that juniors were never mainly about cheap hands on keyboards. They’re the only people in the org who are still allowed to ask “dumb” questions without losing face, and those questions are often the only signal you get that your abstractions are nonsense.
This seems almost entirely wrong to me? That anyone, at any level of seniority, can ask "dumb questions" and give signal about "nonsense abstractions" seems a property of any healthy organization. That only juniors can do this doesn't just seem wrong, it seems backwards. I would expect seniors to have the clearest idea on whether abstractions make sense, not juniors.
People who are new to the business should be able to challenge the assumptions that the business has built up over time and ceased to question.
They are the most insecure, however, no knowing who will be annoyed, shown up, embarassed by that question if it suggests that some past decisions were wrong.
This is a really good and under appreciated point. My recommendation to mid-level, senior, and staff engineers is to keep questioning decisions and create a culture where that’s encouraged.
Junior devs do that naturally (if you have the culture) because they don’t know anything already. It’s great
> My recommendation to mid-level, senior, and staff engineers is to keep questioning decisions and create a culture where that’s encouraged.
Tell me you've never worked at FAANG without telling me you've never worked at FAANG...
I’ve worked at a couple FAANG and questioning things is pretty much always viewed as a positive when it’s done in a productive and professional manner
What isn’t viewed positively is when you refuse to accept a decision after it’s been made and your concerns have been heard. People get pissed if you keep relitigating the same points over and over again
My advice to engineer is always:
Your job is to make sure that the decision makers, when they're not you, have the information needed to make competent decisions. You should keep arguing when (a) there is credible reason to believe that important information has not been heard or understood or (b) when new information has come to light that you credibly believe might change the decision. In the absence of those two, your should accept that you have done your job and should let your managers to theirs, even if you disagree with them. Bring it back up when (a) or (b) changes, and not until.
I've worked in various teams on the infrastructure side of a FAANG from early career/L4 to sr staff eng/L7 and have always been encouraged and rewarded for asking questions, even when those questions have led to unexpected multimillion dollar costs and in one case a loss of ~1% of fleetwide compute capacity.
I think this comes down to how you go about asking. You have to take the time to understand what is and how it's seen by others by being curious, reading docs, etc instead of rolling in making assertions disguised as questions to assert authority like so many are wont to do.
I suppose it's possible that I'm the designated court jester and that's why I can get away with questioning, but I don't think that's the case :)
How did the questions lead to costs? Like your questions highlighted issues that already existed that you all then had to fix?
Usually the people who question decisions are shot down because they don’t have a wholistic understanding of the decision and (respectfully) don’t have good arguments. This is only because they are focused on some narrow aspect of the business which distorts or reduces their visibility and understanding.
One of the most regulated industries, aviation requires crews to go through crew management training where it's explicitly trained for lower level staff to raise concerns in spite of perceived superior knowledge.
Some of the biggest accidents have happened directly due to this. Like Tenerife where the flight engineer had been listening to the radio and raised doubts about the runway being free but was ignored by the overconfident captain.
> Usually the people who question decisions are shot down because they don’t have a wholistic understanding of the decision and (respectfully) don’t have good arguments.
It takes months of dysfunction until the customer says "I do not want to work with you anymore" or until the "overtime and over budget" thing suddenly becomes too large and problems show up in numbers. Or until key team suddenly completely decomposes. Every single time I have seen that, multiple people tried to communicate about the issue and were shot down.
It is not like management was always "wholistically" right and everyone down there just dont see big picture or have bad arguments - they usually just do not know what is going on on lower levels. Failure to actually listen, whether because it feels bad or because it would take time is quite common.
> This is only because they are focused on some narrow aspect of the business
Is this a bad thing though? If some technical decision has downside risk, I’d reasonably expect:
- the affected stakeholder to bring it up
- the decision maker to assuage the stakeholder’s concern (happy path) or triage and escalate
I think you are right. It's still worth encouraging people to question decisions even though most of the time it won't be the right compromise for the business.
This thinking pattern exactly illustrates how a group of very intelligent people can make disasterously bad decisions without anyone challenging them. Don't look for holes in the the arguments of people saying you are making a bad decision, look for the information they have that you do not have or have not explicitly analyzed. If you think you have all the information that the org possesses, go right ahead and make your choices without others; you might be lucky and be Steve Jobs post 2000.
I don't know how to calculate "usually", in my experience people who question decisions in my company are shot down because the decision makers are usually (no pun intended) very incompetent and the questions make that visible, even if not intended. Many companies that I know are so corrupt that competent people are considered to be dangerous for the status quo.
This is definitely a best case scenario.
As important as I think questioning is, there’s another side of it where people push their own agenda with questions on topics that were decided by other/more senior people hashing it out. At some point this does need to be dealt with. All I see is the yapping questions wasting meeting time, though.
Some of us intentionally avoid FAANG for that reason.
I’ve never worked at a FAANG and have no intention to.
I did work at Stripe, which in places did this pretty well. It still felt like a huge company (this was back in 2022) that had lost part of that spirit depending on org leadership. I had to pull that out of engineers who had been scared out of that level of vulnerability. But building that trust is part of leadership and great people tend to want to question and improve things.
As a staff engineer at FAANG... tell me you've never worked at FAANG without telling me you've never worked at FAANG.
I've given talks on work/life balance -- and I stand by those talks enough to argue with directors and above when needed, though it rarely is -- and an important part of that talk is about how much better it can look when you can intelligently describe the limits of your knowledge, skills, and estimation.
If you get penalized for that, you're just in a shit role with a shit manager. Don't project that on the rest of us.
Most of us haven't, good for you
So, I think there are two models.
One is a "one junior per team" model. I endorse this for exactly the reasons you speak.
Another, as I recently saw, was a 70/30 model of juniors to seniors. You make your seniors as task delegators and put all implementation on the junior developers. This puts an "up or out" pressure and gives very little mentorship opportunities. if 70% of your engineers are under 4 years of experience, it can be a rough go.
That second model is basically the hospital model.
You have 1 veteran doctor overseeing 4 learning doctors. For example operating rooms do this, where they will have 4 operating rooms with 4 less experienced anesthesist and then 1 very experienced anesthesist who will rotate between the 4 and is on call for when shit hits the fan.
Honestly I think everyone here is missing the forest for the trees. Juniors their main purpose isn't to "ask questions", it's to turn into capable seniors.
That's also why the whole "slash our junior headcount by 3/4th" we are seeing across the industry is going to massively, massively backfire. AI / LLMs are going to hit a wall (well, they already hit it a while ago), suddenly every is scrambling for seniors but there are none because no one wanted to bear the 'burden' of training juniors to be seniors. You thought dev salaries are insane now? Wait until 4-5 years from now.
Fred Brooks proposed "surgical team" structure, where as people gain experience they "bud out" new teams - i.e. the most senior after "the surgeon" ultimately leave team to become "surgeon" of a new team
I guess Peopleware couldn't get every single thing right.
A hospital model may be a good idea. One where you have a senior programmer and many junior ones doing most tasks isn't. IMO, something closer to a real hospital team, where you have experts of different disciplines, and maybe a couple of juniors composing the team has much higher chances of success.
> something closer to a real hospital team, where you have experts of different disciplines
That is not how hospitals work. The surgery departement won't have a crack team of different disciplines to teach budding surgeons everything. They'll only have veteran surgeons to guide less-experienced surgeons.
What you will have is interdepartmental cooperation / hand-off, and you'll have multi-discipline roles like surgical oncologist.
In the same way, you won't have devops seniors training front-end juniors.
A surgery team has a surgeon an anesthesiologist, a nurse specialized on material handling overseeing the material usage in the procedure, maybe a nurse specialized on equipment handling. None of those people are junior or subordinated to the others.
In my operational team, I'm following a third model, inspired by german trade workers. You have juniors, journeymen and masters. Juniors are generally clueless and need to be told what to do, specifically. This is very much the level of "Here are 28 marks that needs bolts placed in concrete, make it so, I can explain why". Journeymen should be figuring out a plan how to solve a project and challenge it with the master to see if it fits the quality requirements of the master.
And practically, you can have one or two journeymen per master. However, these 2-3 people can in turn support 3-4 more juniors to supply useful work.
This also establishes a fairly natural growth of a person within the company. First you do standard things as told. Then you start doing projects that mostly follow a standard that has worked in the past. And then you start standardizing projects.
My first big job was the 1 junior per team; those years were extremely good for learning how to design and write high performance services. Since then, I've mostly been at the 70/30 places where I'm considered senior. Occasionally I just sit down and blast out a big software project, just to feel I am still able, but mostly I tend the garden hoping that a few of the fragile stems will survive and grow into mighty oaks.
With the subjective view on what a junior is, I think the 70-30 - or higher - model is used in any company I ever interacted with. For this evaluation I consider junior=someone with less skills than needed to do the job autonomously/require direction and supervision most time, senior=someone that can work autonomously.
The real thing people miss is not AI replacing Juniors. Its that senior management soured on hiring juniors even a few years before AI, almost across all industries.
AI is now just the scapegoat for an economy wide problem. Execs found "one neat trick", piling junior work on seniors until they quit. While not hiring replacements in order to goose short term profits. Now every company is in the same position where hiring a senior really means hiring 5 seniors to replace the one that had 5 jobs layered on over a few years. This is of course impossible for any mortal to jump into. Now they also dont even have juniors to train up to senior levels.
Good juniors are also great at just working. Usually no family so they are able to put in a lot of attention into work and they have that innocent curiosity and can-do in them which brings a lot of positive energy.
> put in a lot of attention into work and they have that innocent curiosity
They're also good at putting company code into ChatGPT.
/snark
I think the biggest challenge now becomes how more seasoned engineers teach juniors. The AI makes the ramp a lot easier but you still do best when you understand the whole stack and make mistakes.
It’s damned near impossible to figure out where to spend your time wisely to correct an assumption a human made vs. an AI on a blended pull request. All of the learning that happens during PR review is at risk in this way and I’m not sure where we will get it back yet. (Outside of an AI telling you - which, to be fair, there are some good review bots out there)
Junior engineers now learn from AIs. And AIs now learn from RL cost functions. And RL cost functions are being set by PhDs, with little to no production grade engineering experience ;)
The result is interesting. First, juniors are miserable. What used to be a good experience coding and debugging, in a state of flow is now anxiously waiting if an AI could do it or not.
And senior devs are also miserable, getting apprentices used to be fun and profit, working with someone young is uplifting, and now it is gone.
The code quality is going down, Zen cycle interrupted, with the RL cost functions now at the top.
The only ones who are happy are hapless PhDs ;$
I sense a lot of hate/baggage in this post subtext.
Really, juniors are only important because they ask "dumb" questions that can help remove useless abstractions? That your take?
Yikes. Sounds like you work for a toxic company. The mid and senior level engineers I know all go out of their way to ask the dumb questions. Every junior employee I've mentored, I've told them the main way they can fail is not asking questions early and often. Gotta build a culture that supports questions.
AI will replace jobs. People are putting their IT/dev budget into something, which means something else will be cut.
I also don’t believe juniors, kids, seniors, staff, principals, distinguished/fellow should be replaced by AI. I think they WILL be, but they shouldn’t be. AI at Gemini 3 Flash / Claude Opus 4.5 level is capable with help and review of doing a lot of what a lot of devs do currently. It can’t do everything and will fail, but if the business doesn’t care, they’ll cut jobs.
Don’t waste time trying to argue against AI to attempt to save your job. Just learn AI and do your job until you’re no longer needed to even manage it. Or, if you don’t want to, do something else.
> People are putting their IT/dev budget into something, which means something else will be cut.
That's not how things work in normal times.
But normal times require minimally capable managers, a somewhat competitive economy, and some meritocracy in hiring. I can believe that's how things will work this time, but it's still a stupid way to do it.
Yes, the most helpful things AIs do is to guide people into popular environments they don't know very well.
Or in other words, the people that get the most value from AI are junior devs, since they still don't know very well plenty of popular environments. It's also useful for seniors that are starting something in a new environment, but those only get 1 or 2 novel contexts at a time, while everything is new for a junior.
Or, in again another set of words, AI enable juniors to add more value more quickly. That makes them more valuable, not less.
> you’re basically saying you want a company with no memory and no farm system – just an ever-shrinking ring of seniors arguing about strategy while no one actually grows into them.
Isn't that also the explicit aim of AI replacement, as stupid as it sounds? To me, the idea appear to be separation of money and work, so that economy will be strictly the concern of a metaphorical upper floor, floating in the thin air.
I don't agree that this is the central value juniors provide. Its a nice tertiary value, but not why one hires them. I think the value is the later part of farming for new talent and just growing your team.
I still think the central issue is the economy. There are more seniors available to fill roles, so filling out junior roles is less desirable. And perhaps "replacing juniors with AI" is just the industry's way of clumsily saving face.
I don't think many orgs learn all that much from coaching their juniors, at least after first few.
Juniors are just... necessary in the balance, have to little of them and the mid and senior devs will get more and more expensive, so you hire a bunch of juniors, they get trained on job, and it balances it out.
Hell, if company does it right they might underpay junior-turned-senior for decade before they notice and look how industry pay looks like!
I agree, the routine is gone, but at what cost? Understanding "how our system fits together" means solving problems, reading code, and debugging. If those fundamental skills aren't built through "humiliating and boring" tasks, how will a junior understand how the system actually works, not just how it appears to work?
That's a perplexing take based on how I've experienced the past 15 years: the more senior someone is, the more questions they tend to ask.
I'll also add the obvious answer in that real companies constantly have seniors leaving/retiring. Juniors are meant to be trained up to be the future seniors of the company. You should consistently feed and grow this pipeline unless you think you won't exist in the future or AI will replace all jobs, period.
I think the main benefit of junior devs is that it’s the only pipeline for getting senior devs. The other benefit over AI is that most of software engineering is not writing the code, but doing all of the other stuff like working out what to build, flagging concerns, operating the software once it is running, etc.
If that was the case I would be chilling during my junior years.
Juniors are usually given either grunt or low priority work while seniors get more "important" work.
OTOH, it takes a lot to get your questions on RIGHT EARS when you're a junior, so wouldn't agree with your characterization at all.
It really depends on the workspace. Some places will give juniors serious work items specifically to grow them.
I generally agree with you but AI confusion is also a good signal your abstractions are nonsense.
One problem there is that people would rather believe the AI is "dumb" than face the facts.
I’m a senior engineer on a staff track, I am proud to ask “dumb” questions all the time, and I don’t want to work somewhere where I don’t feel safe pursuing knowledge openly and candidly.
Agree.
> cargo-culting Stack Overflow
What do you mean by this? I understand “cargo-culting” as building false idols, e.g. wooden headphones and runways to attract airplanes that never come.
It means to copy code or instructions from a site into your own project without having any comprehension of how or why it works.
example: you have a Windows problem. You search and read that "sfc /scannow" seems a popular answer to Windows problems. You run it without ever understanding what sfc does, whether the tool is relevant to your problem, etc. You are cargo culting a solution.
I think the idea is copy-pasting code snippets from StackOverflow without comprehension of whether (and how) the code fixes the problem.
Cargo-cult in relation to programming exists since late 80s.
http://www.catb.org/jargon/html/C/cargo-cult-programming.htm...
https://en.wikipedia.org/wiki/Cargo_cult_programming
plugging your AI newsletter at the end of your comment comes off as an indicator you want to farm engagement, not genuinely stimulate conversation.
This is actually a super power I have after spending my first part of my career in sales.
I was never formally trained so I just keep asking "why" until someone proves it all the way. Sales itself is also a lot about asking questions that won't come up to find the heart of the thing people actually want... which is just another side of the coin.
I mean, that’s an interesting take, but “having people around to ask dumb questions” is not why most orgs hire juniors.
In my experience, juniors are absolutely terrified of asking any sort of question at all during a meeting. Senior engineers are far more likely to ask interesting, useful questions.
We hire juniors so that we can offload easy but time-consuming work on them while we focus on more important or more difficult problems. We also expect that juniors will eventually gain the skills to solve the more difficult problems as a result of the experience they gain performing the easy tasks.
If we stop hiring juniors now, then we won't have any good senior engineers in 5-10 years.
>They’re the only people in the org who are still allowed to ask “dumb” questions without losing face
This is the only role of executives, sales people, account managers. They usually do it with complete and utter confidence too. Vibe-questioning and vibe-instructing other people without a care in the world.
[flagged]
What will eventually pan out is that senior devs will be replaced with junior devs powered by AI assistants. Simply because of the reasons you stated. They will ask the dumb important questions and then after a while, will even solve for them.
Now that their minds are free from routine and boilerplate work, they will start asking more 'whys' which will be very good for the organization overall.
Take any product - nearly 50% of the features are unused and it's a genuine engineering waste to maintain those features. A junior dev spending 3 months on the code base with Claude code will figure out these hidden unwanted features, cull them or ask them to be culled.
It'll take a while to navigate the hierarchy but they'll figure it out. The old guard will have no option but to move up or move out.
Why would Claude code help you find unused features? The end customer uses features, not the AI. I would want to know from the end customer whether a feature is unused, and a Junior with an LLM assistant is not going to be able to tell me that without adding new features to the code base.
Am using Claude code as an approximation here. 2 years down the line the tooling around analytics will get integrated in AU assistants and they will be absolutely able to figure out unused features.
How do you suppose the old guard are filling their days now?
At some level, aren’t you describing the age-old process of maturing from junior to mid level to senior in most lines of work, and in most organizations? Isn’t that what advancing in responsibility boils down to: developing subtlety and wisdom and political credibility and organizational context? Learning where the rakes are?
I wish 3 months, or even 3 years, were long enough to fully understand the whys and wherefores and politics of the organizations I cross paths with, and the jungle of systems and code supporting all the kinds of work that happen inside…