100% this. Stuff like database schemas gets comitted in the first sprint and never gets refactored, which completely locks you in to long term design decisions, then every subsequent PR will get held up for days in arguments around meaningless "code quality" arguments which ultimately affect nothing

ive never actually seen someone get fired for making some deep architectural software mistake. its alway for moving too slow, or "low code quality". i think people that were promoted for building systems that turned out bad, should be demoted

Because businesses, as a rule, value moving fast. Being first to market makes money and generally results in winning.

Oftentimes the circumstances are "we don't know the requirements", not because of shitty management, but because the problem is inherently hard to define.

The business conditions that do heavily penalize bad architectural decisions, like physical structural engineering, can suck to work in compared to SWE.

It takes a decade or more before you're trustworthy enough to architect a building and there's a million layers of approvals. Then it takes years before groundbreaking, and years more as the building increases in size.

Your whole life might be dominated by a single large project like Hudson Yards, which has been floating around as an idea since 1956. The most recent proposal started in 2006, broke ground in 2012, and another 6+ years to finish. Then when companies were about to move their offices there, COVID-19 happened and the leases fell through.

I'd rather the system that gives average SWEs regular opportunities to lead large projects from scratch and make mistakes.

I think you are underestimating how many product problems at big companies are actually bad technical debt. They cant release new features or evolve the offering because the systems are too complicated to change. 1 year of quick development could stunt the whole org for the next five years.

The good news if you take 2 years to ship the system "properly" then you won't have to re-factor it because the company went out of business or that product was too late to market.

There is a phrase "million dollar problems". You do stuff at your startup that will take a million dollars to fix because it doesn't scale.

The point is that if your startup doesn't get to that scale then it doesn't matter. If you startup does reach that scale then you have plenty of money/people to spend a million dollars fixing it.

Replies like yours gloss over nuance. I don't mind prioritizing time to market as a programmer; I am not clueless, I understand that imperfect product that pours money into my employer's coffers is infinitely better than it sinking and we all get fired out of necessity.

My problem comes from the fact that the leadership _never_ compromises and never allows us to avoid at least some crises that are extremely easy to foresee (and have happened like clockwork in 95% of the cases where I or other colleagues have predicted them).

Again, sure, let's go to market and start making sales. I completely agree. But scolding a dev for fixing a DB schema anomaly that slows down ~40% of _all_ feature requests and that it took him the grand day or two to do so, is not just myopic. It's moronic.

---

Even shorter / TL;DR version: If the balance of power was 80% leadership and 20% engineers, I'd still be completely OK with that. But wherever I go the "balance" of power is more like 99% leadership and 1% engineers (and that's only when stuff really has hit the fan; they'd take away that last one percent as well if they could).

That is the problem. There's no balance. No compromise. Just people barking orders.

It is not only being first. It also is about responding to customers - not fun part is your customers don’t care about your app. They have to use dozens of different apps on daily basis, so when you have customer interaction you better be able to do stuff right there because they might be available in 3 months or next year to talk about your app.

I don’t like all the fantasy about “just talk to the customers” - nah it is not just, it is super hard to get their time.

Yep. "Oh you don't have that feature? I'm moving on".

You can’t often demote them because usually the people responsible for bad initial design decisions left the company years ago with a desperate need to go and start a new mess somewhere else.

All systems eventually turn bad. The idea that you can gold plate something so it won't is naive. It isn't about getting it right from the start, its about having the will to change it once your system or uses evolve into something that turns it wrong.

A good system, i. e. one that got it right from the start, is one that is cost-effective to change. (“Will” has little to do with it.)

Change in which ways? A system designed to be cost effective to change in any way isn't going to be cost effective to change in a small set of ways.

Answering that question well is what makes the system good!

> i think people that were promoted for building systems that turned out bad, should be demoted

Nope, in the same vein of "lording" over others, they become the expert of knowledge of bullshit. The environments that allow such behavior have already engrained reward of such behavior.

> 100% this. Stuff like database schemas gets comitted in the first sprint and never gets refactored, which completely locks you in to long term design decisions, then every subsequent PR will get held up for days in arguments around meaningless "code quality" arguments which ultimately affect nothing

I moved teams a few years ago, and the very first thing I did was push hard to re-structure the schema they (sorry, pals) slapped together without much thought. It took some fair amount of arguing, and maybe a PR that I had reviewed by only a single person and pushed through because it's easier to ask for forgiveness, but we got there in the end.

Luckily, we were able to do this before the code started hitting production traffic; it would have been significantly more difficult to fix once we started getting real data into the system.

100% this. The architecture is what slows things down (or speeds them up), the code quality, variable naming, all that bs just does nothing.

Totally agree, I've found that as well working in big tech

People focus way to much on the superficial stuff like code cleanliness, formatting, organization, local structure of the code

Because that stuff is easy to talk about, kind of like bikeshedding.

Plus a lot of times code reviewers just want to comment something to show they aren't just rubber stamping it.

Whereas it takes a lot more brain power to think about logic, correctness, and "does the change actually make sense in the big picture"

Part of it too is that as a reviewer a lot of times you just don't have enough context to know if the change makes sense

In the context of reviews my experience has only been code review quality brought up as a negative thing for folks and the bar to not be a negative is low enough that folks slowly take less and less time to review code well because it isn't valued come review time.

>does the change actually make sense in the big picture"

Ideally by the time your at code review this is not a question. It sucks for everyone for it to come up.

I think people also avoid rejecting for this reason becasue of that

Its hard to have good enough requirements gathering and documentation and product design practices to let an engineer really wrap their head around a problem well enough to come up with and then consistently follow a thoughtful, long-term-maintainable design for a system during implementation.

And its even harder to make sure everyone who reviews or tests that code has a similar level of understanding about the problem the system is trying to solve to review code or test for fitness for purpose, and challenge/validate the design choices made.

And its perhaps hardest of all to have an org-wide planning or roadmap process that can be tolerant of that well-informed peer reviewer or tester actually pushing back in a meaningful way and "delaying" work.

Thats not to say that this level of shared understanding in a team isn't possible or isn't worth pursuing: but it IS a hard thing to do and a relatively small number of engineering organizations pull it off consistently. Some view it as an unacceptable level of overhead and don't even try. But most, in my experience, hope that enough of the right things happen on enough of the right projects to keep the whole mess afloat.

Eh, its either that, or the wrong people are getting promoted. Technical skills != business process modelling

I've seen too much of the same. It strikes me that the pattern you describe also matches a lot of AI generated code I see, especially when it's big chunks of generated code. Are we automating this problem and going all-in on the long term costs?

100% yes. The most dangerous developers you’ll ever work with are the tactical tornadoes who crap out extraordinary amounts of code that mostly implements the exact feature that product asked them for with zero thought given to any other concerns.

AI makes these types of developers much more dangerous because they will accept anything the AI generates tha looks like it works, and they’re experienced at pushing nonsense through code reviews.

AI also provides more of a “productivity” boost to these types of developers because unlike everyone else they actually spend the majority of their time typing code.

> Are we automating this problem and going all-in on the long term costs?

I feel that is a very likely scenario.

This was the case before AI tho, people were copying coding patterns from companies randomly even without understanding. I mean there was an interview with some DoorDash architect that literally stated that whatever their architecture was just fad chasing at that moment.

Every company I've ever worked at (from ISPs to health insurance to finance) every organize was just copying the fad of something else.

At the time I felt like it was because that was "the best way" but it was more likely do to engineers not having the freedom to actually explore good solutions. The made up constraints imposed by organizations against their workers are rarely for the benefit of the company.

It's not a surprise to see this being the case, most companies on the planet are ran like centrally planned dictatorships with the results being obvious in retrospect.

Yes, it was the case. AI just magnified the severity by an order of magnitude or two.

Well obviously this is the same code the AIs were trained on.

Catching architecture problems in code review is usually a red flag for process problems. Anything substantial should have been reviewed for architecture prior to a code review, especially if it spans multiple commits. Code review should feel rote and focus on rubrics around style and best practices in an ideal case. Of course you will still find architectural issues during code reviews in many cases but that shouldn't be often as it's not reliable to expect the reviewer to have the necessary context to catch them.

It's getting much worse with AI now too. People just blindly trust the AI's decisions which even as of Opus 4.5 is generally misguided for nontrivial problems and best-case doesn't even consider the bigger picture given context-window limitations.

So the mountain of syntactically correct functional slop is growing faster than ever before.