I think you are both right.

But I don't think GP was ignoring clients. If anything, he was doing what those clients wanted by moving to containers and a cloud architecture. And I say that as someone that doesn't like those things.

I've never seen outsourcing of a company's core product result in anything but litigation. If a team legitimately made a 2000% leap in throughput and it wasn't just from manipulating metrics, and then that still wasn't good enough then nothing will be satisfactory in the eyes of that owner, you rightfully should give up that battle and find greener pastures. Expecting someone to come in and wave a magic wand of 4000% productivity is absurd. Expecting that you can outsource that sort of demand is plain stupid.

There are a lot of managers who believe you should always put a squeeze on devs and keep the org in constant panic mode. Nothing will ever be good enough. If you achieve one goal, you get hit with another crazy deadline. It never ends.

> but, on the other hand, being client focused and continuously delivering client facing feature, might be the thing that keeps the revenu streams coming

I firmly reject this. If you can't build quality then you don't deserve to be in business

I'm so sick of the fact that everyone is ok accepting "just barely passable"

It has lead to everything new being built is crap. New housing is crap, new furniture is crap, new software is crap

I get that building nice things is expensive and takes time, but I want to live in a world of nice things instead of this constant race to the bottom, produce endless quantities of crap world that we are in right now

Doesn't anyone else feel like we're being crushed under all this crap we're building?

I do get frustrated with the state of modern software, but often times the comparison ends up being between a crappy version of something or nothing at all.

One of the major problems is that many of our core software assumptions were based on design decisions made decades ago, when the industry was young and figuring out a million details.

I've mostly done web dev, but recently was trying out IMGUI and was amazed by the tiny memory footprint and with how quickly it started. But even that system has limitations, requiring that you learn a bunch of details for targeting different platforms. Isn't it amazing that native cross platform development is still so difficult in 2024? The platform owners could so a lot to ease this burden, but everyone wants their own little fiefdom.

> The platform owners could so a lot to ease this burden, but everyone wants their own little fiefdom.

The thing is that most people use one platform. So the owners try to present one consistent view on how to use that platform. Trying to provide a common paradigm across platform is the goal of companies that love their brands too much. But as a user, I just want for everything to function similarly so I don't have to read a manual for each app. I've done Android dev and dabbled in iOS, but now I'd only recommend React Native if what you want can be a web app, but you want the extra UI performance and some native features. If you want something more complex or consistent, go native.

I don't know where this idea came from that an application should look and feel exactly the same across Windows, Mac, Linux, iOS, Android, and so on. I have encountered this attitude in more than one company, but have not heard of any actual customer who wants this. As an actual computer user, the worst applications tend to be the ones that stick out like a sore thumb by ignoring OS conventions and using custom-drawn controls with nonstandard behavior.

> I'm so sick of the fact that everyone is ok accepting "just barely passable"

Isn't everyone ok with that by the definition of "passable"?

"Just barely passable" is the endless customer support carousel, the nickel-and-diming of airline fees, the addition of more and more ad space and cloned-content spam to web pages, and automobiles that spy on you to sell the data to marketers.

But if we updated our standards such that we no longer accept those things, they would no longer be passable, and something else would be "just barely passable".

My point - inasmuch as there was a serious one - wasn't that we shouldn't raise our standards but that the framing isn't particularly helpful in determining whether we should (while rhetorically sounding like it is).

I have learned over the years that there are different types of devs. Some are ok with cranking out features without regard for overall architecture and can handle the chaos of constant quick fixes over previous quick fixes. There are others (like me) who like well designed systems and get stressed when they are asked to just crank out features without regard for the overall system.

Personally I believe that my approach achieves higher velocity over time because the guys who just do quick bandaid fixes get bogged down over time with technical debt. But not everybody agrees.

I definitely think you need to know where you are on that spectrum and find an org that fits your style. Otherwise you are in for constant pain and unhappiness.

People love to be the hero that swoops in and saves the day. From the hot mess they created the past year.

Every situation is different, and sometimes it's prudent to write a kludge to fix something now, while other times it's more prudent to take your time developing a long term solution. There's even the middle ground of monkey patch now, long term solution later.

I would argue that a well rounded developer will have the capacity to write kludges when necessary, and long term solutions when necessary. Now, if your boss repeatedly asks you to write the code one way and you are always disagreeing with them, then that would be a good reason to find another job. But if you trust your boss, you'll write the code however they ask, even if it's not your natural preference.

long term, companies that operate like this are better off paying for third party services that handle the more technical details that they aren't interested in managing. these are the target customers for managed infra services like heroku, fly, and such (or more task-specific services like pack digital). imo if you get into heavy technical requirements territory, the leadership has to re-assess their priorities or risk drowning the org in tech debt.

Regulation. Regulation. Regulation.

The software world is coming under more and more of it because our magic incantations affect the real world and peoples lives.

>New housing is crap, new furniture is crap, new software is crap

Old housing was crap, old furniture was crap, and old software was crap, you are letting survivorship bias bite you too much and you're losing focus of the forest for the trees.

> its a financial service, not a software company

I have no experience in the financial industry, but I work in a field which is also highly regulated (medical devices). Failure to pass audits or be otherwise compliant to regulation can very much make the difference between having or not having any business at all.

Paying of decades worth of debt in a few month where clients see no shiny new features was likely more and better service than that founder-CEO type deserved.

I'm also in medical devices and I had the same reaction. "If you're out of Compliance, you're out of business."

It's a classic problem - there are some people who know exactly what they are talking about and you should trust them, and there are some people who just sound like they know what they're talking about and you should absolutely NOT trust them.

See Honey the Bear's "Metagame" hypothesis. https://adriantchaikovsky.com/dogs-of-war-series.html#anchor...