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

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.

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.

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.

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 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 seen a twist - not juniors but just offshore engineers.

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

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

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.

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?

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.

usually in most when engineers tend to create their own tickets - it's for useless shit like improve x, clean up y etc.

very few people have worked in places with high agency - where you work with a higher up & create a feature/product line that has customer impact. startups are one of the few places I can think of with high agency.