My instinct after reading this article is to pull back a bit and ask some larger questions. Why is it necessary for big tech companies to act this way? Why does bad code bother engineers so much? Are they actually misguided for feeling like bad code is a catastrophe, or is it really the fault of the broader economic sphere we all inhabit? Is it actually maturity to reconcile ourselves to drift powerlessly as faceless and titanic forces sculpt our reality? So many possible questions.

But I think it's a matter of motivation, Bob.

> The thing is, Bob, it's not that I'm lazy, it's that I just don't care. It's a problem of motivation, all right? Now if I work my ass off and Initech ships a few extra units, I don't see another dime, so where's the motivation? ... my only real motivation is not to be hassled. That, and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.

And also to "keep the balance of power tilted away from engineers and towards tech company leadership." The author touched on that and forgot about it. You don't want key projects depending on a group of engineers that might get hit by a bus or unionize or demonstrate against Israel or something. Network effects and moats and the occasional lobbying/collusion mean the quality of your product is less important.

in the short run (1-2 years) there is no repercussion for this, but eventually making changes will be extremely risky and complicated. The individuals that built the software will lord over everyone else with their arcane knowledge of this big pile of junk

In the end it doesn't matter how normalized and pretty you design the database, someone will eventually show up and write a pipeline that dumps every row of it into JSON once an hour and ships it to some far away corner of the company. Someone will write a shitty script to deal with the fact that those rows don't represent a consistent point-in-time snapshot of your database. In the end it doesn't matter anyway, it'll all be rewritten or coerced through some migration into some ugly system in a few months anyway that it doesn't conform to and could never match.

The thing that matters is the process. When you decide you want to do it, do you have the process to mend the ether to do what you need it to do in two months? Do you have the processes in place to catch it when it's so catastrophic it's blowing up your balance sheet?

I think the issue is more that engineers face unreasonable pressure to deliver short term value and that there is no respect for the craft/engineering from many managers or even engineers.

It's not that the goal is to write low quality code, it's that big businesses understand the sales cycle and how to maximize profits. If they over spend on employees, that cuts into their profits or causes the product to be too expensive. And if they spend the time to write quality code rather than developing features, they lose sales. Customers don't buy quality, they buy features at a price, and quality issues (like bugs) get thrown over the wall to downstream support staff.

As much as I dislike this, knowing how unstable it makes the overall software ecosystem, companies aren't wrong for making these decisions. The companies that choose differently don't become big businesses, they either stay small, get acquired, or go out of business.

One of my first strange and unpleasant realizations in transitioning from studying computer science to "working in the real world" came in a 1:1 meeting with my manager at my first job out of school. I was complaining about code quality both in the context of some of our existing codebases and some new code one of my peers (also a junior developer) had recently written. When the light bulb finally lit up in my naive little head, the question I asked my manager with a sense of horror and outrage was "... so you're saying they wrote bad code on purpose?". The painful thought was that I, too, would (or had already) found myself tasked with pushing code that I knew sucked, for reasons entirely unrelated to architecture or design or other purely "technical" constraints.

I used to fantasize about moving into a different software niche, maybe in safety critical systems, where correctness is more highly valued. But recently I'm coming to realize that the thing I crave (and miss from my school days) is the joy of the craft— something involving elegance and taste in a way that even the strictest standards of correctness doesn't necessitate.

I think for the most part, truly excellent code isn't something many businesses perceive themselves as needing (even if many practical benefits can flow from its virtues). And, probably, for many businesses, such indifference is right. So excellent code, where it exists, is probably more often "gotten away with", half-snuck in by stubborn engineers who are productive enough to burn time injecting some extra consideration and effort into their code, than it is commissioned by a business which understands that it wants good code.

There is also one, very important aspect, that is - (un)suprisingly - rarely mentioned in comments: a lack of dependence between sloppy work and personal comfort of particular person, responsible for problematic changes.

What I mean? A badly installed or configured system would be a problem in next three, maybe five years: to time of major OS upgrade, HW replacement or refresh, framework deprecation and so, and so... In current, corporate culture, there is almost impossible to being bite by own laziness - almost no one is working in particular company or for particular project so long. Especially, when installation is conducted by external party in model "grab the money and run!"

So, very basic motivation for good work, that comes from awareness, that today technological debt would lead to personal, painful experience in future, doesn't exists at all in modern, corporate environment. The things are even worse - there are multiple relations about negative career consequences resulting from concern for the quality of work: "because we want that product fast a we don't like troublemakers and defensive thinkers".

In consequence, one cannot throw a rock without hitting a dozens of such a cases, like that one: https://discourse.ubuntu.com/t/release-26-04-lts-without-the...

I consulted for a large manufacturing firm building an application to track the logical design of a very complex product.

They modeled the parts as objects. No problem.

I was stunned to see the following pattern throughout the code base:

  Class of the object

  Instance #1 of the class

  Instances 2,,n of the class

I tracked down the Mechanical Engineer (PhD) who designed the logical parts model. He desk was, in fact, 100 feet away from mine.

I asked him what he intended, regarding the model. He responded "Blueprint, casting mold, and manufactured parts." - which I understood immediately, having studied engineering myself.

After telling him about the misunderstanding of his model by the software team, I asked him what he was going to do about it. He responded "Nothing."

I went back to the software team to explain the misunderstanding and the solution (i.e. blueprint => metaclass, casting mold => class, and manufactured parts => instances). The uniform response was "It is too late to change it now."

The result is a broken model that was wrong for more than a decade and may still be deployed. The cost of the associated technical debt is a function of 50+ team members having to delineate instance #1 from instances 2,,n for over a decade.

N.B. Most of the software team has a BS (or higher) in computer science.

P.S. Years later, I won't go anywhere near the manufactured product.

But I rarely find this to be the case. The decision on whether or not to invest in static analysis tooling is usually made by people managers, not technical managers, and those people managers are loathe to pay short-term costs for non-functional gains when functional priorities have deadlines.

It's really as simple as, deadlines to ship trump all other considerations, including expertise of any kind other than how to ship when working in unmaintained codebases.

A $20 IKEA chair is not "bad furniture". It's just optimized for different constraints than a Herman Miller. Most consumers are totally happy with the $20 IKEA chair.

An underrated part of engineering skill is knowing what corners to cut. I think large tech companies have structures that impose this on engineers who view this as dereliction of duty.

I hear "thats something we can fix/improve/iterate on" when I'm criticizing code at ny company.

My retort is "why aren't we getting it right the first time?"

A big company is like a collection of small companies. Code quality varies depending on where you are in it.

Similarly, nothing leads me to believe small companies are any better. Some are excellent. Some are nightmare spaghetti.

Experience CAN remove pitfalls, though developers even disagree about those sometimes.

Organization, chosen abstractions, naming etc are basically personal thinking and have differed on every team I've ever been on.

When it's been good is when it's been consistent and that's taken a strong personality the team trusted to have authority.

But even then, given time and number of people, bit rot and a slow downwards spiral feels inevitable. Which is why in those industries they will often do a rewrite every 5-10 years, especially in front-end. Often a redesign / rebranding (also every 10 odd years) will be used as an excuse to rebuild software entirely.

At the second, it wasn't hostility but more indifference -- yes, in theory they'd like higher quality code, but none of the systems to make this possible were set up. My team was all brand new to the company, except for two folks who'd been at the company for several years but in a completely different domain , with a manger from yet another domain. The "relative beginner" aspect he calls out was in full effect.

I have not worked for a FAANG, so maybe things are different there, but I don't suspect so. People are people no matter where you put them.

Increasing compensation is not the solution. It can be a factor in a larger solution, but just increasing compensation increases employee entitlement which makes this problem worse, not better.

The best solution I have seen is risk/reward. Put people in charge of their assigned effort with real adult danger of liabilities. Likewise, award them for their successes. This is called ownership, and it works because it modifies people's behavior. The rewards and liabilities do not have to be tied to compensation. Actually, associating these rewards/liabilities to social credibility within the team/organization appears more effective because it reinforces the targeted behaviors.

I have seen this missing in all of my software career until my current employment. Conversely people in the military are pushed into this liability/reward scenario from the very beginning and its very effective. It has always been striking to see the difference in my dual career progression.

I noticed an issue with a new feature i couldn't fix in a satisfactory manner monday. I talked a lot, with the lead and the other senior early. First i started doing a shitty fix. Then i asked for a carefull review from the other senior, we discussed the issue and managed to find the origin of all the bad code. Then i asked for more time (well, i "told" more than asked tbh) and did a full refactor, correct this time (hopefully) (the deployment + migration script will run next monday).

Writing bad code happen to everyone, at every company, especially when you don't have a lot of experience and domain knowledge. The issues appear when no one catch this bad code, or when people don't have the time or the latitude to fix it before it corrupt all the surrounding code.

In my experience, while this line is often repeated, in practice it’s rarely really a “deliberate” tradeoff. Rather it’s mostly accidental.

Also, the process, security, approvals and compliance could dominate so much that less than 20 lines of code changes per week could become the norm and acceptable.

1) the focus is on shipping a new feature, often building on half-baked infrastructure and with a tight deadline. Corners have to be cut. 2) the usual “shipping features gets you promoted, maintenance work doesn’t”

“Bad” code is probably “good enough for now” code that was written some time ago on a bet that doing it better would never be needed as it wouldn’t need to change.

Also, “good” code is costly especially if taking longer to build the thing causes the company to miss its market.

I have met maybe 5 good engineers in my whole career. The size of the company did not matter. The reason is, the only thing that exists in our world today that can make you a good tech engineer, is yourself.

When you hear the word "engineer", you might imagine a professional who has done studies, passed exams, has certificates, maybe even apprenticed. They know a specific body of knowledge (which is maintained by some organization), they're held liable for their work. They are masters of their domain and they don't step outside of it.

But not if they're in tech! Then an 'engineer' can be a high school graduate or a PhD. Both can make the same amount of money, and have the same lack of real-world experience and job skills. They will both regularly apply technology they've never been trained on, never learning more than the least possible information to get a proof of concept working (and then that immediately becomes a production service). There's often no record of the decisions they made, no formal design process, no architectural review, no standards listed, no testing required, no risk analysis performed, no security/safety/reliability checklist performed. And they often are dealing directly with PII, with absolutely no thought to how to manage it. And they often have far more access than they should have, leak critical credentials everywhere, don't manage the software supply chain properly, don't even pin versions or even test rollbacks, etc. I have seen all of this at every single company I've worked for.

In any other 'engineering' profession, this would be illegal. Hell, it's sometimes illegal just to change a breaker in a subpanel in your home without pulling a permit, because doing it wrong has consequences. Think of all the times your personal financial records, health records, sensitive data, social security numbers, etc, have been leaked, just in the last year or two. 9 times out of 10 those happened because nobody cared enough to prevent it. But these things shouldn't be optional. There should be some kind of mandatory thing in place to force people to ensure this doesn't happen. And some kind of mandatory minimum requirements about what people know, what they're allowed to work with, and how. None of that applies in tech, yet we still call it engineering.

https://suno.com/song/d6d77518-16ca-455f-ade1-0e8d08fc4b0b

In my experience, big companies have the biggest incentive to write good code. They have the highest conviction in their bets, and they know with high confidence they will be around in 10 years. One large tech company I worked at had a rule of thumb that all code would need to be maintained for ~7 years - at which point, as the author points out, the entire team may have been replaced. This is precisely when the time it takes to write good code is a worthy investment

The code may look "bad" in a vacuum but if it yielded a successful outcome then the engineer was able to achieve his/her goal for the business.

The stories shared in this article are exactly what you'd expect from big tech. These are some of the most successful firms in the history of capitalism. As an engineer you are just grist in the mill. If you want to reliably produce "good" code then IMO become an artist. And no ... working at a research facility or non-profit wont save you.

I think this is crucial. Even old hands working on their area of expertise can be compromised by deadlines.

What I cannot stand and can barely tolerate is kruft and sloppiness. massive sections of commented out functions, leaving the poor guy to come along 2 years later wondering if it was important or why it was left there. Unused functions. bad, inconsistent, or nonexistent naming conventions. Terrible or annoying file/project structure.

None of this stuff has to be. Not doing this stuff requires a bare minimum of effort and time and doesn’t require any familiarity with a codebase. It’s a lack of professional pride, and that deeply annoys me when I inevitably have to clean it up because it’s an unreadable mess.

In my experience at a FAANG working on one of the core services for both internal and external customers, essentially two kind of people crank out great code:

1. "rock stars": they joined the company at 25 and they're still there at 35+. they're allowed pretty much everything (eg: no RTO, work from home country) and they know many codebases across the services very deep. they aren't really motivated to go look elsewhere, their grass is already one of the greenest.

2. people with kids. the company pays enough. they aren't really interested in switching job, rather they want to provide for their family. they're good, and maybe every now and then will push through for a promo in order to face new challenges in life (another child coming or some kind of new financial burden).

i'm not saying either one is inherently good or bad.

but yeah. in such large companies you end up working in on a very large codebase that interacts with other very large codebases. all the codebases are proprietary and you're lucky if you can use some libraries that come from the outside world (that have not been heavily lobo^H^H^H^H customized - the libraries i mean).

you do what you can, you do your best, but you're essentially a relative beginner.

I tried almost in vain to fix these two ridiculous decisions, but the company refused to let code fixes through the review process if they touched "well-established, stable code that has been thoroughly tested." After being there for a couple of years, the only thing I was able to fight through and fix was the BEAM issue, which ultimately cost me my job.

My point in all this is that, at least sometimes, it isn't good engineers writing silly code, but rather a combination of incompetent/ignorant engineers making stupid decisions, and company policies that prevent these terrible decisions from ever being fixed, so good engineers have no choice but to write bad code to compensate for the other bad code that was already cemented in place.

2. Eng teams that have mostly old-timers tend to get stale and slow in changes. This is bad for products that need rapid evolution or new ideas to break status quo. New engineers have way more incentives to make changes to prove themselves and collect credits, while old-timers tend to play safe and stay on the side of stability.

3. Bad coders, not new coders, write bad code.