>This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.

>What tends to happen is that the EMs and PMs look at who’s free and give that person the task.

The gp you replied to qualified it with "enterprise software" (LOB, CRUD, etc aka "cost center") so your observations where senior -vs- junior engineers being more fungible can be true.

However, in "engineering" type of software products (game engines, RDBMS engines, operating systems, etc) where the software is more often a "product" that's sold (aka profit center) ... there are definitely different layers of complexity where senior and junior engineers are not fungible at all.

One way to describe the differences of complexity and criticality in various parts of the source tree is the "core" parts vs the "leaf" parts. E.g. in a game engine or Linux kernel, the deep parts of the engine or os process scheduler where the tight loops are located are the "core" parts. They most likely would be worked on by the most senior people.

But the game engine may have some less complex code for handling text width on a menu for different foreign languages. Or the os needs a new menu option on the installer to ask for the users age. Those would be more "leaf" functionality in the source tree. A junior could get assigned to those parts with less risk. After a few years of experience, he might be trusted enough to work on the deep "core" logic without screwing things up in catastrophic ways for a million customers.

A product with several million lines of source code will invariably have both the "hard parts" and "easy parts" so the new hires and juniors will work on the easier stuff first.

There's also a spectrum of hard-to-easy in enterprise software but it's much more narrow than engineering code bases.

Oh I'd say its real. Years ago I worked as that senior who divvied up the work to a team of 4 mid-level engineers in that exact fashion (they were mostly Latin American contractors with limited english). We actually shipped some good stuff too!

Unfortunately, looking back, I could easily see Claude replacing 3 out of 4 of those developers. Myself + one other dev + AI would probably would've shipped a bit more a little faster. With that said tokens aren't free so the net cost savings would've been 2 dev salaries maximum.

Nor have I seen this "punch every hiccup into google" approach. Most errors are things that (a) you've seen before if you have any significant experience and (b) have a pretty obvious cause if you simply read the error message and look at your code.

Sure you might lean more on Google or SO if it's something you haven't seen before, or it's something deep in a stack that isn't code you actually wrote. But as the noob eventually learns when he thinks he's found a bug in a runtime or compiler that thousands of other people are using every day: No. It's probably your code.

I suppose there are people who never advanced beyond the "type (or copy/paste); run; google the errors" loop, but I've never seen anyone with more than a year or two of experience doing that very often.

> This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.

I would have said the same thing for the first 15 years of my career across several jobs and acquisitions.

Then I took a job at a company that fit this description. They had so many managers and PMs that every task was talked about, broken down, and documented so much that every Jira ticket was a little piece of work that a junior could handle by Googling things.

The quirk was that they had started hiring a lot of experienced and staff level engineers, too, but then tried to force this same framework on to everyone. We spent more time discussing tasks than doing them by a factor of 2-50X. There are some situations where this is appropriate, but none of our work was actually high scale or difficult. Your day might be spent writing design docs and collective sign offs as you worked through committees until the tickets at the end were so simple that any junior could do them.

It didn’t lead to better software. It was one big cargo cult game of performative management. A frequent outcome was that someone would get into the micromanaged tickets and realize there was a better way to handle something, but it wasn’t worth doing all of the fighting and meetings involved to do the meeting and Jira ticket dance all over again.

> If your company is highly product driven, you’ll often find that the juniors end up lea[d]ing projects more often than not because they will tell the PM exactly what they want to hear

I worked in a company where this happened, and it wasn't pretty. Product managers used their experience and seniority to intimidate junior engineers and exert control over project management of engineering projects, which they predictably used to move as much work as possible to post-launch, including testing and security. They also gaslit junior engineers into agreeing that issues with contradictory or impossible product asks could be figured out later, leading to software getting released to customers that fundamentally could not be made reliable, performant, or even secure.

Even after the entire company went on site visits where customers told us they weren't using any of the features released in the last year because they were all buggy, and the only information they wanted about upcoming releases was assurance that their use cases wouldn't be impacted, product still kept claiming that the time it took to release new features was the biggest problem facing the company and kept fighting back against engineers who said we were in a quality crisis and desperately needed to make time for better testing and design.

The only thing that can shield you is good engineering management. Weak management will end up getting rolled by product and start promoting the bad behavior that product insists on. At that company I had a boss whose attitude towards us was "engineers in a startup should make decisions independently and stand by their work" but made sure engineers felt unsafe making engineering decisions that product wasn't happy with, likely because they felt unsafe themselves.

>This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.

Same but with 10 years, and I don't think I would do well in a place like that. That removes you from writing code and there is a similar complaint about relying too much on AI and not writing enough code on your own.

I've never thought about it this way before but this definitely mirrors my experience

> but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice

I've seen a twist - not juniors but just offshore engineers.

> I’ve worked at a lot of places over 20 years

Primarily in Silicon Valley or outside of it?

I worked most of my two decades in the Valley but also spent time outside of it. There is in many cases a vast gulf between the dev cultures. What the parent comment is describing I've seen many many times.

I think that’s a completely different problem.

I’ve worked with two junior devs recently who are very good precisely because they’re trying to understand what they’re doing, rather than just producing code.

I’ve also worked with senior devs who basically gave up and stopped trying to understand the code. They became much worse engineers as a result. At this point I would much rather work with those 2 juniors.

They use it to explore things they don’t understand, ask me questions to clarify their reasoning, double-check assumptions. They generally use the tools available to increase their understanding.

It's true that developing junior devs is challenging (but it always was), but that's not what this is about: This is about the kind of not-that-good, mid-ass programmers who make up the silent bulk of the industry. The ones who have 20 years of experience, but who you still wouldn't trust to write fizzbuzz.

Those people are doomed. Which is fine in a lot of ways, but will be devastating for their economic prospects.

Yeah. Technology and social change has done this all over the economy. E.g. from my dad's field, there's not enough public health people with field experience to replace the folks who are retiring. We have plenty of entry level people who can't get a job, but then there's a gaping hole in the pipeline between them and the graybeards who are retiring.

by then we'll have an mfc, instead of trying to get llms to write code our prompts will compile and execute efficiently. after that inversion "programming" becomes "using language to describe some processing" it's just writing. knowing a computer language of old helps but not necessarily

also who knows if prolonged ai development for years actually doesn't atrophy your coding muscles so to speak such that you are fully reliant on ai programming to get things done

> Kind of like the fortran crisis of the last decade or so....

I’m convinced the only reason there’s a Fortran crisis is because nobody wants to work on Fortran or make a career out of it.

Has nothing to do with willingness to hire juniors. Good luck finding promising juniors who survey their career opportunities and decide that Fortran is a good technology for building their resume.

It also ignores the effects of having a critical tool in the software pipeline controlled by a large corporation. That is an absolute sea change from the years when you could (and some of us did) run most of our software development on open tools.

Think about all the open source the world got from some random person in Finland or Sicily or wherever hacking on a cool idea. Will that still happen with a high (for someone who is not employed... maybe a student) monthly cost?

I think that smart companies (don't laugh, a few exist) will still hire juniors. Fewer, more carefully selected, but still some.

The StackOverflow devs being replaced were never going to become real senior developers no matter how much time was given to them. There is an entire cohort of people who were told to go to college for programming because it was an easy way to make good money, who did what they were told while having zero interest in it and never touching a line of code outside of work/school hours. Those people were never going to understand actual programming, all they were doing was copy-pasting code for a paycheck. Does it suck for them that they're being replaced by automated copypasting bots, yep. But frankly speaking nobody should've ever been paid 6-figure salaries to copy paste snippets from SO and jam JS library legos together in the first place.

By contrast I have not worked anywhere that engineers originated tickets. And thankfully, only one place that used Jira (but the engineers didn't interact with it).

Tickets came from the product side, after being evaluated and prioritized. Engineers got involved with estimating effort (in "points") and doing the actual implementation of course.

My last job was like that, it was miserable having no agency. The whole team was from fang companies and were all ok with the tell me what to do dynamic.

Do you think it's acceptable to do the work of multiple full time positions? I can't imagine it's very sustainable, nor healthy for you (both body and soul).

Not really in my experience. I’d much rather have just the prompt rather than the seven paragraph slop

Django? Django is older than jQuery…

Nobody is getting paid significant money just to build a simple CRUD app. Even before AI. Companies pay experienced engineers because the supposedly simple CRUD sits inside a messy real system with years of business rules, constraints, integrations and bad decisions have consequences.