How good engineers write bad code at big companies

Every couple of years someone notices that big tech companies sometimes produce shockingly bad code. If you haven’t worked in a large company, it can be hard to understand how this happens. Big tech companies pay well enough to attract many capable engineers. They move so slowly that it feels like they are able to take their time and do a solid job. How does bad code happen?

Most code changes are made by concerned beginners

I think this is the main reason Big companies are full of engineers working outside their area of ​​expertiseThe average big tech employee only stays for a year or two^{In fact, large technical compensation packages are typically designed to impose a four-year limit on an engineer’s tenure: after four years, the initial share grant vests completely, allowing engineers to take a 50% pay cut, Companies offer temporary annual refresh increases, but this apparently encourages engineers to find another job where they won’t have to wonder if they’ll get half their compensation each year,}

It’s even worse if you count internal dynamics. The longest I’ve ever stayed on a single team or codebase was three years, which was near the beginning of my career. I expect to reorganize at least every year and often more often than that.

However, the average tenure of a codebase at a big tech company is much longer than that. Many of the services I work on are a decade or more old, and have had many, many different owners over the years. This means that many big tech engineers are constantly “figuring it out”. A very large percentage of code changes are made by “newbies”: People who have been involved with the company, the codebase, or even the programming language in the last six months.

old hands

To some extent, this problem is mitigated by “old hands”: engineers who have been in the orbit of a particular system long enough to develop real expertise. These engineers can provide thorough code reviews and reliably catch obvious problems. But there are two problems with relying on “old hands”.

First, This process is completely informalBig tech companies make surprisingly little effort to develop long-term expertise in individual systems, and once they achieve it they don’t care at all about maintaining it, Often the engineers concerned are transferred to different services, and have to either effectively carry on their “old” duties on a volunteer basis, or abandon them and become relatively newbies on a brand new system,

Second, Experienced engineers are always overloadedthis is one Busy Jobs is one of the few engineers who has deep expertise on a particular service. You don’t have enough time to personally review every software change, or be actively involved in every decision-making process. remember that you also have to do your work: If you spend all your time reviewing changes and engaging in discussions, you’ll probably be penalized by the company for not providing enough personal output.

average productive engineer

Putting it all together, what is the average producer? ^{What does an engineer at a big tech company look like? They are generally:}

• Sufficiently competent to pass the recruitment examination and be able to do the job, but either
• Working on a codebase or language that is largely new to them, or
• Trying to survive the flood of code changes while also handling your own work.

They are almost certainly working to a deadline, or to a series of overlapping deadlines for different projects. In other words, They’re trying to do their best in an environment that isn’t set up to produce quality code.

This way there is “obviously” bad code. For example, a junior engineer raises a ticket for an annoying bug in a codebase they’re barely familiar with. They spend a few days figuring it out and come up with a hacky solution. One of the more senior “old hands” (if they’re lucky) takes an extra half hour to take a look at it, veto it, and suggest something better that will at least work. The junior engineer implements as much of it as possible, tests that it works, gives it a brief review and ships it, and everyone involved immediately moves on to higher-priority work. Five years later someone noticed this ^{And thinks “Wow, this is hacky – how did such bad code get written at such a large software company”?}

Big tech companies agree

I’ve written a lot about the internal tech company dynamics that contribute to this. Most directly, in Looks like a software company I argue that big tech companies consistently prioritize internal clarity – The ability to see at a glance who is working on what and change it at will – more than productivity. Large companies know that dealing with engineers and moving them around destroys their ability to develop long-term expertise in a single codebase. This is a deliberate compromise. They are giving up some degree of expertise and software quality to gain the ability to rapidly deploy skilled engineers on any problem of the month.

I don’t know if this is a good idea or a bad idea. It certainly seems to be working for big tech companies, especially now when “how fast can you focus on something AI related” is so important. But if you are doing this, then Absolutely You’re going to produce some really bad code. This happens when you ask engineers to work quickly on systems they are unfamiliar with.

Individual engineers are completely powerless to change this dynamic.This is especially true in 2025, when the balance of power has tilted away from engineers toward tech company leadership, The most you can do as an individual engineer is to try to be an “old hand”: develop expertise in at least one area, and use that to prevent the worst changes and steer people toward at least minimally-sensible technical decisions, But that also often goes against the grain of the organization, and if done inexperiencedly can leave you PIP-ed or worse,

pure and impure engineering

I think a lot of it depends on the difference between pure and impure software engineering. For pure engineers – engineers working on self-contained technical projects like programming languages ​​– the only explanation for bad code is incompetence. But unclean engineers work like plumbers or electricians. They’re working to deadlines on projects that are relatively new to them, and even if their technical fundamentals are impeccable, there’s always something to work on. Some? What is strange or surprising about the specific arrangement of this situation. For unclean engineers, bad code is inevitable. As long as the overall system works well enough, the project is successful.

In large technology companies, engineers cannot decide whether they are working on pure or impure engineering work. This is not their codebase! If the company wants to move you from working on database infrastructure to building new payment systems, they are perfectly entitled to do so. The fact that you may make some mistakes in an unfamiliar system – or that your old colleagues in the database infra team may suffer without your expertise – is a deliberate compromise. Company, not engineer,

It’s okay to point out examples of bad code in large companies. If nothing else, it can be an effective way to fix those specific instances, as executives usually take advantage of the opportunity to turn bad PR into good PR. but i think it’s a mistake ^{Assigning primary responsibility to the engineers of those companies. If you could wave a magic wand and make every engineer twice as strong, you will still have bad codeBecause almost no one can come in to a brand new codebase and make changes immediately with zero mistakes. this is the root cause Most large company engineers are forced to do most of their work in unfamiliar codebases,}