It's not just PMs though: developers are forced into resume driven development by hiring practices. If they stick to the toolkit already established in the app they set themselves up for a career trajectory towards Uber driver. The risk of knowing only what was fashionable five years ago is just too big.

50% of the reason Kubernetes is getting so popular, devops people need k8 experience to move up in their careers and therefor your company is now using k8.

I think ai/llm have overtaken kubernetes in this regard, everything’s needs to be solved with AI, even if it doesn’t solve the problem in a better way. But I guess that’s also part of the learning process, trying it everywhere to learn from experience what doesn’t work.

We’re adopting kubernetes to run “ai” with kubeflow. Modern problems require more problems taps forehead

> It's not just PMs though: developers are forced into resume driven development by hiring practices

I was laid off from my last gig in January because the company was running out of money. Last week I saw a former coworker share how excited they were to turn a perfectly functional and internal website built with html and css into a react app with redux and nextjs. I couldn’t believe a company running out of money would have a developer do that when it doesn’t affect revenue generation whatsoever. And I can’t believe the dev didn’t stop to think that the previous website was already perfect. There were never any complaints. Their LinkedIn post had tons of likes. I’m happy that they were happy, but I was left a little concerned.

This is what happens when everyone is trying to do busy work to make themselves look productive and less likely to be laid off.

Taking it a step further, this is what happens when the monetary authority's mandate is maximum employment and not maximum production. We're optimizing against efficiency.

Literal cargo culting. The mindset, of whoever is approving those decisions, is often that they just need the right software ‘cargo’ to attract more money and save the company.

> the grumpy ones

You know, grumpiness really is a thing. I wonder if it should be treated as a symptom like left arm tingling before a heart attack. A call to make some serious changes.

Meh, developers are people too. They are right and they are wrong. I've seen some guys who are proud of having the grumpy persona, which is really just a nice word for "I know better than the other people I work with" and it's not a great attitude. Engineering choices all have trade-offs yet the grumpy guys always frame it as "my way or everything will collapse later".

What attitude is the appropriate one if everything will collapse?

There are long-tail risks to the stability of codebases, organisations, institutions, governments.. the soviet union collapsed.

It seems likely that some engineers can intuit such long-tail risks.

If linkedin is subject to a competitive threat which requires rapid innovation, the org will lose because it's development practices preclude it.

> What attitude is the appropriate one if everything will collapse?

Short the stock.

Sorry, should have been more clear.

It is when you - a normal, well adjusted engineer - realize you are feeling grumpy about something.

It might be a sign to explore what is really going on.

Agree with this. And why it’s important to have spaces to blow off steam and vent without being shunned as a bad team player or whatever. I’ve seen quite a bit of toxic positivity that makes people sit on their grievances in silence instead and become complicit and resentful (like the parent comment mentions). It’s much better to air it out - oftentimes there’s constructive things behind discomfort. In fact, discomfort is a guiding light for innovation imo.

> This is a perfect example of why the problem isn’t...

Depends on how you frame the problem.

If you declare the problem is that although batteries became way more efficient you don't get out more hours because they are wasted, then the story is a different one.

Same when you don't have an abundance in RAM but are forced to use certain programs and applications. I have 64GB Ram these days, colleagues at clients of mine only have 16GB and they face certain challenges I don't, because of the tools forced upon them by their superiors.

These problems can be real, they can be "artificial" (there is a philosophical note to this somewhere ;)), but in the end, there is undeniable truth that launching a whole browser engine for each and every app can be and indeed is wasteful compared to alternatives.

Of course if you don't see this as a problem "ex falso quodlibet" takes precedence and it all becomes futile to discuss :)

It goes opposite way as well. I have workstation with 128GB ram with a few terabytes of storage, I can run full stack with everything in single machine. I also have VM snapshots, versioning etc... There is simple script that installs all deps and setup dev machine.

My colleagues have tiny Macs with 16GB. To accommodate them, we had to split mono dev setup into separate K8S cluster.

On single machine I could easily split test build process. Now we have spaghetti of dependencies. And spinning up secondary dev instances is not permitted due to high AWS cost.

So investing result binary (like this blog post) is now impossible.

> And spinning up secondary dev instances is not permitted due to high AWS cost.

Time for a new employment opportunity.

> there is undeniable truth that launching a whole browser engine for each and every app can be and indeed is wasteful compared to alternatives.

Wasteful and always, always a worse experience. I'm sorry if this ruffles feathers here or people feel called out, but I can FEEL the difference in these web-cruft apps every single time, full stop. I would Pepsi challenge this as many times as people want and I will eat my snow boots if I get it wrong.

If you make your app with web tools, I will not use it if I can conceivably manage doing so. And if I must, then I guarantee you I will do it as grudgingly and as little as I possibly can.

Sounds like bad product management as much as bad engineering. I mean, the outcome — a bloated product — is bad for everyone: the users in the first place, the engineers building the product, but also the PM who can't conceivably be proud of shipping a bad product.

In my experience PMs are not rewarded for good product, but rather a mix of shortsighted metrics and whatever their VP/senior person has on their personal agenda. At big companies, employees are often not even using their own products. The corporate ladder is all that matters.

Obviously that’s not unique to the PM role, but seemingly more prevalent. I think it’s an effect of the rootless roaming you get when you spread people thin over large areas, and don’t have clear ownership and responsibility – which I think is a prerequisite for (the good kind of) pride.

But overall, yes, it’s definitely a structural issue with the organization at large. Clearly, when it’s gotten as bad as in this case.

>In my experience PMs are not rewarded for good product, but rather a mix of shortsighted metrics and whatever their VP/senior person has on their personal agenda. At big companies, employees are often not even using their own products. The corporate ladder is all that matters.

YES YES YES. It's why I gave up on working as a product manager after nearly a decade. It's turned into KPI Management and everyone suffers, especially if you care about delivering good product

What career did you transition to?

My background is natural sciences, so I took a paycut to go back into an academic lab and rekindle my bench chops. Been really fun so far and my hope is to continue working in the field as a lab manager or researcher in the private sector. Won't pay as high as a software PM, but a lot more satisfying and healthy

I very much agree and I've seen that a lot in large companies. I really like how Bain explains it: "growth creates complexity; complexity kills growth". They talk about in The Founder's Mentality: https://media.bain.com/the-founders-mentality/

I also agree about your point on ownership and responsibility. That's why I like Amazon's principle of Single Threaded Leaders.

"The best way to fail at inventing something is by making it somebody's part-time job" — Dave Limp, CEO, Blue Origin, formerly Amazon

Best product people I've worked with operated alongside QA and support instead of engineering.

Yup. If you're not talking to customers and hearing the problems on the front line you run the risk of solving problems nobody has.

There is a balance though - in some cases you have to roll the dice and strike out in bold new directions. But this needs to be done with eyes wide open and everyone in full acknowledgement that this is an experiment and conversations with users are the next step.

Perhaps, but in my experience, this is often what happens when you have too many cooks.

People like to build corporate empires by having more subordinates. Those subordinates need to justify their existence somehow. Bloated, inefficient software is one of the unfortunate outcomes.

It's like Parkinson's law, but extended to other resources besides time, like capital.

Similar to Myhrvold's laws #1

https://blog.codinghorror.com/software-its-a-gas/

Some of my friends who work in similar situations call this "job security".

You joke but when something is really bad I make a point of saying it is "job security" for myself in front of my tech lead (and my teach lead's manager). It triggers something in their heads that "oh, if he quits we are screwed". Those things tend to get addressed.

There other bad things I don't refer like that, like something that is bad but if I quit and they get a new guy he can probably figure it out in a few weeks tops.

>go on a PM-centric feature frenzy

Do developers have any agency whatsoever, or are they at the mercy of doing whatever their managers suggest (while always knowing the "right" answer, of course)? Does our industry attract people who avoid accountability?

Fraud? It's the executive's fault. Business struggling? It's the MBA's fault. Bad product? It's the PM's fault. Must be nice!

Maybe when you tell your engineers you need X feature implemented in two weeks, leaving them no time to plan or refactor, and they're building on an already bloated, ancient spaghetti codebase because every deadline has been two weeks under a skeleton crew for the past decade...

They have very little agency. Priorities are driven by OKR’s, which require measurability as one of the core tenants. If you want to accomplish something, you must be able to point at a number somewhere, and have a plan to make it to up and to the right. Refactorings to pay down tech debt rarely can pass as OKR’s unless there is a true business need.

This is a feature, not a bug, as far as management is concerned. They’re often proud of saying things like “if you can’t measure it, it doesn’t exist.” There’s often managers that are very sympathetic to the idea of pushing for quality, but then they’ll ultimately say something like “but, if you can’t come up with a number to show benefit, perhaps it really isn’t worth pursuing ¯\_(ツ)_/¯” and we move on to the next feature.

The only way any real quality improvement happens, is if motivated individuals do the work basically on their own time. You will not get organizational support for it. If you’re lucky, it will pan out and an improvement will be made. If you’re not, maybe your refactoring causes a regression somewhere (nobody’s perfect!), someone notices, and if that person is particularly angry about it you’ll get yelled at for making “rogue changes” that cause bugs. If your rogue change was done in some other part of the codebase, you’ll probably have your access revoked (ie. others will be put on the approval chain to prevent you from making such changes again.)

Your post sort of boils down to me as "be annoying and measure stuff all the time" or "hope you get lucky". I think there's a middle ground in there but it's too easy to err on one side or the other ad a methodology and then get stuck - either you're ruled by OKRs and playing games with metrics and juking the stats all day, or you're shooting blindly in the dark with no direction or accountabilities.

Or you can trust your engineers to know where the quality issues are (they live in the code base all day) and trust that when they say fixing something is important, and that they can make a logical case for it, that it should mean something.

Quality doesn’t come from metrics, it comes from giving a shit.

On balance, devs have more agency than ever before, but they choose to use it to load in every daft technology imaginable that makes their resume look good. IMO developers are less and less inclined to act like professionals that bring data to the decision table, so as to create meaningful business solutions.

Take scaling for instance: there is such a thing as unnecessary scaling. I've seen junior devs in AWS shops insist on embedding insane levels of serverless AWS tech, all to serve minimal systems with minimal data and bandwidth and minimal customers. When questioned about the drivers for all of this scaling, they have no reply - its all fairly obvious that they feel that they do not have a career without all of the latest TLAs on their resume.

Apart from creating billions for Jeff Bezos, this is creating bloat on staggering levels. PMs are often unable (or unwilling) to push back, because who wants to questions devs these days?

> I've seen junior devs in AWS shops insist on embedding insane levels of serverless AWS tech

I see senior devs doing that all the time as well; they have resumes to work on as well. Applications that probably will not get more than a few 10000 hits a day, if that, getting set up and stress tested so someone can say ‘set up app that could handle millions of hits a minute’. All on the company’s dime of course.

> punish the grumpy ones in favor of the people-pleasers, that this crap happens

This isn’t exclusive to technology, but I see this all the time at my large organization. As a grump, I have to pick which shitstorm to care about and spend my time chipping away at, which ends up being really draining.

To help with this, we began focusing a team of great folks with shared values, leaning in on modern operations/SRE best practices.

We started to have some real success with SDLC for our operations workflows.

That’s when management changed our teams direction. Good times.

Especially when everything's on 2 week sprint cycles, and all of those new features are rushed. We can refactor later!

We're not doing waterfall, but we're going to plan out every little detail of a change into small parts and plan out how many sprints it should take to do them all and split that work across the team so that you are always relying on someone else's work or somebody is waiting on you to start something.

Literally described my workplace, and it won't change b/c everyone wants to game theory the wrong way to make themself look like a 'team player' (I hate that term)