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

Re: How good engineers write bad code at big companies

#281

Post by zingar » Sat, Nov 29, 2025, 9:38 PM UTC

JackSlateur wrote: post #243

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…

"management doesn't care about good code, it cares about results." And management is probably right: code is a mean, not an end It is us, as software engineers, to make that better code brings better results Some benefits of better code can be: - less infrastructure cost - more speed / efficiency / whatever metrics available from the users - easier to integrate new features - less issues, less time spent in maintenan…

Yup, tolerating inappropriate tech debt for too long leads to bad results. I see this going wrong all the time and I thought it was mostly due to being surrounded by bootcamp grads given nothing but year after year of pressure and no examples of what good code can look like. Surprised to hear the same thing happens in big tech.

Re: How good engineers write bad code at big companies

#282

Post by bcrosby95 » Sat, Nov 29, 2025, 9:42 PM UTC

empthought wrote: post #170

bcrosby95 wrote: post #153

Earlier quoted context omitted.

All systems eventually turn bad. The idea that you can gold plate something so it won't is naive. It isn't about getting it right from the start, its about having the will to change it once your system or uses evolve into something that turns it wrong.

A good system, i. e. one that got it right from the start, is one that is cost-effective to change. (“Will” has little to do with it.)

Change in which ways? A system designed to be cost effective to change in any way isn't going to be cost effective to change in a small set of ways.

Re: How good engineers write bad code at big companies

#283

Post by sigotirandolas » Sat, Nov 29, 2025, 9:46 PM UTC

jeltz wrote: post #266

sigotirandolas wrote: post #225

Earlier quoted context omitted.

When all leadership is asking is "what is the short term business value?", it's pointless to make that case. It's much easier to measure "yet another feature" than "fix the root causes of what makes our product subpar and slows us down". Not only that, but an incompetent engineer's "tech debt grooming" may make things worse. I think that this may eventually become better now that there isn't so much dumb money around…

I think AI will make it worse since it will allow the incompetent engineers to do much more harm.

In the short term, definitely.

In the long term, once the damage from vibecoding is better understood (for customer impact and team morale), there's an incentive to push them out, both from the leadership and the individuals side.

Re: How good engineers write bad code at big companies

#284

Post by sfink » Sat, Nov 29, 2025, 9:57 PM UTC

brendoelfrendo wrote: post #161

sfink wrote: post #149

Earlier quoted context omitted.

Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it. I got into this career because I like mucking about with this kind of work. Programming is sort of like building thought sculptures. Ok, maintaining them too. I spend a lot of my adult life working with these systems, so of course I car…

> Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it. Well, I don't know that we can separate external forces from why people might dislike bad code... being held to a standard that is unachievable because of someone else's mess and someone else's expectations is all too common in life,…

> Well, I don't know that we can separate external forces from why people might dislike bad code...

I'm not denying the validity of the reasons stemming from external forces. I'm just enumerating a bunch of additional reasons why developers might have a problem with bad code.

>> If you try to do something right and take pride in your work, your teammates will be resentful that you're not closing your bugs fast enough.

> Right, but why would they resent that? Probably because management has expectations on the team, and they are concerned that you're sandbagging the metrics. It ends up being a management or cultural problem regardless.

Heh. That's definitely a valid and common reason for resentment, but again I think the resentment can arise from more internal reasons as well. Even the craft coders recognize that you can't polish forever, and if one person spends 90% of their time polishing, then effectively that requires the others to pick up the feature work slack. That person is leaning on the rest of the team. It might be sometimes the right thing to do, but if it's a perennial pattern then even a team with 100% anal-retentive craft coders is going to get annoyed. Possibly because it cuts into their polish time, so they end up shipping worse code than they'd like.

But then, I'm not sure we're even disagreeing. The above could be labeled as "cultural". I think of the internal/external distinction as one where it's internal to the team vs imposed by management.

Re: How good engineers write bad code at big companies

#285

Post by sfink » Sat, Nov 29, 2025, 10:02 PM UTC

StackRanker3000 wrote: post #238

sfink wrote: post #149

Earlier quoted context omitted.

Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it. I got into this career because I like mucking about with this kind of work. Programming is sort of like building thought sculptures. Ok, maintaining them too. I spend a lot of my adult life working with these systems, so of course I car…

> Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it. From the perspective of the organization that pays you to do it, it is? At best there may be another mission that it genuinely cares about, usually there’s only a profit motive (which is also fine). If you want to create software as a…

> From the perspective of the organization that pays you to do it, it is?

I agree. I'm just saying that if you limit yourself to explanations from that perspective, you will miss some of the explanations and be unable to describe real-world phenomena.

> If you want to create software as an end in itself or enjoy the craft without compromise, it usually can’t be in the context of a job or a business

Sure, but that's an extreme position. Maximizing the "ship features that make money" end of the balance doesn't end well in the long term. Maximimizing "all code must be perfect" also doesn't end well. There is very much a place for an appropriate amount of craftsmanship, and businesses do better and even make more money in the long run if that isn't choked out. ("Appropriate" varies widely by situation.)

Re: How good engineers write bad code at big companies

#286

Post by vlovich123 » Sat, Nov 29, 2025, 11:10 PM UTC

bdangubic wrote: post #274

vlovich123 wrote: post #270

Earlier quoted context omitted.

I think you are conflating mastery with some kind of beautiful codebase that is completely obvious to everyone else. Einstein had mastery over physics and yet his ideas required a lot of studying to understand and explore. Engineering is the intersection of science and economics. You build the thing as best you can with the knowledge you have and you often discover things you didn’t even know once you start building.…

I agree with literally every word you wrote. But what is this “mastery” or “craft” then? if we agree (rightfully so) that some special people exist, eventually (or immediately) other people get involved, we as industry accept “we had a deadline so it was cool to ‘cut corners’ etc…” - where is mastery or craft in this process? I have and I am sure you have worked with some amazing people over the years but to me our e…

I think people have a very weird notion of mastery and think it looks very different in other fields. That’s because mastery no longer looks like mastery once you attain it. Mastery also doesn’t look like the absence of imperfections - even art house films by master auteurs will have imperfections the masters will see and compromises they had to make to get a film done. Talk to a master builder and they’ll instantly start pointing out flaws in buildings. Electrical grids regularly see outages despite.

So my question then is how would you define mastery if you believe our industry doesn’t practice it.

Re: How good engineers write bad code at big companies

#287

Post by _dain_ » Sun, Nov 30, 2025, 12:17 AM UTC

omnicognate wrote: post #240

matwood wrote: post #211

Earlier quoted context omitted.

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…

I've come to quite a specific definition of "bad code", at least the main form of bad code that infests corporate environments. It's overly complicated code, but people disagree on what that means too, and I have a concrete definition of that now. Bad, over-complicated code is code that requires you to form an unnecessarily detailed mental model of it in order to answer a particular question you may have about it. Pe…

>People rarely read code in its entirety, like a novel. There is almost always a specific question they want to answer. It might be "how will it behave in this use case?", "how will this change affect its behaviour?" or "what change should I make it to achieve this new behaviour?". Alternatively, it might be something more high level, but still specific, like "how does this fit together?" (i.e. there's a desire to understand the overall organisational principles of the code, rather than a specific detail).

+1. For me the most frustrating one is "where is the core logic for this one user-visible feature actually implemented?"

You look in all the obvious places and it's just nowhere to be found. Or it's shredded into tiny pieces and scattered across multiple files and seventeen layers of inheritance ...

Re: How good engineers write bad code at big companies

#288

Post by mesarvagya » Sun, Nov 30, 2025, 12:27 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…

> “You’re a senior engineer - why did fixing this take so long?”

Now add "Why can't you use/ask AI agents to fix it?" which is being shoved through your throat by management.

Re: How good engineers write bad code at big companies

#289

Post by Ygg2 » Sun, Nov 30, 2025, 12:33 AM UTC

godelski wrote: post #278

Ygg2 wrote: post #249

Earlier quoted context omitted.

> How do you say no in that situation? Just quit? Apparently so. It seems GP never had to pay for their siblings to get through college, while paying rent. Just say no, quit, and ruin life of your loved ones, and become homeless. Ez.

The GP has been homeless and lived off of discarded food. You're right that saying "no" is a privilege. But also there's nothing as empowering as knowing that it's not going to be as bad as it was before. Stop making assumptions about me and start trying to communicate with me. We can't talk if you want me to be wrong and just reinforce your position. And sorry, I'm not as good as doing the cat wrangling in social se…

I did talk to you. Seniors don't matter, neither do junior, janitors, and to large part execs and CTO.

Processes, and the whole structure of company, and past events determines the outcome not individuals. And on top of that broad economic movements.

A good carrot in a rotten soup, is just a rotting carrot to be.

Re: How good engineers write bad code at big companies

#290

Post by Ygg2 » Sun, Nov 30, 2025, 12:39 AM UTC

godelski wrote: post #277

sethammons wrote: post #230

Earlier quoted context omitted.

My CTO, when told that adding scope, reducing headcount, and keeping the same timeline all while discovering new unknowns in the codebase was not possible, we were simply told to make the date and asked who's performance review will be impacted. The "no" was entirely ignored. "I don't accept that." How do you say no in that situation? Just quit?

I think bosses are like cats, when training them you have to make it think it is their idea. As I said in a sister comment the best way to do this is to not say the word "no" but to ask clarifying questions[0] so that all the puzzle pieces get placed on the table. Together you can assemble most of the puzzle, taking the lead but not lecturing them. But the final pieces have to be put together by them. Management is e…

I get the feeling you didn't work in a dysfunctional company.

Here is some anecdata. I came onto a team, that had team lead, product owner fight tooth and nail to not use boolean special flags for some case.

Instead the Product Lead went to CTO and overruled them. A product lead that ain't a programmer told programmer's to shove it, and do how he wants it.

This flag along with many, many such cases has been caused problems ever since.