27 ms·
How good engineers write bad code at big companies
- n4r9 10mo agoThe referenced article Pure and Impure Engineering was discussed a few months back here: https://news.ycombinator.com/item?id=45165753 https://news.ycombinator.com/item?id=45165753
- lloydatkinson 10mo agoI 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.
- sigotirandolas 10mo agoThere's definitely some that hold CQRS, DDD, TDD, ... as _the_ way to design software and over-engineer around it, so I can understand some pushback. Knowing those patterns is very helpful as a way to think about design problems, as long as you have the common sense to realize applying the pattern "by the book" is often overkill and you can just take some ideas out of it. That article conflates as "Pure engineering" both reducing a software system to a small set of cohesive concepts, and architecture astronauts, when those are polar opposites.
- n4r9 10mo agoI searched for "CQRS" in both the HN thread that I linked and the article that that linked, and the only mention I could find was this: > Companies burned hundreds of thousands of engineer-hours migrating from monoliths to microservices, or from HTTP service calls to event-sourced architecture, or from event-sourced architecture to full CQRS, and so on. Is that what you're talking about? imo this hardly counts as an attack on CQRS itself. The issue is rather with enterprise companies forcing the migration of large codebases based mostly on hype.
- lloydatkinson 10mo agoThe reason you missed it is because it's a relentless attack on anything testing, anything DDD, anything CQRS, generally speaking across HN or Reddit or anywhere else. I didn't mean it was just this thread. The example I gave was just another one of them!
- n4r9 10mo agoI'm struggling to make sense of what you're saying. Is there something concrete - some subtlety - that I missed? I searched HN comments for mentions of "CQRS" over the past year. It's mentioned very infrequently outside of "who's hiring" posts, and mostly in a neutral manner. Very little of what I'd describe as a "drive-by attack".
- jeltz 10mo agoI 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 10mo agoThe 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 10mo ago100% 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 10mo ago> 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.
- 10mo ago
- lapcat 10mo ago> 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 10mo agoYeah, 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.
- pdimitar 10mo agoWhat is there to get? Bull-headed egomaniacs on a power trip are the norm in most of the world -- on the executive positions, middle managers included. Reasoning with unreasonable people is not impossible but drains too much time and energy... and you don't know if they will not come back to you next week and hit you with "You know what, I actually think that your idea is not as good. Let's get back to mine and...". I have danced this dance. As much as it pains my younger idealistic self to say this, you'll know how well you'll work with somebody after the end of the first week. All the signs are there, we just choose to ignore them because you can't bail during your first month after all.
- Herring 10mo ago> 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 10mo agoYeah, 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 10mo agoif 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
- jeltz 10mo agoDoesn't that just mean you are underpaid?
- stoneforger 10mo agoIt means that we are okay with being exploited and that's almost universal except for the sociopath class
- 10mo ago
- hereme888 10mo agoI'm just gonna drop this funny roast song here. Hope it's heard lightheartedly: https://suno.com/song/d6d77518-16ca-455f-ade1-0e8d08fc4b0b https://suno.com/song/d6d77518-16ca-455f-ade1-0e8d08fc4b0b
- stuxnet79 10mo agoMaybe 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 10mo ago> 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 10mo agoI 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.
- matt3210 10mo agoIt’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 10mo agoSadly 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 10mo agoThen you've been fortunate to work at places that respect engineering.
- jeltz 10mo agoYes, 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 10mo ago"I love deadlines. I love the whooshing noise they make as they go by." ― Douglas Adams
- doctorpangloss 10mo agoDeadlines are a way to manage people. They’re fine but most deadlines are not real. There are other ways to manage people, such as paying people more in bonuses for goals.
- 10mo ago
- austin-cheney 10mo agoThe 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.
- deleted 10mo ago[deleted]
- VirusNewbie 10mo ago>I have not worked for a FAANG, so maybe things are different there, but I don't suspect so it is quite a bit different at FAANG. I've workded for small companies, huge companies that aren't software/FAANG, and now FAANG, and it's definitely better here. The floor is very high for talent and just an overall ability to get stuff done. Google certainly doesn't have a monopoly on genius coders, i've met brilliant folks at all different size companies. It is very good at making sure the caliber of the average engineer is quite high. Code quality is shockingly good across teams and codebases. I said good, not amazing, there are definitely differences in teams and I can cherry pick projects outside of google that had better code than some at google. But the consistency of it being decent is very high. I'm also dubious of your claim that compensation doesn't attract better talent. In my 25+ years of coding, it's a pretty damn strong correlation. The people who leave google to go to even higher paying places like the top hedge funds or Anthropic are not the most 'average' caliber talent, it's usualy the better folks.
- innocentoldguy 10mo agoI 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 10mo ago> 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 ;)
- innocentoldguy 10mo ago> 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.
- zkmon 10mo agoThe 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 10mo agoYou have to realise there is a almost full complete disconnect between engineering and business value
- pyrale 10mo agoThat is, until planes fall from the sky.
- tjr 10mo agoIt's popular to mock aerospace engineering, but it's usually quite robust. Even if people still sometimes make bad decisions.
- brazukadev 10mo agoAnd move slowly. So when things turn bad, they will be bad for a decade - or more. See Boeing.
- awesome_dude 10mo agoBoeings (software) issues stem from a removal of their Engineering skillset and replacing it with an outsourcing model don't they?
- pyrale 10mo agoThe goal wasn't to mock Boeing, just to point out what happens when business overrides engineering. The context is the parent post making the point that there is little business value in good engineering.
- tjr 10mo agoAh, I see where you're coming from. I've been hearing a lot of people talk poorly of aerospace as a whole recently, due to some Boeing issues, and I misread your comment as such. Apologies and thanks.
- 10mo ago
- epgui 10mo ago> 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 10mo agoI 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.
- matusp 10mo agoI think it's cultural. Managers today do daily stand-ups, one-on-ones, retrospectives, syncs, and all kinds of meetings. They are heavily invested in the day-to-day operations of the team. The societal expectation for this role is that they are hands-on, and when a problem arises, they will immediately do some shuffling or reshuffling to address whatever problem is at hand. In a sense, this is the outcome of agile-like methodologies spreading in the industry. If this is the tool we are teaching managers to use, of course it's the tool they are going to use.
- deleted 10mo ago[deleted]
- samdoesnothing 10mo agoI 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 10mo agoYes, 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 10mo agoYeah that's true. As with most things it's a mix of factors.
- can3p 10mo agoThe 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 10mo agoI 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.
- britch 10mo agoI think about this a lot. My belief is professional programmers should not be artists. I think about other professions. A cook cannot spend time making every dish perfect. A bricklayer isn't perfectly aligning every brick. Even in movie-making there's a shooting schedule. Things go wrong and the best filmmakers know how to keep the production moving. I love the craft of programming, but I see a lot other craft-oriented programmers who want every line to be beautiful. If you want to write code poetry in your off-time, that's your business. But that's not the job. At work we are bricklayers and cooks. We practice a craft, but also have time constraints. I try to do my best work while working at pace. Sometimes my code could be better, but it's not worth the time to fix. Ultimately the thing we make is the running software, not what's under the hood. The business people are sometimes right
- mikert89 10mo agowhat 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 10mo ago100% 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 10mo agoive 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 10mo agoYou 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 10mo ago> 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 10mo ago...and also bad engineers write bad code at small companies.
- mtnygard 10mo agoMiddle management gets reorged almost as frequently as the engineers. So they have little to no incentive for long term viability of the code either.
- deleted 10mo ago[deleted]
- nathancspencer 10mo agoThe 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, so no wonder the median tenure was 1.1 years. A better statistic to use would be median tenure conditional on that the employee has already left.
- Terr_ 10mo agoThe same process causes us to overestimate the rate at which older programmers leave the profession. Even if there was zero attrition, programmers with 40 years of experience would still be rare. The fresh newbie developers of 1985 were a small group by today's standards.
- deleted 10mo ago[deleted]
- area51org 10mo agoMaybe 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 of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.
- asdfman123 10mo agoNo, 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 work, so it doesn't value it at all. People who ship sloppy code get promoted.
- minikomi 10mo agoSo it's a problem of motivation you say
- mattashii 10mo agoThere is also a lot of money, there is also good management, and there are also lots of incentives. But management depends on your manager; at scale it becomes likely there are bad apples in every management tree. Incentives may not align with what you want or need, with work From Home policies getting shrunk. Even money sometimes is a point of contention.
- pdimitar 10mo agoThat's just the thing though: I want to know what those other incentives are and I was never told anything else than a hand-wavy "money" blurb with zero elaboration. I mean OK, technically the ad viewing experience in f.ex. iOS is terrible; you sit through 30 seconds, then a white button on an almost-white background appears (dark pattern, they want you to sit looking at the ad longer), then when you "dismiss" is, an AppStore pop-under shows up and you have to dismiss that as well, and ONLY THEN you get another screen where you have to wait 5-10 seconds until the blessed micro X button finally appears. This can be made much better: the ad platform might enforce the top-left corner be always black and the X button to appear only once and be effective immediately, for example. No shenanigans with bluffing that you are now leaving the ad but haha, you have fallen into our trap! Here's our AppStore page! But why should Apple care? The money is literally pouring in! And humans operate on fight-or-flight responses much more than what 99% of them would be willing to admit; an Apple executive can drown you in executive jargon but the naked truth would still be "We don't want to change anything that might slow down our income". Or even more bare: "Don't touch it if it works and makes money". So yeah, that's one of the examples where the hand-wavy "money" blurb would make total sense; I get it. But in all my career I was never told in clear certain terms -- and they must also make sense -- about why not investing just a measly two hours more on technical excellence is so extremely unwelcome. Of course they always cite velocity and customer retention and how we must make sure we don't miss a potential client but I've never seen even one little piece of evidence of customers churning because a feature was delivered on Wednesday and not Tuesday. I am sure it happens, mind you, but I could never shake the feeling that those dangers are always hugely exaggerated.
- lambersley 10mo agoRemember the Stanford Prison Experiment; "bad company corrupts good people."
- mberning 10mo agoIt is only briefly touched on in the article but most of the “best” engineers spend almost no time coding or engineering. I’ve worked at multiple Fortune 500 companies and many weeks I would be lucky to spend 4-8 hours coding. Often I would just work on things that interest me after hours or on the weekend since it would be unlikely to be bothered. Unless some other unfortunate soul happens to see you are online.
- 01100011 10mo agoIDK, 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.
- VirusNewbie 10mo agogithub does not have a good engineering culture compared to FAANG, they've had some horrible outages and made some questionable scaling choices.
- nfRfqX5n 10mo agoThe 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
- cbm-vic-20 10mo agoI'm an "old-hand" at a non-FAANG big tech, and have not had a meaningful refresher in a few years, or even a salary bump for that matter. This is a bad time to be looking for a new job, but I should have jumped ship years or even decades ago. I'm sure I'm under-compensated for my level of experience. Don't get caught in this trap like I did.
- orwin 10mo agoI did a mistake during an early refactor a year ago (the last refactor just before the code hit production, and any new update on models would demand a db migration), and i architectured and named a data structure poorly. Sadly it was a huge refactor on many part of the code, and we had a small team and few seniors, so the PR didn't catch the mistake. I noticed an issue with a new feature i couldn't fix in a satisfactory manner monday. I talked a lot, with the lead and the other senior early. First i started doing a shitty fix. Then i asked for a carefull review from the other senior, we discussed the issue and managed to find the origin of all the bad code. Then i asked for more time (well, i "told" more than asked tbh) and did a full refactor, correct this time (hopefully) (the deployment + migration script will run next monday). Writing bad code happen to everyone, at every company, especially when you don't have a lot of experience and domain knowledge. The issues appear when no one catch this bad code, or when people don't have the time or the latitude to fix it before it corrupt all the surrounding code.
- znpy 10mo agoThis overall makes sense. In my experience at a FAANG working on one of the core services for both internal and external customers, essentially two kind of people crank out great code: 1. "rock stars": they joined the company at 25 and they're still there at 35+. they're allowed pretty much everything (eg: no RTO, work from home country) and they know many codebases across the services very deep. they aren't really motivated to go look elsewhere, their grass is already one of the greenest. 2. people with kids. the company pays enough. they aren't really interested in switching job, rather they want to provide for their family. they're good, and maybe every now and then will push through for a promo in order to face new challenges in life (another child coming or some kind of new financial burden). i'm not saying either one is inherently good or bad. but yeah. in such large companies you end up working in on a very large codebase that interacts with other very large codebases. all the codebases are proprietary and you're lucky if you can use some libraries that come from the outside world (that have not been heavily lobo^H^H^H^H customized - the libraries i mean). you do what you can, you do your best, but you're essentially a relative beginner.
- sfpotter 10mo agoI'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 misguided. My instinct after reading this article is to pull back a bit and ask some larger questions. 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 reconcile ourselves to drift powerlessly as faceless and titanic forces sculpt our reality? So many possible questions.
- alfalfasprout 10mo agoInteresting. 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 reconcile ourselves to drift powerlessly as faceless and titanic forces sculpt our reality? So many possible questions. These are all great questions. I have some thoughts, of course. But I'm not sure it's fair to describe OP as a burnt-out nihilist. The premise of the post is pretty reasonable actually.
- sfpotter 10mo agoI 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.
- kcexn 10mo ago
- pmarreck 10mo agoMeanwhile, I have a ton of experience, am personable, am highly technical, and can't find something for some reason despite requesting a fairly moderate salary ($180k) given being 53 and having worked in technology for decades.
- Aeolun 10mo agoSomething like if you are not a manager at 53 there must be something wrong with you? That’s what people keep telling me to watch out for.
- bigfishrunning 10mo agoNot everyone wants to be a manager -- effective management and effective engineering are two very different and rarely overlapping skill sets. It honestly seems strange to me that transitioning into management is such a common career path for engineers.
- Aeolun 10mo agoOh, I wasn’t trying to imply you should. I don’t want to. I’m perfectly happy as a principal. But people tell me I can’t keep doing that for the next 20 years and expect to keep my job.
- pmarreck 10mo agoI was last a Director of Engineering at a startup. Everyone I hired is still there. I'm fine with passing the baton, I enjoy mentoring.
- anyonecancode 10mo agoOver my career, I've been in a big company twice. This article definitely tracks with my experience. At one company, I think management actively didn't care, and in fact my direct manager was pretty hostile to any attempts at improving our code base as it meant disruption to what was, for him, a stable little niche he had set up. At the second, it wasn't hostility but more indifference -- yes, in theory they'd like higher quality code, but none of the systems to make this possible were set up. My team was all brand new to the company, except for two folks who'd been at the company for several years but in a completely different domain , with a manger from yet another domain. The "relative beginner" aspect he calls out was in full effect.
- elisbce 10mo ago1. In Silicon Valley, people are not bounded by non-compete clauses and can come and go at will. So fungibility is a top priority for any tech company. The only way to do that is to make sure expertise is shared across the team and not monopolized by one or a few old-timers. 2. Eng teams that have mostly old-timers tend to get stale and slow in changes. This is bad for products that need rapid evolution or new ideas to break status quo. New engineers have way more incentives to make changes to prove themselves and collect credits, while old-timers tend to play safe and stay on the side of stability. 3. Bad coders, not new coders, write bad code.
- pkrecker 10mo agoThis article repeats the idea that the tenure of SWEs at large tech companies is only 1-2 years, but I don't think this is true, and certainly not at the lower bound of one year. I am not sure about other companies but at Google, where I work, the average tenure of a SWE is over 5 years.
- 0xbadcafebee 10mo agoI've been at big companies for 12 out of the last 20 years, never a FAANG, just "average" big companies. The rest of the time I've spent at startups and medium-sized companies, and sometimes a startup-in-a-big-company. I have met maybe 5 good engineers in my whole career. The size of the company did not matter. The reason is, the only thing that exists in our world today that can make you a good tech engineer, is yourself. When you hear the word "engineer", you might imagine a professional who has done studies, passed exams, has certificates, maybe even apprenticed. They know a specific body of knowledge (which is maintained by some organization), they're held liable for their work. They are masters of their domain and they don't step outside of it. But not if they're in tech! Then an 'engineer' can be a high school graduate or a PhD. Both can make the same amount of money, and have the same lack of real-world experience and job skills. They will both regularly apply technology they've never been trained on, never learning more than the least possible information to get a proof of concept working (and then that immediately becomes a production service). There's often no record of the decisions they made, no formal design process, no architectural review, no standards listed, no testing required, no risk analysis performed, no security/safety/reliability checklist performed. And they often are dealing directly with PII, with absolutely no thought to how to manage it. And they often have far more access than they should have, leak critical credentials everywhere, don't manage the software supply chain properly, don't even pin versions or even test rollbacks, etc. I have seen all of this at every single company I've worked for. In any other 'engineering' profession, this would be illegal. Hell, it's sometimes illegal just to change a breaker in a subpanel in your home without pulling a permit, because doing it wrong has consequences. Think of all the times your personal financial records, health records, sensitive data, social security numbers, etc, have been leaked, just in the last year or two. 9 times out of 10 those happened because nobody cared enough to prevent it. But these things shouldn't be optional. There should be some kind of mandatory thing in place to force people to ensure this doesn't happen. And some kind of mandatory minimum requirements about what people know, what they're allowed to work with, and how. None of that applies in tech, yet we still call it engineering.
- jeffbee 10mo agoThere's quite a bit of cope involved in this discussion, right? As in "I didn't get hired but at least I, a noble artisan, am not compromising my beautiful style"?
- bmitch3020 10mo agoI'd simplify this post down to this: companies optimize the trade-off between time, cost, and quality by sacrificing quality. It's not that the goal is to write low quality code, it's that big businesses understand the sales cycle and how to maximize profits. If they over spend on employees, that cuts into their profits or causes the product to be too expensive. And if they spend the time to write quality code rather than developing features, they lose sales. Customers don't buy quality, they buy features at a price, and quality issues (like bugs) get thrown over the wall to downstream support staff. As much as I dislike this, knowing how unstable it makes the overall software ecosystem, companies aren't wrong for making these decisions. The companies that choose differently don't become big businesses, they either stay small, get acquired, or go out of business.
- otikik 10mo agoBad quality eventually piles up higher enough so that it starts affecting shipping features, though. Then those companies stay small, get acquired, or go out of business.
- ianbutler 10mo agoI don't think there's an objective assessment of good code. I've been writing code for over 20 years at this point and most times I've seen what people describe as their own good code I disagree with various decisions. Experience CAN remove pitfalls, though developers even disagree about those sometimes. Organization, chosen abstractions, naming etc are basically personal thinking and have differed on every team I've ever been on. When it's been good is when it's been consistent and that's taken a strong personality the team trusted to have authority.
- foobarian 10mo agoI used to obsess about code, but over time I came to dread coming into a new codebase and finding layers upon layers of pointless mini-architecture. There would be a controller calling into a separate package where the actual implementation is, then that would call into a layer where service calls are, then all that would be abstracted just in case and built into a separate jar, and so on. And there would still be cross-dependencies. I think what happens there is a kind of purity spiral effect and developers have to go through the motions of following the best practices du jour instead of just calling the damn method.
- ianbutler 10mo agoI feel like its just a reflection of people's minds. People organize their thoughts very different from one another and people often don't organize their thoughts at all when under certain constraints such as needing to ship NOW. Especially with enterprise code you're hammering your thoughts into a shape roughly compatible with someone else's so its no wonder overtime with the constant revolving door of people that without careful shaping things can get nuts.
- jiggawatts 10mo agoGood code is subjective, especially once you start wandering into the territory of more esoteric approaches such as functional programming, domain-specific languages, code-generation, etc. Bad code is one of those things that we can almost all agree on, often even the person writing it. Alternatively: I don't know how to make a good movie, but I can recognise a really bad one, and you'll almost certainly agree with that opinion. You and I however will almost certainly not agree on what our favourite movie of all time is. The nuances and personal tastes become more important at the last few percentage points approaching 100% "like".
- nrhrjrjrjtntbt 10mo agoAnother reason for short tenure is to get uplevelled more quickly than is possible internally. I.e. it is easy to get to level X as a candidate than via promotion.
- cadamsdotcom 10mo agoThere’s a cost-benefit component missing from the analysis. “Bad” code is probably “good enough for now” code that was written some time ago on a bet that doing it better would never be needed as it wouldn’t need to change. Also, “good” code is costly especially if taking longer to build the thing causes the company to miss its market.
- jeltz 10mo agoIn my experience a lot of bad was bad even when it was written. And that writing good code is often cheaper (within reason, perfection is bad) over any project bigger than a couple of months. The payoff from having good code shows up very quickly.
- pdimitar 10mo agoBad code is not written on a bet. It's written because either competent engineers crunch, or because they are incompetent. Good code could be costly, yes, but often is not. In fact it's very often economically sound to periodically address tech debt i.e. not allow it to accumulate because it seems to increase exponentially until one day a critical customer-acquisition-stakes feature cannot be shipped on time due to it. Only then do the executives wake up and even then 80% of the time they just blame the engineers and move on. They are never at fault, the angels. Finally, many companies are already on the market and are relatively OK economically. Let's be honest: most deadlines are entirely artificial and are just power moves by management; they are not mandated by critical business needs.
- ford 10mo agoAt the end of the day writing good code is rarely the "end" someone is shooting for. It's more research, more features, more experimentation, etc. Maybe hobby projects and library maintainers are the exceptions. In my experience, big companies have the biggest incentive to write good code. They have the highest conviction in their bets, and they know with high confidence they will be around in 10 years. One large tech company I worked at had a rule of thumb that all code would need to be maintained for ~7 years - at which point, as the author points out, the entire team may have been replaced. This is precisely when the time it takes to write good code is a worthy investment
- JohnMakin 10mo agoI don’t mind bad code, I know why it happens and a lot of good points are made here in the comments. What I cannot stand and can barely tolerate is kruft and sloppiness. massive sections of commented out functions, leaving the poor guy to come along 2 years later wondering if it was important or why it was left there. Unused functions. bad, inconsistent, or nonexistent naming conventions. Terrible or annoying file/project structure. None of this stuff has to be. Not doing this stuff requires a bare minimum of effort and time and doesn’t require any familiarity with a codebase. It’s a lack of professional pride, and that deeply annoys me when I inevitably have to clean it up because it’s an unreadable mess.
- khana 10mo ago[dead]
- sophia01 10mo agoThe matter of fact is that big companies (think the usual monorepo business going on in FAANG) don't care about the actual code. The code was never the point of the exercise. Eventually you realize this. Code is like the ether. The company needs it in order to do its thing, and the code needs to be dealt with in order to operate. In the end it doesn't matter how normalized and pretty you design the database, someone will eventually show up and write a pipeline that dumps every row of it into JSON once an hour and ships it to some far away corner of the company. Someone will write a shitty script to deal with the fact that those rows don't represent a consistent point-in-time snapshot of your database. In the end it doesn't matter anyway, it'll all be rewritten or coerced through some migration into some ugly system in a few months anyway that it doesn't conform to and could never match. The thing that matters is the process. When you decide you want to do it, do you have the process to mend the ether to do what you need it to do in two months? Do you have the processes in place to catch it when it's so catastrophic it's blowing up your balance sheet?
- dawnerd 10mo agoTight deadlines and poor scoping. At least from my experience. When corners need to be cut, code quality goes out the window.
- thrwaway55 10mo agoThis hints at the authors misunderstanding. Customers don't care about good code. As an expert you are paid to cut corners intelligently. Customers want cheap and good enough.
- gorfian_robot 10mo agowhen hiring is rare, the mission important and life critical, and the amount of coders small there is an esprit de corps that can arise to create excellent code in the largest organizations. unfortunately it also fails to arise.
- gverrilla 10mo agowork vs capital
- wrxd 10mo agoI 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”
- icsa 10mo agoAnecdote: 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.
- alliao 10mo agocome on man, give us a clue tell me at least it won't kill anyone
- jeltz 10mo agoSeems like a pretty easy thing to clean up. I am confused by these devs who just seem to give up. Just fix it!
- icsa 10mo agoNo one had the motivation to fix it, including management. Many of the developers saw the problem as job security.
- alliao 10mo agoit'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.
- pdimitar 10mo agoCan you expand further on that, and maybe send some sources? Interested to learn more about this.
- alliao 10mo agojust what i was taught when i took a management 101 class in my university years.. it was one of my elective papers outside of my core curriculum quite enlightening and helped me manage my managers...
- solatic 10mo agoAuthor'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.
- yvdriess 10mo agoYou don't need a second screen to do your job, denied. - your people manager that has to sign off on purchases
- Cthulhu_ 10mo agoIn my limited experience (enterprises like energy companies is the biggest tech areas I've worked in, code order of magnitude <1M LOC, at best a few hundred engineers), as a senior developer the best thing you can do is create a culture, good examples, and automated checks and balances. Linters and code formatters, procedures, good examples (because in that kind of world most code is copy/pasted from something similar and adjusted), and nowadays, AI prompt documents that give these tools hints to what code should be used as an example. But even then, given time and number of people, bit rot and a slow downwards spiral feels inevitable. Which is why in those industries they will often do a rewrite every 5-10 years, especially in front-end. Often a redesign / rebranding (also every 10 odd years) will be used as an excuse to rebuild software entirely.
- picafrost 10mo agoEvery industry building at scale makes the same tradeoffs. Manufacturers that create physical products use thinner metal, cheaper fasteners, and not-top-quality plastics. That's not because their engineers are bad but because good enough ships and is profitable, while perfect doesn't ship and isn't profitable. A $20 IKEA chair is not "bad furniture". It's just optimized for different constraints than a Herman Miller. Most consumers are totally happy with the $20 IKEA chair. An underrated part of engineering skill is knowing what corners to cut. I think large tech companies have structures that impose this on engineers who view this as dereliction of duty.
- everdrive 10mo agoBig companies seem to demand you do things poorly. They make some insane internal requirement, and assume that if you disagree you're showboating or being a nerd, or something else. When really, you're only disagreeing because it's clear their idea is flawed. You're sticking your neck out to help the company; it would have been easier just to go along with everyone.
- jeltz 10mo agoYeah, I have seen that happen many times. When some engineer tells management that fixing the issue for real is faster than fixing it ugly they are never believed even though that is a not uncommon thing.
- thomascountz 10mo agoI do rather think it takes good engineers to successfully build around the real constraints imposed by large companies—which optimize their products around a set of business metrics. At the end of the day, engineering is all about building around constraints; bridges aren't built in thin air with idealized traffic patterns, atomically perfect metallurgy, and with unlimited budgets. Yes, bridges aren't software services, but nevertheless the things we humans build are rarely pure or serve a singular purpose.
- emacsahmed 10mo ago[dead]
- aniou 10mo agoA note from someone who specializes in long-term system maintenance: There is also one, very important aspect, that is - (un)suprisingly - rarely mentioned in comments: a lack of dependence between sloppy work and personal comfort of particular person, responsible for problematic changes. What I mean? A badly installed or configured system would be a problem in next three, maybe five years: to time of major OS upgrade, HW replacement or refresh, framework deprecation and so, and so... In current, corporate culture, there is almost impossible to being bite by own laziness - almost no one is working in particular company or for particular project so long. Especially, when installation is conducted by external party in model "grab the money and run!" So, very basic motivation for good work, that comes from awareness, that today technological debt would lead to personal, painful experience in future, doesn't exists at all in modern, corporate environment. The things are even worse - there are multiple relations about negative career consequences resulting from concern for the quality of work: "because we want that product fast a we don't like troublemakers and defensive thinkers". In consequence, one cannot throw a rock without hitting a dozens of such a cases, like that one: https://discourse.ubuntu.com/t/release-26-04-lts-without-the-iso-tracker/69577 https://discourse.ubuntu.com/t/release-26-04-lts-without-the...
- Ygg2 10mo agoGreat article. I quite appreciate this one and the Pure/Impure engineers.
- ncgl 10mo agoI find myself agreeing with everything. I hear "thats something we can fix/improve/iterate on" when I'm criticizing code at ny company. My retort is "why aren't we getting it right the first time?"
- ClayShentrup 10mo agooh man, as a veteran of cruise this hits hard. thinking back to all the astonishingly dumb code I tried to refactor to do the right thing, and just get no recognition for it. politics > proficiency
- ralphc 10mo agoI worked at a perfectly reasonable company that was acquired by Oracle. This was in the 2000s. We were working on a big Java project and were using ADF, the "Oracle Application Developer Framework". It was a piece of crap. One time I asked my manager why we were using it and he said that the project would probably fail and if we used something else the higher ups would blame it on not using ADF and fire him, so...
- nacozarina 10mo agosoftware-by-committee never works
- miljanm 10mo agoit all comes down to being responsible (and/or accountable) for some process for which you have no power and control over. hence burnout. relinquish good code and save yourself.
- saw7777 10mo ago[dead]
- tom_m 10mo agoYes because having a deadline means you aren't set up for quality code...and codebases that are years old are no good. Of course. Sounds like a flavor of the month JavaScript developer. Or the mentality anyway. I know nothing of the author so I don't want to generalize or assume and I definitely agree with a lot of what they are saying. Some very sharp observations. But companies can't be expected to toss out entire codebases every two years. A lot of what's mentioned is also true at smaller companies. I see the same exact thing at startups. Now imagine you don't have any programmers who were around for some of the code. No one to ask why or where in the code. You got 3 or 4 types of programmers that attribute to things in my opinion. At companies big or small. 1. Those who can read through the code and figure things out (or now use the help of AI to do the reading and hunting). These are your A players. 2. Those who try and are cautious but ultimately get tripped up and make mistakes. These are your B players, assuming they can be coached. The next two types are the EXACT people who end up writing bad code that ends up sticking around for someone in the future. Note that #2 here can write "bad code" but they'll stay around to fix it and will learn and grow (with proper management and support). 3. Those who think they know what they're doing and either move too slow or create bugs. These can be very senior engineers. They're C players, they don't make the cut for long. 4. Those who think they know it all and are very comfortable with changing large areas of code. Who maybe don't tell you they are going to do so (scope creep, inventing problems that didn't exist, determining priorities on their own, etc.). They ship bugs to production and maybe they do go and fix them, great, but sometimes you find people who don't and leave it to others to handle because it's beneath them or something. These people, and they may have decades of experience, are D and F players who need to go asap. You might see people in group 3 and 4 as "good" or "experienced" because they sound good, interview well, and may indeed know how to write good code - they just don't write good code with others or with an existing code base or just in general because they don't actually WANT to. They don't care. This brings not only bad code into any company, big or small, it also brings toxicity in. It makes other programmers leave. For example, those that the author talks about as being around longer with limited time. Those people get burned out exactly like the article alludes to. The reason is because of people like 3 and 4. So I guess that is to say I agree with much of the article, but it's for companies of all sizes and it's not because of deadlines or stock options. It's because that average programmer only sticks around 1-2 years. That's the problem. No one has any commitment. Lots of ego and no team players. That's a lot of what I see unfortunately.
- ethan0456 10mo agoThis post highlights a deeper reason many people choose engineering: they want to build good things. Engineers who care about the craft get bothered by bad code. But management optimises for profit and speed. When engineers are treated as a commodity, control ends up with management, and they use it to push for delivery over long term quality. Engineers who think more like managers are not “impure engineers.” They just understand the trade off between cleaning up bad code and getting a project across the finish line.