alt Hacker News>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.
Replies
> 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.
That's great and all, but that's a small minority of all software written. I'd love to work on projects like that but ultimately I have to pay the bills. Many software engineers are in the same boat I am.
Now I guess I'm just up shit creek because I built a career on SAAS work that was available instead of holding out hope I could get in at my dream job working on game engines or some other non-SAAS product?
Sorry if I sound bitter. I'm variations tired of hearing variations "If you only worked in SAAS you were always close to meaningless and now we've automated you so you don't deserve to earn anything anymore". Feels like every day.
> There's also a spectrum of hard-to-easy in enterprise software but it's much more narrow than engineering code bases.
I'm not going to bang this drum too much, because it's been done to death for well over a decade, but lines-of-business supported by CRUD apps are rarely simple from an engineering perspective. Much of that engineering is in the decisions made outside the codebase, or spread across multiple codebases. If you're looking for the one obviously brilliant line of code to tip your fedora to while sipping your snifter of wine, you're not gonna find it. In fact, "clever" code like that is rightfully and instantly rejected as cowboy code.
By your reasoning, civil engineering isn't "real" engineering like aerospace cuz they don't build things that go really really fast and shoot out fire and stuff. Also, there's like too many responsibilities delegated out. Like, man, I only wanna talk to the guys who put the rockets on the thing. Everyone else are just overpaid slackers that smooth talked their way! They're gonna get replaced by AI! Mark my words!