> Why does bad code bother engineers so much?

I’ll take a stab.

Because I’m being held accountable for the bad results of the bad code. Because I’m being held to task to fix the problems caused by the bad code on a schedule that I didn’t agree with. Because management is using someone else’s bad code to deny me a positive annual review.

“You’re a senior engineer - why did fixing this take so long?” Because of the garbage I had to wade through to even find the problem. Because I wasn’t yet working here when this was written and I have to take time to get my head around the insanity.

Yes, these are management problems. I’ve spent years managing managers and attempting to educate them on how bad code causes errors and delays. But for many reasons, it’s a Sysiphean task.

> Why does bad code bother engineers so much?

Others have said some true things but the core is missed. It bothers engineers who care about mastery. It’s the same for architects who see design flaws in buildings that were done by those who don’t care about mastery. Or a filmmaker who watches a movie with lots of flaws. Caring about obtaining mastery means having the capability of seeing the flaws and resolving them.

It could be maturity to resign to powerless forces or it could be the inability to obtain that mastery or the willingness to let go of that mastery. I would think it’s more mature to fight the good fight, but at some point you just get old and tired I imagine. And it’s interesting to posit the author is nihilistic when this “uncontrollable forces” itself is a nihilistic take imho.

I think one of the issues is that engineers define bad code on a different set of dimensions than the business, and even amongst each other. Early in my career I was definitely guilty of this, that if the code didn’t fit my definition of perfect code, it must be bad. I’ve met great programmers (I don’t consider myself in this group) in my career who put even more strict criteria on something to be considered ‘not bad’. Then I worked at small companies, big companies, was an owner at one, and my definition of bad code narrowed. While my criteria are still subjective, if the code meets the business goals and a baseline of quality I consider it fine. Because outside of some absolute genius programmers like Carmack, few of us will look at someone else’s code and not think of any type of improvement.

My feeling when I found this blog was "so I'm NOT the only one!". It's the painful truth about staff+ engineering that I've also experienced, but haven't felt safe to talk about.

You're not wrong that there's something cynical or nihilistic about it. The core thesis is "do what the company wants, even if it's not what they should want". That idea may be unpalatable, but getting ground up in the corporate gears is worse.

I think you are ascribing too much into this. If he does not believe anything then there will be nothing to write about. It looks like he does not believe in _your_ ideals - that does not make it nihilism though.

It's hard to write about the broader context with any expertise in a blog post written from personal experience.

My own thinking is that the big competitive advantage that big tech firms have over small ones is the power to mobilize very large numbers of developers onto a project.

Large projects that don't depend on a small core group of irreplaceable competent individuals are more repeatable for a business. So it makes sense to focus on making the repeatable processes more likely to succeed than simply hope that you happen to have the right team assembled for the job.

Assuming that any of your engineers are above or below average hurts the ability for the business to plan.

Bad code bothers engineers because it is fundamentally wrong to write bad code. It goes against the nature of things.

> Why is it necessary for big tech companies to act this way?

This question gets directly at the cause of the author's nihilism: the necessity is borne from the endless pursuit of positive quarterly growth, the "binding fiduciary duty to shareholders". Which is a lie, there is no such legally binding fiduciary duty. So the aforementioned necessity is also a lie. Companies could operate on a longer time horizon, let engineers write better code, make better products, maybe even consider societal good in their strategic planning, and still turn a healthy profit. But the cost of perhaps taking a few degrees off their YoY trend line is unacceptable to the insatiable greed of their controlling shareholders.

You are being a bit unfair to the author, but I think I know where you are coming from in this argument.

The writing comes across as “well this is the way it is and this is why it is.” That’s fine, but most of us kinda already know why it’s the way it is.

Maybe, tell us something about how to adjust the culture.

Interesting. Coming from big tech, it's actually pretty spot-on of an article. I think most folks at big tech have experienced this stuff too.

> 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.

These are all great questions. I have some thoughts, of course. But I'm not sure it's fair to describe OP as a burnt-out nihilist. The premise of the post is pretty reasonable actually.

Every time I read his article I regret it. I literally mean every time, 100% of it. Judging by the title of the article, I didn't expect his reason to be "engineers working outside their area of expertise". I've seen good engineers figure out problems outside of their expertise plenty of times, so that's not a good reason either.

I feel like this article is the equivalent 16 paragraph stating you're likely to be correct only 10% of the time when you guess a random number from 1 to 10

I can find an experienced doctor, plumber, musician or mechanical engineer that was doing it 50 years ago.

I’m not going to find someone that was doing software 50 years ago. And if I do, their experience is completely unrelatable.

SWE is a lot of relative beginners learning from other relative beginners.

I think the engineer jumping between giant companies for three years or less every time rarely works on particularly key things. Big tech companies do a LOT of stuff, and most of it is crap that isn't moving the needle. This post describes teams that are constantly changing priorities (chasing trends?) and IME that's not true of the really core, central functions at companies. But very true of the "support/enabling" or "what else can we do?!" side functions.

For instance, Github Actions being a meh product is called out in the article - that's a classic "check the box" feature that's good enough for a lot of people (let's not forget that Jenkins was no picnic before it) but is never gonna massively increase GH's bottom line.

Those sorts of projects are easy places for politics to fester since they are easy to ignore for the most influential-and usually strongest-parts of leadership.

On the other hand, if you're on a core, mission-critical team and other people's code is turning into your bad performance review, you need to figure out if the problem is (a) bad/toxic manager or (b) a failure to keep your management chain informed at what the root issues are and how you can improve it.

> 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.

Nihilism is a defense mechanism when everything is moving against your world view.

STEM people of all walks of life join because of the challenge, the loveliness of an elegant solution, and the “art” you create that leaves your mark. Good engineers view their code as a makers mark. This code represents me as my art and I should do my best. Unfortunately (or fortunately) this is beaten out of you by senior engineer and the shell left is a nihilist and misanthrope.

Corporate programming strips you of your creativity, your autonomy, and your drive. It’s simultaneously strict, but too loose where it should matter. It’s spastic in its execution. There is often little rhyme or reason aside from “build fast make money”. No one appreciates your contributions. You show up to meetings where sales and PMs simultaneously wrestle to take the credit you rightfully deserve. You made it 10 years, here’s another low budget pizza party while the sales team gets an all inclusive in Ibiza. You wanted to make cool, elegant, things, and instead you’re just a factory worker that had to do 7 rounds of interview for the privilege of stacking premade widgets together until retirement.

The end result as I and many engineers at and over the one decade mark have realize. Nothing matters, no one respects you, and no one truly cares. You get paid and promoted whether or not your code is elegant, or safe. You get recognized by prostrating yourself in front of leadership. So why should I give a shit if my code works or not. It passes tests and I get to eat.

The industry is pathetic and we should stop calling ourselves “engineers”. Modern corporate programming is analogous to working on a widget assembly line in the limit. Most of us simply find our joy elsewhere and have learned “hearts and minds” as the rule of corporate life.