You can actually make a very comfortable career of Senior and Staff by learning to identify this kind of work/system and proposing ways to simplify it. These kinds of systems, as the author pointed out, are incredibly expensive and inefficient, but look readable on an architecture diagram.
As opposed to all those people that make similarly comfortable careers in middle and upper mgmt by identifying simple systems and complicating them beyond recognition?
Hah, yes. I will say that while I understand the general disdain here, as I grew more senior in my career I realized the world takes all types. There are "doers" who will rush to an end goal that's highly prioritized and then there's "optimizers" who come fix that mess up into a durable, cost-effective system. Some people are gifted enough in knowledge and have the right business priority to do both at the same time, but usually they're required at different times.
Anecdotally, optimization tasks (in this brain) are multitudes easier than innovation tasks. I spend a lot of time thinking about how to do things differently whereas optimization utilizes many lessons I've learned over and over again with well-trodden patterns. That's to say, I'm grateful for the doers :)
These roles aren't opposed at all, they greatly benefit each other :-)
Bringing what used to be the privilege of upper management (wasting massive amounts of resources while getting paid handsomely) down to software developers.
It's that trickle-down effect people talked about, right?
Hmm looking at your git statistics it appears you have only pushed 60 commits this month with 12,000 lines of code changed - while Jimmy over here has pushed 200 commits this month with 200 lines of code changed.
If you do not improve next month we are going to have to let you go, we just cant carry a 0.3x employee such as yourself.
> You can actually make a very comfortable career of Senior and Staff by learning to identify this kind of work/system and proposing ways to simplify it.
I've typically worked in SRE and platform engineering work and that's where I've gotten exposed to these kinds of Rube Goldberg machines. Make a short list of them when you find them and then use them as a hit list during "cost cutting". Most people don't want to touch these systems because they look big and expansive and generally "work". They're just very poorly optimized.
Dare I say, any time I see a function as a service my brain immediately drifts to inspecting the cost implications of said process.
Most large companies. There is a stark difference between the distinguished engineers and the tier below them in terms of asking people to stop doing things badly.
Tried it. Nope. You can get people to acknowledge it but because it's not a fun project or doesn't involve an upsell you can bill the clients for, it'll go in a product backlog for a decade or two.
I don't care any more. I'm just there to tell people what's shit and then laugh when it explodes in their face.
The easy part is choosing a better end-state; anyone can do that, and for any of these Rube Goldberg machines at a large-ish company, several people likely have.
What makes someone a staff+ is finding a path to iteratively evolving towards that end-state without breaking anything along the way and while having progress to show off at each step.
