>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.

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.

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.

> 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.

>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.

> 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.

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.