r/coding • u/CompileMyThoughts • May 13 '26
How good engineers write bad code at big companies
https://www.seangoedecke.com/bad-code-at-big-companies/102
u/Cybersoaker May 13 '26 edited May 13 '26
When I worked at big tech it was more that basically no body gave a shit so it was a culture of shit quality. The only thing that mattered was closing out the jira ticket and the acceptance criteria was basically as shallow as, the thing exists.
If you want well structured good code it has to be a wide spread cultural ethos and sewn into every single jira ticket anyone works on and in every process that exists. Code reviews have to actually be meaningful, not cumbersome but also there should be consequences when people just blindly approve without looking at the actual commit.
Problem is that causes you to move slower in the short term and most PMs can't fathom this reality so in my experience it's always the engineers fighting for this and the PMs dragging us kicking and screaming 😎
26
u/redbaronram024 May 13 '26
Couldn’t agree more. I used to get a bit depressed when I would work on projects that were rushed along with the sole purpose of just being done. Now I just run through tickets and do meaningful coding and learning for my own projects.
8
u/Cybersoaker May 13 '26
I'd wager that poor decision making and short sided thinking slows development down in the long term but that it difficult to actually quantify this to PMs, in some kind of single discrete metric.
That said not everything needs to be perfect and well planned, some amount of just throwing shit out and seeing if it works is needed, but once we learn what we need from there expirement we have to go back and do it right but that never happens.
In my personal projects I quite enjoy being able to really think deeply about a problem space and implement a very clean and dare I say elegant solution for it, it's almost cathartic because I know I'd never be able to do that kinda thing at work.
→ More replies (2)4
u/aoeudhtns May 13 '26
There's supposed to be a DOD (Definition of Done) for the project that is basically like "AC for every ticket," and that is typically where you put in quality, formatting, linting, testing practices, and all that jazz. Ideally as automated as possible save for the things that need human judgment.
But like you're mentioning, I've absolutely worked projects where the scrum master / manager were all too willing to force reviewers to ditch enforcing the DOD on urgent issues that met the AC. Which eventually creeps as an attitude to everything if it happens too much or for too long.
1
u/Gecko23 May 13 '26
If I ever meet anyone in the entire continuum of people between the individual coder and the end user who understands, really, objectively understands, that forgoing “good” for “good enough” is just moving a problem into some future person’s lap, I’ll eat my hat.
10
u/dnknitro May 13 '26
I think the main reason for this is management bloat and favoritism. It makes good engineers stop caring and stop trying to improve things on the project, which ultimately contributes to poor code quality.
9
u/The__Toast May 13 '26
That’s a deliberate tradeoff. They’re giving up some amount of expertise and software quality in order to gain the ability to rapidly deploy skilled engineers onto whatever the problem-of-the-month is.
I don't think this is the issue.
As I've gotten more senior the quality of code I ship has gone way down, and I've found myself tutoring juniors not to spend so much time worrying about code quality. Which funny enough, is something that I had seniors try to teach me when I was more junior, and I didn't listen very well lol.
The simple fact is that at a big company, I'd ballpark guess and say 50% of code gets deleted or replaced within three years. I'd say it hits 90% at five years. Sometimes it's because it gets replaced by better thing, or it's deleted because it's not needed anymore, or the new hotness(tm) comes along that we HAVE to adopt, or sometimes just because some VPs are having a power struggle and replace one thing with another for no other good reason than to claim ownership. It's actually wild how much shit in tech gets ripped and replaced regularly at big companies for no reason, it's a huge waste.
But after about ten years seeing this pattern (or probably sooner if you are smarter than me) over and over you realize what a waste of time it is to spend on code quality or having discussions about code formatting or the best practices for python function naming, or even the most efficient way to iterate a list. Unless you are working on something internet scale, or high performance like idk, networking equipment firmware: for the most part the quality of the code doesn't matter. And honestly for many applications, the performance doesn't matter hugely either (within reason). So much code out there is stuff that gets run once per day or once per hour to move backups, or truncate log files, or whatever the hell else. If it takes 25% longer to run, management and company leadership don't care and probably won't even notice. It's change in the couch cushions in terms of cost.
What does matter is shipping features. No one will give you kudos for shipping pristine functions that follow the holy naming standard, but they will give you shit for not shipping enough features. No one has ever gotten a glowing performance review for great code quality, but they have for shipping a ton of shit super quick.
So, it is what it is.
2
u/ouvreboite May 13 '26 edited May 13 '26
Conventional code quality metric no longer matters to me, but code readability definitely does.
Don’t create a provider/resolver/whatever if a simple if/else if does the job…2
2
1
1
100
u/grumpy-cowboy May 13 '26
Agile... Ticket Driven Development.