[HN Gopher] Good engineers write bad code at big companies
___________________________________________________________________
Good engineers write bad code at big companies
Author : gfysfm
Score : 115 points
Date : 2025-11-28 19:59 UTC (3 hours ago)
(HTM) web link (www.seangoedecke.com)
(TXT) w3m dump (www.seangoedecke.com)
| n4r9 wrote:
| The referenced article Pure and Impure Engineering was discussed
| a few months back here:
| https://news.ycombinator.com/item?id=45165753
| lloydatkinson wrote:
| I find these drive-by-attacks on CQRS to be particularly
| frustrating. Some people know CQRS or CQS are fairly
| straightforward ideas that can be nice to use and give you some
| benefits. Some people believe CQRS is some kind of elitist
| architecture authoritarianism bogeyman in the same category as
| the microservice pushback.
| jeltz wrote:
| I don't really buy that this is the main reason. A good senior
| engineer is for the most part able to not write bad code from day
| one, just at a very low speed and with the need to ask other
| people frequenyly. Even if you do not know the code base or
| domain yet there are a lot of things you can do to avoid writing
| bad code. Yes, as someone new you will make mistakes and
| misunderstand things but a lot of the bad code I have personally
| seen has not been caused by that. Most bad code I have seen has
| been caused by people rushing and not having their fundamentals
| in order. Like not actually doing reviews, not spending a few
| extra hours to think about architecture, etc. Also a big issue is
| that people just let the complexity of systems explode for the
| gain of short term projects.
|
| I think the issue is more that engineers face unreasonable
| pressure to deliver short term value and that there is no respect
| for the craft/engineering from many managers or even engineers.
| morkalork wrote:
| The worst code I've ever written is because of shifting or
| unforeseen requirements. It doesn't matter how good the
| architect is if the foundation is built on sand.
| jeltz wrote:
| 100% agreed. But to me that sounds like a typical case of
| rushing instead of working like responsible engineers. If the
| foundation is built on sand then that needs to be fixed.
| Engineers being expected to magically paper over a lack of
| clear requirements is what leads to bad code. I am fine with
| helping gather the requirements but if I get a list of
| unclear and shifting requirements and just is expected to fix
| it I obviously will fail.
| veverkap wrote:
| > 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.
| jeltz wrote:
| 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.
| veverkap wrote:
| It depends a lot on the circumstance.
| toast0 wrote:
| 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 are going to use your product before
| you build it, but sometimes you build what you think is
| wanted, and people only use part of it or use it for
| different things than what was intended, and it's better to
| adjust and refocus than to start a whole new development
| process with the found requirements.
| jeltz wrote:
| 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.
| veverkap wrote:
| I think it's probably a bit of both. A good senior engineer may
| pick up a task and look at the system, seeing hacks duct taped
| together with kite string, and have the choice between "doing
| it right" (aka rewrite/refactor) and getting shit done.
| dave_sid wrote:
| They wouldn't have to fix the entire codebase to be doing the
| right thing. That approach would be more likely taken by a
| junior who would soon find they are fighting a losing battle.
| The senior engineer would accept the state of the world and
| consider how to make small, deliverable, manageable
| improvements one PR at a time, to improve the code over a
| longer period of time without breaking the system.
| godelski wrote:
| > A good senior engineer is for the most part able to not write
| bad code from day one
|
| This seems unlikely. Self contained, I'd go further and say
| you're not a senior if your code isn't good you shouldn't be a
| senior.
|
| But what is good code is in context of the codebase. It takes
| time to get the context of a reasonably sized codebase and no
| one is doing that in a single day or single week, even the
| wizards.
|
| I don't agree with everything the OP writes but I think they're
| correct in that many companies don't value institutional
| knowledge. To me that is lunacy. I'm not sure how any
| programmer could think a reasonably complex codebase could be
| learned quickly. The larger and more complex your codebase the
| more valuable institutional knowledge is. Adding new actors
| just accelerates complexity and redundancy. Pushing people to
| be quick only worsens this. The best thing to do with new
| employees is get them deep into the code. Have them
| write/update docs, do cleanup, or other tasks that force them
| to understand the code and how everything interacts
| nosianu wrote:
| Then how do you work with this:
| https://news.ycombinator.com/item?id=18442941
|
| I did that job, just after university, but that is not my
| comment. I bookmarked it though because that person said it so
| well.
|
| You _will_ write bad code, because what you already find there
| - and that one company is not alone! - is already so bad, there
| is no way to do a good job on top of literally millions of
| escalating hacks.
|
| And don't think that you could clean this up - not even with
| ten years of time is that possible. You can only rewrite from
| scratch. Trying to rewrite even a tiny part is like picking up
| one spaghetti and always ending up with the whole bowl on your
| fork.
| tim1994 wrote:
| Another reason I can think of is the requirement not to
| introduce a breaking change. It is very frustrating if the
| codebase has a lot of hacky/bad code in it but a lot of it
| can't be changed...
| lapcat wrote:
| > They are almost certainly working to a deadline, or to a series
| of overlapping deadlines for different projects.
|
| I think this is crucial. Even old hands working on their area of
| expertise can be compromised by deadlines.
| jeltz wrote:
| Yeah, I in my experience this is the root of most bad code.
| People rushing. And it is not even necessarily faster to rush,
| since often working slow and methodical wins the race. I don't
| get why we as managers and engineers have just accepted rushing
| and taking shortcuts as the default. Especially at the big tech
| companies this constant rush makes zero sense, they have tons
| of engineers they use very inefficiently.
| Herring wrote:
| _> Big companies know that treating engineers as fungible and
| moving them around destroys their ability to develop long-term
| expertise in a single codebase. 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._
|
| And also to "keep the balance of power tilted away from engineers
| and towards tech company leadership." The author touched on that
| and forgot about it. You don't want key projects depending on a
| group of engineers that might get hit by a bus or unionize or
| demonstrate against Israel or something. Network effects and
| moats and the occasional lobbying/collusion mean the quality of
| your product is less important.
| zanellato19 wrote:
| Yeah, this is a deliberate choice to make labor less powerful.
| Capital is willing to be less efficient for that. He does touch
| upon this by saying that Capital wants every worker to be
| replaceable.
| bdangubic wrote:
| if I learned anything in my (too) long career is that one
| should do everything possible to ensure that whoever pays you
| needs you more than you need the money they are paying you.
| it is not easy to get there right away but if you make this
| core thing in your career it is achievable and your career
| will be happy and prosperous
| hereme888 wrote:
| I'm just gonna drop this funny roast song here. Hope it's heard
| lightheartedly:
|
| https://suno.com/song/d6d77518-16ca-455f-ade1-0e8d08fc4b0b
| stuxnet79 wrote:
| Maybe I have it wrong but the very essence of "engineering" is
| managing the constraints of (1) providing an acceptable solution
| to a problem (2) within some fixed parameters of time and cost.
|
| The code may look "bad" in a vacuum but if it yielded a
| successful outcome then the engineer was able to achieve his/her
| goal for the business.
|
| The stories shared in this article are exactly what you'd expect
| from big tech. These are some of the most successful firms in the
| history of capitalism. As an engineer you are just grist in the
| mill. If you want to reliably produce "good" code then IMO become
| an artist. And no ... working at a research facility or non-
| profit wont save you.
| lapcat wrote:
| > The code may look "bad" in a vacuum
|
| Substitute "buggy" for "bad". The links in the first sentence
| of the article refer to bugs, which affect end users of the
| products.
|
| > If you want to reliably produce "good" code then IMO become
| an artist.
|
| This is not about aesthetics but rather about QA.
| tyleo wrote:
| I don't think the underlying point is true: big companies don't
| necessarily write bad code.
|
| A big company is like a collection of small companies. Code
| quality varies depending on where you are in it.
|
| Similarly, nothing leads me to believe small companies are any
| better. Some are excellent. Some are nightmare spaghetti.
| veverkap wrote:
| Big companies oftentimes have cultures and leadership that lead
| to bad code.
| cm2012 wrote:
| Big companies are insanely slower due to beauracracy and rules,
| even if talent is identical. I have seen it happen so many
| times as companies grow and go IPO.
| matt3210 wrote:
| It's always a trade off between raising the bar and making a
| deadline. The deadline always wins since the boss doesn't know
| how to read code
| jeltz wrote:
| Sadly a lot of engineers have been indoctrinated into this
| mindset and I have had to fight quite many battles to conceive
| my fellow engineers that missing a deadline is not the worst
| thing in the world.
| veverkap wrote:
| Then you've been fortunate to work at places that respect
| engineering.
| jeltz wrote:
| Yes, I have. I have also worked at placed which do not. And
| the difference is night and day. The places which respect
| engineering are more fun to work at, deliver better
| features for less cost and the code is better. Only places
| which can deliver faster are crazy startups which
| constantly crunch time (I have worked at those too) but
| those are hell and the code is a mess.
|
| The main cost I have seen at places which respect
| engineering is lower predictability. It is harder to budget
| and plan even if the end result in average is usually
| cheaper and always better.
| lukan wrote:
| "I love deadlines. I love the whooshing noise they make as
| they go by." -- Douglas Adams
| austin-cheney wrote:
| The short tenure is a symptom of a larger problem. The deeper
| problem is that very little is expected of big company software
| employees. Conversely those same employees tend to expect a lot
| in return. You can call that entitlement, poor expectation
| management, first world problems, and all kinds of other names.
|
| I have not worked for a FAANG, so maybe things are different
| there, but I don't suspect so. People are people no matter where
| you put them.
|
| Increasing compensation is not the solution. It can be a factor
| in a larger solution, but just increasing compensation increases
| employee entitlement which makes this problem worse, not better.
|
| The best solution I have seen is risk/reward. Put people in
| charge of their assigned effort with real adult danger of
| liabilities. Likewise, award them for their successes. This is
| called ownership, and it works because it modifies people's
| behavior. The rewards and liabilities do not have to be tied to
| compensation. Actually, associating these rewards/liabilities to
| social credibility within the team/organization appears more
| effective because it reinforces the targeted behaviors.
|
| I have seen this missing in all of my software career until my
| current employment. Conversely people in the military are pushed
| into this liability/reward scenario from the very beginning and
| its very effective. It has always been striking to see the
| difference in my dual career progression.
| innocentoldguy wrote:
| 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
| _SomePublicModule.Private_ module as public functions so that he
| could "test them."
|
| I tried _almost_ in vain to fix these two ridiculous decisions,
| but the company refused to let code fixes through the review
| process if they touched "well-established, stable code that has
| been thoroughly tested." After being there for a couple of years,
| the only thing I was able to fight through and fix was the BEAM
| issue, which ultimately cost me my job.
|
| My point in all this is that, at least sometimes, it isn't good
| engineers writing silly code, but rather a combination of
| incompetent/ignorant engineers making stupid decisions, and
| company policies that prevent these terrible decisions from ever
| being fixed, so good engineers have no choice but to write bad
| code to compensate for the other bad code that was already
| cemented in place.
| toast0 wrote:
| > 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 put your tests in the
| PublicModule. Or you can just solve this by not testing your
| private code ;)
| zkmon wrote:
| The actual coding work in most non-tech big companies, is
| considered a low-level or dirty work and is delegated to the
| contractors or junior developers, who just can't bother anyone to
| get the information. As a result, bad code happens.
|
| Also, the process, security, approvals and compliance could
| dominate so much that less than 20 lines of code changes per week
| could become the norm and acceptable.
| hkleppe wrote:
| You have to realise there is a almost full complete disconnect
| between engineering and business value
| pyrale wrote:
| That is, until planes fall from the sky.
| tjr wrote:
| It's popular to mock aerospace engineering, but it's usually
| quite robust. Even if people still sometimes make bad
| decisions.
| brazukadev wrote:
| And move slowly. So when things turn bad, they will be bad
| for a decade - or more. See Boeing.
| awesome_dude wrote:
| Boeings (software) issues stem from a removal of their
| Engineering skillset and replacing it with an outsourcing
| model don't they?
| DarkNova6 wrote:
| Only if there are is organizational disconnect... which is the
| norm.
| alephnerd wrote:
| Ime, a lot of the onus falls on Engineering and Product
| Management failing to make a case for _why_ certain engineering
| decisions (eg. Investing in continual tech debt grooming) have
| business value.
|
| The point of a business is to generate revenue. The point of
| employees is to do work that helps generate revenue. As such,
| any decision needs to ensure it has a business case aligned
| with revenue generation.
|
| Good engineering hygine has significant business value such as
| in speeding up delivery of new features as well as keeping
| certain customers happy, but in a lot of cases there is an
| inability to communicate from either direction (eg. PMs not
| giving Eng full visibility into business decisions, and Eng not
| being able to explain _why_ certain engineering choices have
| business value). If you cannot communicate _why_ this matters,
| you aren 't going to get it prioritized.
|
| Unsurprisingly, at big organizations, communication can take
| the backseat because communication is _hard_ and at a large
| company, there is some amount of complacency because the
| product is good enough.
|
| Edit: Unsurprisingly got downvoted.
|
| The only reason you are employed is to make value (which
| generally is measured in revenue generated). You are not paid
| $200k-$400k TCs to write pretty or a e s t h e t i c code. You
| can make a case for _why_ that matters, but if you choose to
| bury your head in the sand and not make that case, I have no
| sympathy for you.
| zwnow wrote:
| I work for some event ticketing business and I'd sign this.
| My bosses want features quickly. Does not matter to them if I
| need extra time to make stuff secure, doesn't matter to them
| if it wont scale. Its about short term revenue. Can always
| rebuild the software to fit the next short term goal...
| alephnerd wrote:
| If you understand what are the metrics being tracked, and
| what are the primary goals that an initiative or product
| has, you can make a case.
|
| We are an engineering discipline and engineering decisions
| can have revenue making implications. But it is hubris to
| assume _why_ you should care about the nitty gritties of a
| codebase. It 's the same way no one in leadership cares
| about the nitty-gritties of HR policies or accounting
| practices - people are hired to deal with the intricacies.
|
| When I was a PM, I didn't have a difficult time making a
| business case for "keep the lights on" or tech debt work
| _so long as_ I was able to attach tangible revenue
| implications (eg. X customer might churn because of subpar
| experience and we have both customer testimony and user
| stats showing that) or roadmap implications (eg. If we
| spend 6 months refactoring our monorepo, we can add new
| revenue generating modules every quarter instead of
| annually).
| ethanwillis wrote:
| The point of a business is to generate profit.
| wubrr wrote:
| Communication is not hard, it's very easy, but there are
| actors who's goal is to obfuscate communication and prevent
| others from participating.
|
| At the end of the day it comes down to who the decision
| makers are and how they are incentivized to act. As a simple
| example - company X has product C, and they set a goal of
| increasing usage of feature F (of product C). Currently this
| feature F completely sucks and users don't want to use it -
| so the idea is to improve it and thus increase usage.
|
| There are 2 ways of increasing usage:
|
| 1) Make the feature F more useful/better.
|
| 2) Force/push your users to use feature F, by aggressively
| marketing it, and pushing it within the product surfaces,
| making it non-optional, etc. and other dark patterns.
|
| Option (1) is hard to do - it requires deep understanding of
| the product, user needs, the related tech, etc. It requires
| close tactical collaboration between product and engineering.
|
| Option (2) is easy to do - it requires ~zero innovative
| thinking, very surface-level understanding of the problem,
| and relies purely on dark patterns and sketchy marketing
| tricks. You can almost completely ignore your engineers and
| any technical debt when following this approach.
|
| If your decision makers are imposter PMs and marketing/sales
| people - they will almost always choose option 2. They will
| increase the 'apparent usage' of this feature in the short
| term, while reducing overall customer satisfaction increasing
| annoyance, and reducing the company's overall reputation.
| This is exactly how many 'growth' teams operate. Short term
| benefit/gaming of metrics for long term loss/reputational
| damage. Their success metrics are always short-term and
| linked directly to bonuses - long term effects of these kinds
| of strategies are ~always completely ignored.
| ihsw wrote:
| * Product folks over-promise
|
| * Engineers are consulted for estimates to facilitate long-term
| planning
|
| * Middle management slashes those estimates in half due to
| pathological myopia
|
| * Executives enforce musical chairs to assert their authority
|
| * Consultants muck everything up while collecting enormous
| payouts
|
| And yet the business cycle keeps cycling.
| wubrr wrote:
| The disconnect is more between long term business value, and
| short term benefit for the most parasitic and manipulative
| actors within the business.
|
| Engineering and business value go hand-in-hand in a healthy
| tech/engineering business.
|
| A business that was built on great/innovative engineering,
| became successful, and then got taken over by various impostors
| and social manipulators, who's primary goal is gaming various
| internal metrics for their own gain, is not a healthy business.
| Herring wrote:
| I think that's a bit unfair. I'd say shipping a product that
| solves a problem is the baseline entry fee into the market.
| Profitability is determined by the machine built around the
| product: the efficiency of capital deployment, the speed of
| distribution, the defensibility of the business model against
| competition, etc. The product is just one variable in a much
| bigger equation.
| epgui wrote:
| > That's a deliberate tradeoff.
|
| In my experience, while this line is often repeated, in practice
| it's rarely really a "deliberate" tradeoff. Rather it's mostly
| accidental.
| cdavid wrote:
| I can believe it is deliberate at the top, I've certainly seen
| first hand in several orgs I've worked at.
|
| My sense is that unless actively managed against, any org big
| enough to have a financial department and financial planning
| will work under assumption of fungibility.
| samdoesnothing wrote:
| I think it's more that optimizing your hiring process for
| leetcode savants selects developers who prioritize algorithmic
| practice over everything else. They also deprioritize character
| over raw technical skill. But it turns out you need well rounded
| developers who are able to work with others, communicate well,
| and have taste. If your hiring process deprioritizes that, don't
| be surprised when the software produced is shite.
| jeltz wrote:
| Yes, that is an issue they have but I do not think it is the
| main issue. In these orgs even week rounded engineers can be
| made to write bad code.
| samdoesnothing wrote:
| Yeah that's true. As with most things it's a mix of factors.
| can3p wrote:
| The other reason is the volume of the code being produced
| combined with the constant product changes. An innocent change
| like mixing two close but still different concepts can easily
| poison the whole codebase and take years to undo and may even be
| nearly impossible to fix if it propagates to external systems
| outside of direct control
| pxc wrote:
| I think, sadly, that's often "the job". My career has been good
| so far, all things considered, but I think it would probably be
| better if embracing that idea came more naturally to me.
|
| One of my first strange and unpleasant realizations in
| transitioning from studying computer science to "working in the
| real world" came in a 1:1 meeting with my manager at my first job
| out of school. I was complaining about code quality both in the
| context of some of our existing codebases and some new code one
| of my peers (also a junior developer) had recently written. When
| the light bulb finally lit up in my naive little head, the
| question I asked my manager with a sense of horror and outrage
| was "... so you're saying they wrote bad code on purpose?". The
| painful thought was that I, too, would (or had already) found
| myself tasked with pushing code that I knew sucked, for reasons
| entirely unrelated to architecture or design or other purely
| "technical" constraints.
|
| I used to fantasize about moving into a different software niche,
| maybe in safety critical systems, where correctness is more
| highly valued. But recently I'm coming to realize that the thing
| I crave (and miss from my school days) is the joy of the _craft_
| -- something involving elegance and taste in a way that even the
| strictest standards of correctness doesn't necessitate.
|
| I think for the most part, truly excellent code isn't something
| many businesses perceive themselves as _needing_ (even if many
| practical benefits can flow from its virtues). And, probably, for
| many businesses, such indifference is right. So excellent code,
| where it exists, is probably more often "gotten away with",
| half-snuck in by stubborn engineers who are productive enough to
| burn time injecting some extra consideration and effort into
| their code, than it is commissioned by a business which
| understands that it wants good code.
| mikert89 wrote:
| 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 extremely risky and
| complicated. The individuals that built the software will lord
| over everyone else with their arcane knowledge of this big pile
| of junk
| bad_haircut72 wrote:
| 100% this. Stuff like database schemas gets comitted in the
| first sprint and never gets refactored, which completely locks
| you in to long term design decisions, then every subsequent PR
| will get held up for days in arguments around meaningless "code
| quality" arguments which ultimately affect nothing
| mikert89 wrote:
| ive never actually seen someone get fired for making some
| deep architectural software mistake. its alway for moving too
| slow, or "low code quality". i think people that were
| promoted for building systems that turned out bad, should be
| demoted
| dave_sid wrote:
| You can't often demote them because usually the people
| responsible for bad initial design decisions left the
| company years ago with a desperate need to go and start a
| new mess somewhere else.
| skhameneh wrote:
| > i think people that were promoted for building systems
| that turned out bad, should be demoted
|
| Nope, in the same vein of "lording" over others, they
| become the expert of knowledge of bullshit. The
| environments that allow such behavior have already
| engrained reward of such behavior.
| huqedato wrote:
| ...and also bad engineers write bad code at small companies.
| mtnygard wrote:
| Middle management gets reorged almost as frequently as the
| engineers. So they have little to no incentive for long term
| viability of the code either.
| nathancspencer wrote:
| The claim this article makes about very short tenures at big tech
| is misleading. Because of headcount growth, the median tenure is
| naturally going to be short. Google grew headcount by 60% the
| year before 2013. A better statistic to be use would be median
| tenure, given the employee has already left.
| inopinatus wrote:
| This appears to be why Sonos went utterly to shit. Some mediocre
| product managers got together and decided the mesh overlay
| networking they'd spent years neglecting was now "legacy" instead
| of being their sole technological advantage, and threw it away in
| favour of everything joining standard wifi and being mediated
| through cloud services and a really shitty new app, which remains
| shitty despite the vacuous protestations of their CEO. Crippling
| their own diagnostic tooling at the same time just to really piss
| off the power users.
___________________________________________________________________
(page generated 2025-11-28 23:00 UTC)