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

Re: How good engineers write bad code at big companies

#111

Post by twothreeone » Sat, Nov 29, 2025, 12:29 AM UTC

asdfman123 wrote: post #92

area51org wrote: post #72

Maybe it's things like 4-year tenure, or shorter tenure, or something else. 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…

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 quality wins out by a large margin.

Re: How good engineers write bad code at big companies

#112

Post by Aeolun » Sat, Nov 29, 2025, 12:29 AM UTC

jeltz wrote: post #45

toast0 wrote: post #29

Earlier quoted context omitted.

I've worked on projects where if you wait for the requirements to be firmed up, you'll never be able to do anything. Depends on what you're trying to build if that means you need to stop and figure out the requirements or if you need to just deal with the shifting sands. Aircraft built for moving requirements don't work so well; but lots of things are fine with moving requirements. It'd sure be nice to know how users…

Of course you should not wait around. I think rather the opposite that the engineers should be more involved in working on the requirements. The issue is more rushing and being expected to magically just conjure something. Changing requirements is a fact you just have to live with in many industries.

Changing requirements is fine. Changing requirements when it was eminently avoidable is very, very bad.

If I asked you 6 months ago if you might ever consider something other than credit card payments, urged you to seriously consider this and you say no, you shouldn’t come to me now and say that bank transfers (bank transfers!) are absolutely indispensible.

Re: How good engineers write bad code at big companies

#113

Post by sfpotter » Sat, Nov 29, 2025, 12:29 AM UTC

alfalfasprout wrote: post #110

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…

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…

I don't disagree that it's an accurate portrayal of reality. And of course, as I made clear in my post, I don't know if they're actually a burnt out nihilist.

My issue with the article is maybe more that the perspective and framing seem to want to lock out idealism from the conversation and encourage people to become ruthless, hard-nosed pragmatists in order to survive in this environment. Is that actually good, effective, or desirable? Again, lots of questions.

Re: How good engineers write bad code at big companies

#114

Post by hibikir » Sat, Nov 29, 2025, 12:29 AM UTC

asdfman123 wrote: post #92

area51org wrote: post #72

Maybe it's things like 4-year tenure, or shorter tenure, or something else. 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…

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…

It's interesting that you talk that there's a lot of good management, followed by a list of things I'd call bad management: Forget about good vs bad code, of course that's unimportant. But insufficient maintenance that causes lower velocity on the next set of changes matters. Good engineering will tell you when the issue isn't just about code that is ugly, but code that slows changes down so much you'd be better off improving it.

If you set incentives that say that being sloppy and leaving landmines for the next group of people is the way to get promoted, guess what? the management is bad. Often because they are also looking at their own self interest, and expect to leave the consequences to whoever comes after them. This isn't new to big tech: You'll find this all described in books about corporate dysfunction written in the 90s.

It's all traditional principal agent problems, which just get worse and worse as you add layers of management, as the principal has agents upon agents underneath, all using the misaligned incentives. One either wants t avoid getting fired while doing the minimum, or sacrifice the health of what is around them for a good enough promotion packet/review. And since there's no reasonable way for individual objectives to align well with long term objectives, people leave landmines. When there's enough landmines everywhere, you are always better off in greenfield development. And at that point, doing any maintenance, or being stuck in a project that isn't getting fed a bunch of capital to grow it is career suicide. All about bad incentives, set by bad management.

Re: How good engineers write bad code at big companies

#115

Post by BurningFrog » Sat, Nov 29, 2025, 12:29 AM UTC

asdfman123 wrote: post #92

area51org wrote: post #72

Maybe it's things like 4-year tenure, or shorter tenure, or something else. 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…

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…

I'd say it somewhat differently:

Management doesn't know how good the code is. So they can only look at results.

Like you say, this easily ends up rewarding people writing quick and dirty solutions.

This problem is easy to describe and hard to solve. Yet some teams do it much better than others. One solution is that management also writes code.

Re: How good engineers write bad code at big companies

#116

Post by alfalfasprout » Sat, Nov 29, 2025, 12:30 AM UTC

asdfman123 wrote: post #92

area51org wrote: post #72

Maybe it's things like 4-year tenure, or shorter tenure, or something else. 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…

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 problem I observe is a fairly universal one: management doesn't care about good code, it cares about results.

The thing is, good code is a form of a good result. You need to solve the underlying problems (which manifest as impact) but if you used code to get there, that code if well designed is extensible, reusable, then you pay low maintenance on it and that same code can be used to solve other problems (ideally).

It's a difficult judgement call to make though. If your org doesn't have the right technical leadership and the performance management structure doesn't reward it then you get what you see.

It's a lesson that's always learned far too late when it becomes slow and costly to deliver something new because you've amassed so much tech debt so it's often cheaper to start from scratch (which is saying something).

I see this all fwiw in big tech myself and with my peers at peer companies.

Re: How good engineers write bad code at big companies

#117

Post by Aeolun » Sat, Nov 29, 2025, 12:31 AM UTC

jeltz wrote: post #25

veverkap wrote: post #22

Earlier quoted context omitted.

> If the foundation is built on sand then that needs to be fixed. Except this is the system working as designed. Leadership 1000% wants to do things as fast and as cheap as possible.

It works as designed if your goal is to get your next promo package. It does not work as designed if the goal is to actually make the company more profitable. This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.

> This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.

Being delivered faster or cheaper isn’t the goal. The goal is to look good while doing it. Telling your bosses ‘Yes sir!’ Is apparently a lot more palatable than saying ‘No can do’.

Re: How good engineers write bad code at big companies

#118

Post by innocentoldguy » Sat, Nov 29, 2025, 12:31 AM UTC

toast0 wrote: post #33

innocentoldguy wrote: post #18

I worked for a company writing Elixir code several years ago. Prior to my arrival, the ignorant architect had deployed Elixir in a way that broke the BEAM (which he viewed as "old and deprecated"). Furthermore, one of the "staff" engineers—instead of using private functions as they're intended—created a pattern of SomePublicModule and SomePublicModule.Private , where he placed all the "private" functions in the SomeP…

> had deployed Elixir in a way that broke the BEAM (which he viewed as "old and deprecated") I'd love to hear more about this! > instead of using private functions as they're intended—created a pattern of SomePublicModule and SomePublicModule.Private, where he placed all the "private" functions in the SomePublicModule.Private module as public functions so that he could "test them." Yeah, this is weird; you can just p…

> I'd love to hear more about this!

He deployed our applications using Kubernetes and refused to implement libcluster. There was something else, too, but I can't recall what it was. It was seven years ago.

> Yeah, this is weird...

I kept telling this developer that you're supposed to test your private functions through your public interfaces, not expose your private functions and hope nobody uses them (which they did), but that fell on deaf ears. He was also a fan of defdeligate and used it EVERYWHERE. Working with that codebase was so annoying.

Re: How good engineers write bad code at big companies

#119

Post by nfRfqX5n » Sat, Nov 29, 2025, 12:32 AM UTC

01100011 wrote: post #86

IDK, my team at a FANG has an average tenure of around 7 years and the ones less than that are new hires. I keep getting refresher grants every year. I'm sure this article rings true for some people but not me.

The job hopping thing was definitely a trend, but I think it died with ZIRP. kinda weird to reference it now, but I guess it does have relevance to the state of some of these older services. The original teams are long gone

Re: How good engineers write bad code at big companies

#120

Post by alfalfasprout » Sat, Nov 29, 2025, 12:32 AM UTC

mikert89 wrote: post #37

what I see alot is that the syntax and overall code architecture is text book, but its the completely wrong approach that creates extremely complicated tech debt. All the code reviews will be on the syntax, and none on the big picture of the business problem, or whether the implementation is overcomplicated. in the short run (1-2 years) there is no repercussion for this, but eventually making changes will be extremel…

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.