How good engineers write bad code at big companies • Hacker News Board

Re: How good engineers write bad code at big companies

#211

Post by matwood » Sat, Nov 29, 2025, 8:06 AM UTC

sfpotter wrote: post #93

I've read a few of this guys posts now and have consistently been rubbed the wrong way by them. I think I know why now. It's not that he's wrong . His analysis is reasonable and straightforward. I think it's that the basis for his analysis is ultimately a form of nihilism, coming from someone who (maybe?) used to be an idealist but was burnt by a bad experience and must now explain why believing in anything is misgui…

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.

Re: How good engineers write bad code at big companies

#212

Post by saghm » Sat, Nov 29, 2025, 8:10 AM UTC

twothreeone wrote: post #111

asdfman123 wrote: post #92

Earlier quoted context omitted.

No, big tech engineers are highly motivated. There's lots of money, good management, and plenty of incentive. (I'm a Google engineer myself). The problem I observe is a fairly universal one: management doesn't care about good code, it cares about results. It's generally hard for anyone without specific experience with a codebase to tell what you're doing with it. Management can't evaluate the value of maintenance wor…

The thing is shipping sloppy code is orders of magnitudes easier, because that's the default result. Any sufficiently determined hack-job can do it. On the other hand, steering a team of 5-10 engineers to deliver quality on (or before!) a deadline requires excessive amounts of coordination and skill. Now, is this trade-off "worth" the effort? I guess that's a matter of opinion, though I would argue in the long term q…

Sometimes teams will do the sloppy thing because it's the quickest path to resolution of an issue deemed to be critical, which can make sense in the moment, but if you do this too many times without spending the effort to improve the solution after the immediate pressure is gone, issues like this will continue to get more common. I like to use an analogy of trying to put out a fire on the other side of a building by filling a cup in the sink and then running across to toss the water onto the fire; in the short term, it might be the best fix, but if you keep finding yourself having to do this, you're probably better off installing a fire hose even if it requires a lot more effort up front.

Re: How good engineers write bad code at big companies

#213

Post by black_13 » Sat, Nov 29, 2025, 8:22 AM UTC

jagged-chisel wrote: post #139

sfpotter wrote: post #93

I've read a few of this guys posts now and have consistently been rubbed the wrong way by them. I think I know why now. It's not that he's wrong . His analysis is reasonable and straightforward. I think it's that the basis for his analysis is ultimately a form of nihilism, coming from someone who (maybe?) used to be an idealist but was burnt by a bad experience and must now explain why believing in anything is misgui…

> 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 gar…

[dead]

Re: How good engineers write bad code at big companies

#214

Post by wrxd » Sat, Nov 29, 2025, 8:28 AM UTC

I would add a couple reasons why good engineers end up writing bad code.

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”

Re: How good engineers write bad code at big companies

#215

Post by Ygg2 » Sat, Nov 29, 2025, 8:28 AM UTC

Aeolun wrote: post #108

Ygg2 wrote: post #96

Earlier quoted context omitted.

> I'd go further and say you're not a senior if your code isn't good you shouldn't be a senior. You say that until you are tasked with doing impossible - three lines, all perpendicular, five green, two anti-green, seven in ten or more dimensions, any color; while customer only uses purple lines. Last guy that worked on it committed seppuku. Rest of team is in mental ward. Your only team member is guy that programmed…

There is a magic word that adults sometimes use. It is a word you have to learn to master if you want to be any good at your job. No.

Saying no is a privilege.

It's easy to say if you have other options.

It's extremely hard to say if others depend on you saying yes.

Re: How good engineers write bad code at big companies

#216

Post by icsa » Sat, Nov 29, 2025, 8:28 AM UTC

Anecdote:

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 politely asked why this pattern existed. The answer was "it's always been that way."

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.

Re: How good engineers write bad code at big companies

#217

Post by alliao » Sat, Nov 29, 2025, 8:31 AM UTC

icsa wrote: post #216

Anecdote: 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 politely asked why this pattern existed. The answer was "it's always been that way." I tracked do…

come on man, give us a clue tell me at least it won't kill anyone

Re: How good engineers write bad code at big companies

#218

Post by alliao » Sat, Nov 29, 2025, 8:34 AM UTC

it's just the mindset of management 101.. you do not ever let your engineer be bored. literally the first thing they teach in 101 is you deliberately overburden them with crazy THEN set impossible deadline so that they build only the very core and you ship it immediately then refine later. sure the method might be different now, but the spirit of such process is the same, you do not ever let your engineer be bored as boredom is waste, and waste is not efficiency. this is to ensure that creative (value-add) portion is left to the management.

Re: How good engineers write bad code at big companies

#219

Post by phito » Sat, Nov 29, 2025, 8:47 AM UTC

chanux wrote: post #205

ajkjk wrote: post #160

Earlier quoted context omitted.

I don't think it's that. It bothers me a lot too, and not because anyone else is judging me or anything. I think it's just that it's depressing... it sucks to be doing bad work, on top of other bad work, and unable to do good work instead. It is incredibly frustrating to care about quality but be surrounded by and constrained to work on crap. Just feels like everything went horribly wrong somewhere and you're powerle…

I know how to fix this but I'm not "allowed to" can eat away at you easily. Then there are things that I know how I might fix but I wouldn't realistically be able to because it's all a lot to take on, there will almost never be enough time and hands to get it done, within the set constraints. This is due to the way how incentives are aligned. Systems that are powering things for, say a decade at least but worked on Q…

>I know how to fix this but I'm not "allowed to" can eat away at you easily.

This really is the worst, and that's why I left my first job. Funnily enough, I just took that job back after a few years but I am now the lead and sole developer on it, I'm having the time of my life doing what I've always wanted to do back then, and seeing the product now flourish.

The bad code didn't really matter, it was the fact that I was not allowed to improve it and forced to build new features on top of crappy code that made me quit in the first place.

Re: How good engineers write bad code at big companies

#220

Post by solatic » Sat, Nov 29, 2025, 8:57 AM UTC

Author's conclusion that legibility is prioritized over quality implies that static analysis tooling, auto-formatters, and similar linting tools would be practical requirements in all BigCo projects. Auto-formatters improve legibility in nearly all cases, and where engineers are trading off quality to meet deadlines, they are almost never hand-formatting the code intentionally. Static analysis catches common issues made by beginners without deep expertise in the codebase's language.

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.