I've read a few of this guys posts now and have consistently been rubbed the wrong way by them. I think I know why now. It's not that he's wrong. His analysis is reasonable and straightforward. I think it's that the basis for his analysis is ultimately a form of nihilism, coming from someone who (maybe?) used to be an idealist but was burnt by a bad experience and must now explain why believing in anything is 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.
Because I’m being held accountable for the bad results of the bad code. Because I’m being held to task to fix the problems caused by the bad code on a schedule that I didn’t agree with. Because management is using someone else’s bad code to deny me a positive annual review.
“You’re a senior engineer - why did fixing this take so long?” Because of the garbage I had to wade through to even find the problem. Because I wasn’t yet working here when this was written and I have to take time to get my head around the insanity.
Yes, these are management problems. I’ve spent years managing managers and attempting to educate them on how bad code causes errors and delays. But for many reasons, it’s a Sysiphean task.
I don't think it's that. It bothers me a lot too, and not because anyone else is judging me or anything. I think it's just that it's depressing... it sucks to be doing bad work, on top of other bad work, and unable to do good work instead. It is incredibly frustrating to care about quality but be surrounded by and constrained to work on crap. Just feels like everything went horribly wrong somewhere and you're powerless to do anything about it and your only option is to suck it up.
I know how to fix this but I'm not "allowed to" can eat away at you easily. Then there are things that I know how I might fix but I wouldn't realistically be able to because it's all a lot to take on, there will almost never be enough time and hands to get it done, within the set constraints.
This is due to the way how incentives are aligned. Systems that are powering things for, say a decade at least but worked on Quarterly basis.
Why is this alive and well, then? Because it doesn't actually matter as long as money keeps rolling in. It is also possible that the losses caused by or efficiency not achieved do not show up in the accounts.
>I know how to fix this but I'm not "allowed to" can eat away at you easily.
This really is the worst, and that's why I left my first job. Funnily enough, I just took that job back after a few years but I am now the lead and sole developer on it, I'm having the time of my life doing what I've always wanted to do back then, and seeing the product now flourish.
The bad code didn't really matter, it was the fact that I was not allowed to improve it and forced to build new features on top of crappy code that made me quit in the first place.
> “You’re a senior engineer - why did fixing this take so long?”
exactly!
If a senior engineer is responsible for the problem, but he wasn't given room to develop a proper solution in the first place, then he cannot be blamed for the outcome. And yet, this is exactly what happens.
If a system had been made well, and functions well, same senior engineer does not get the credit for not causing problems!
This is what happens when management/stakeholders don't understand what is going on, but have an expectation that is not well communicated to the engineers (and also inversely too, where engineers are not communicating the situation properly to management - or they refuse to hear it/ignore it).
> “You’re a senior engineer - why did fixing this take so long?” Because of the garbage I had to wade through to even find the problem. Because I wasn’t yet working here when this was written and I have to take time to get my head around the insanity.
The arguably unproductive part of my brain craves to reach a day where I can say literally everything straight - if this would be a true description of the circumstances, then say exactly that.
Unfortunately, in addition to not only not being a “team player” this would also be really mean to people that had different time and resource pressures when they wrote the original flawed implementation. So both burning bridges and being kind of a dick.
At the same time, there’s sometimes people that develop stuff in such a way that I will never agree with them and a few people like that are enough for me not to want at a particular team/org even if it’s maybe like just 5 to 10% (and even then often it’s about them being inherently mean/nitpicky/whatever, rather than purely technical stuff).
Obviously the irony of the above isn’t lost on me so I just bite my tongue, focus on being professional and fixing the things I can and let the rest be without picking fights that will lead nowhere - otherwise I’d be a hypocrite and the situation couldn’t be described as anything other than “a bad culture fit” from an outside perspective.
But I’ve seen a lot of really shit code and it baffles me that alarm bells don’t go off more often and people just trudge along.
Then again, you do see a lot of drama in plenty of open source projects, so maybe that’s just human nature.
I agree it's often difficult, but I think it's possible to balance honesty with humility and being a so-called team player.
For example, if you see something that's sloppy [1], your honest assessment will likely help both the coder and the manager. But you do have to temper your language, and sandwich the criticism in something that won't make the person interpret it as "you're sloppy/stupid" or "you don't deserve to work here".
The additional problem is: you have to test it with baby steps. If a coder/manager can't take any feedback [2], not even the friendliest suggestion, you have to pick whether to (1) slowly train each other to communicate better, or (2) leave (it alone).
But ultimately (IMO), it's not worth training yourself to be less honest or dishonest. You risk losing the ability to do your best among other smart, honest and feedback-accepting people, or being an honest and feedback-accepting manager/employer yourself [3].
[1] Like many blocks of copy-pasted code, or massive scripts with no separation of concerns, which can really grind my gears.
[2] I've personally had a few discussions with peers and leads in teams who would get defensive, or interpret my feedback as politicking, even in a cooperative environment, and I didn't love that. But I also didn't love getting (what seemed as) "holier than thou" evals in (what I saw as) more competitive environments. So, maybe my cooperative is another's competitive, and vice versa.
[3] Because you can easily get used to a skewed or toxic environment, and accidentally spread that toxicity to others, or unintentionally be seen as toxic yourself.
> your honest assessment will likely help both the coder and the manager
While I'd like this to be always true, there will be cultures and even individual egos for which this will never be true.
Someone who's considered a senior dev in the org might dislike your assessment (regardless of what external resources and industry practices and any number of people's experiences say) and might turn your suggestions for how to make their code a bit better into a bikeshedding argument until either one of you tires out and gives up (no relation to which opinion is even right or what's best) or the manager gets pissed off at the both of you and has to intervene (not necessarily thinking badly of you) and the traditional methods like "pulling rank" wouldn't work either if it's a senior engineer. Even if you do everything right in how you approach it and frame it positively and everything else.
In part, this might be because there's no one set of guidelines for "this is what good code looks like", especially because of how fast moving and disjointed and underregulated the whole craft is (might settle down in a century idk). It might also be because that mess leads to vastly different opinions on what's good (e.g. how some people take SOLID/DRY as gospel, others don't, to the point where WET is a thing). And some people just don't care and don't see things the way you do.
Concrete example: once saw a bit of code that had nested service calls. Suggested to the person that this will lead to the N+1 problem in database interaction. They said that it's okay because the other code is written like that in the app already and that this code is easier to reason about. A month later I had to actually show them cache hit/miss statistics after implementing caching as a band-aid on top of the nested code because there were deadlines and nobody could rewrite the whole thing as a DB view. In that particular case, there wasn't even mean exchanges or whatever, just endless bikeshedding about whether something is needed or not that lead nowhere, even when graphs and data were presented by me.
Same for opinions on how much logging or code comments should there be, stuff like dynamic SQL generation vs DB views and a bunch of more nebulous things, though often with a quality of life impact instead of something so concrete as above, where pages started taking 20-30 seconds to load once the DB was properly populated with a lot of data.
So yeah, absolutely do your best effort and try to orient yourself towards open minded egoless developers in a cooperative environment. But sometimes that's not what life will give you and you might just realize "hey, naah, person X is the problem 100% here but it might be possible that I cannot do anything about it in this environment". I've also been person X, of course, but in general I think more honesty would be good.
Like figuring out why our national e-health project failed so badly as it did and putting the people responsible for the failure in jail after a proper root cause analysis is done, if they didn't seek proper remedies in an adequate amount of time: https://www-lsm-lv.translate.goog/raksts/zinas/latvija/09.04...
Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it.
I got into this career because I like mucking about with this kind of work. Programming is sort of like building thought sculptures. Ok, maintaining them too. I spend a lot of my adult life working with these systems, so of course I care about their quality.
It is unpleasant to work on a hack-filled creaking monstrosity of a codebase. My skills, such as they are, don't help as much as it feels they should, because I rely heavily on understanding a system based on how it sort of has to work given what I know about the constraints, and hacky systems constantly confound my expectations. That means I have to spend way too much time and effort learning the idiosyncrasies and unpredictable corner cases, and so have less time to make the changes I want to make. It's like a carpenter working on a house where nothing is straight, nothing is level. Or a cook given flavorless or half-rotten ingredients to use. You spend more time picking out the bad (or picking out the good and discarding the rest) than actually cooking.
Any my scope is limited. Some changes are just not feasible to make, because there are too many hidden and/or unnecessary dependencies buried in the code. If you change one thing, everything falls apart. If you patch it together well enough to more or less work, you're faced with a long tail of subtle bugs that you'll be battling for a long time to come. There's no conceptual integrity.
Furthermore, working with a team that accepts a never-ending accumulation of creeping technical debt is also unpleasant. You can't trust that a positive review means anything. If you try to do something right and take pride in your work, your teammates will be resentful that you're not closing your bugs fast enough. Who cares that it means less maintenance overhead in the future if nobody's planning on sticking around, or people are depending on things being constantly broken so that they can spend their days knocking off relatively easy whack-a-mole style bugs?
Bad code is actually fine. It happens. But I want to know why the code is bad, whether the reasons are defensible or not. If they aren't, I know that the codebase is going to be littered with similar crap, and that my job is going to suck. That's what bothers me so much. This is true even if I'm the author of the bad code. Why didn't the reviewer point it out? Is it like the article said, and there's nobody competent enough to spot glaring issues? That is also a component of a job that sucks.
> Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it.
Well, I don't know that we can separate external forces from why people might dislike bad code... being held to a standard that is unachievable because of someone else's mess and someone else's expectations is all too common in life, and the reality is that your livelihood might depend on meeting those expectations. If you like programming, you might also like maintaining or refactoring code; it goes with the territory, and it can be fun to see how something can be improved or challenge yourself to see how far you can improve it. But it tends to be less enjoyable when your ability to eat and house yourself rides on someone else's bad code.
> If you try to do something right and take pride in your work, your teammates will be resentful that you're not closing your bugs fast enough.
Right, but why would they resent that? Probably because management has expectations on the team, and they are concerned that you're sandbagging the metrics. It ends up being a management or cultural problem regardless.
> Bad code is actually fine. It happens. But I want to know why the code is bad, whether the reasons are defensible or not.
> Well, I don't know that we can separate external forces from why people might dislike bad code...
I'm not denying the validity of the reasons stemming from external forces. I'm just enumerating a bunch of additional reasons why developers might have a problem with bad code.
>> If you try to do something right and take pride in your work, your teammates will be resentful that you're not closing your bugs fast enough.
> Right, but why would they resent that? Probably because management has expectations on the team, and they are concerned that you're sandbagging the metrics. It ends up being a management or cultural problem regardless.
Heh. That's definitely a valid and common reason for resentment, but again I think the resentment can arise from more internal reasons as well. Even the craft coders recognize that you can't polish forever, and if one person spends 90% of their time polishing, then effectively that requires the others to pick up the feature work slack. That person is leaning on the rest of the team. It might be sometimes the right thing to do, but if it's a perennial pattern then even a team with 100% anal-retentive craft coders is going to get annoyed. Possibly because it cuts into their polish time, so they end up shipping worse code than they'd like.
But then, I'm not sure we're even disagreeing. The above could be labeled as "cultural". I think of the internal/external distinction as one where it's internal to the team vs imposed by management.
sandbagging or messing with metrics is an inevitable part of playing a role in $BIGTECHCO. Even if people don’t admit it or aren’t aware of it, it happens everywhere. If anyone resents it they just resent you’re doing it better than they could. much of what we do is all a political game. I’ve had situations where I cannot do something that clearly needs to be done, I in the past will find reasons to slow things down and point to (thing that needs to be done) as the reason why. Eventually the manager above you will prioritize it or discipline you. If you’re right and are valuable and your manager isn’t stupid, you’ll get your way, and they can take credit for the sudden velocity gain. I’ve also done the opposite in speeding things up to expose brittle unsustainable processes.
Not endorsing it, but, it just seems to me the way most performance management works at these companies (I came from a company that liked to think it was amazon with stack ranking) you have to do it or you will get shanked inevitably before you vest. This is just my personal experience. TLDR it’s how you make things “happen”
It’s very cynical. Thankfully these days I work on much smaller teams where everyone helps as much as they can because you’re constantly treading water, but there’s very little room for this kind of political maneuvering and bs.
> Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it.
From the perspective of the organization that pays you to do it, it is? At best there may be another mission that it genuinely cares about, usually there’s only a profit motive (which is also fine). If you want to create software as an end in itself or enjoy the craft without compromise, it usually can’t be in the context of a job or a business
Our job is to produce the best possible outcomes given the constraints we’re faced with, and inform leadership so that they’re aware of the tradeoffs when they make their decisions. Sometimes those decisions are going to be bad, and obviously it’s justified to be frustrated then. Other times they are correct, even when it means compromises on the engineering side. That’s when we have to just suck it up (or go elsewhere)
I still think there’s room for enjoying the work of creating software even under imperfect conditions. Striving for perfection is for hobbies, or the very rare circumstance when it’s justified by the goals of the organization
> From the perspective of the organization that pays you to do it, it is?
I agree. I'm just saying that if you limit yourself to explanations from that perspective, you will miss some of the explanations and be unable to describe real-world phenomena.
> If you want to create software as an end in itself or enjoy the craft without compromise, it usually can’t be in the context of a job or a business
Sure, but that's an extreme position. Maximizing the "ship features that make money" end of the balance doesn't end well in the long term. Maximimizing "all code must be perfect" also doesn't end well. There is very much a place for an appropriate amount of craftsmanship, and businesses do better and even make more money in the long run if that isn't choked out. ("Appropriate" varies widely by situation.)
I'm currently leading a team in a group of teams responsible for a terrible code base. It's riddled with tech debt, our DB is maintained by others and has absolutely atrocious performance, it often feels like I'm the only one who cares about all our tech debt, typescript errors, linting errors and browser warnings, and I worry that the reason I'm the only one is that I'm the most recent hire. I still care.
I'm now spending my weekend thinking about a problem where a really urgent feature I wrote doesn't work because the query behind it is too heavy for the database (the query isn't anything special, but it's against a view that clearly isn't properly indexed), and the DB people are complaining I'm overloading the DB. But it's going to be shown to the regulator for some important regulatory rule for which noncompliance is costing us tens of millions per year. Next Tuesday. Which they told me last Tuesday.
How am I supposed to write good code in that kind of environment?
There’s another side to this I see - and have been guilty of committing - where “it took so long because I found some code that felt wrong and while trying to fix that I found something else that felt wrong and while trying to fix that…” at some point you just have to settle for making one thing better and then getting the job done while leaving some other ugliness still in place.
The complaints in this thread seem to ignore cases like that and I’m not getting the sense that it’s because everyone is spectacular at avoiding rabbit holes.
Agree. I get accountability for code I had no control over. That's a setup.
"You’re a senior engineer - why did fixing this take so long?” This is also maddening: it's not a question arising from technical indight or a management strategy ala Drucker, ishikawa, or any other serious approach. It's a guilt trip: it's like saying why did you dress so bad at this party? It's manipulative. And nobody likes these smeer tactics.
have you ever worked with pivotal Labs? One of my biggest faults I guess is that I worked with femme and they have such an incredibly high bar for understanding, design patterns and cyclomatic complexity and solid and test driven development principles and so forth that once you've worked with them, anywhere else you go is going to feel like a dumpster fire. so then you'll just pull your hair out thinking everyone's an idiot, even if it's really just a lot of bad incentives.
Others have said some true things but the core is missed. It bothers engineers who care about mastery. It’s the same for architects who see design flaws in buildings that were done by those who don’t care about mastery. Or a filmmaker who watches a movie with lots of flaws. Caring about obtaining mastery means having the capability of seeing the flaws and resolving them.
It could be maturity to resign to powerless forces or it could be the inability to obtain that mastery or the willingness to let go of that mastery. I would think it’s more mature to fight the good fight, but at some point you just get old and tired I imagine. And it’s interesting to posit the author is nihilistic when this “uncontrollable forces” itself is a nihilistic take imho.
I don't think that's entirely true. Seeking mastery does not imply being a master.
If you have only ever seen one pattern to solve a problem, trivial example of inheritance, and therefore do that to the best of your ability then you have achieved mastery to your ability. Once you see a different pattern, composition, you can then master that and master identifying when which is suitable.
Lack of mastery is just using inheritance despite seeing alternative patterns.
Naturally mastery also includes seeking alternative solutions but just because a codebase uses inferior patterns does not mean those that came before did not strive towards mastery, it's possible that they didn't know better at the time and now cannot get the time to revise the work.
There's always a juggling act in the real world.
Assume incompetence and not malice, and incompetence is not a state of being. A person without experience can be seen as incompetent but quickly become competent with training or experience, but the code they write still stems from incompetence.
Strive to see your previous self as incompetent (learn something new every day)
7 out of 4 million active SWEs sounds about right :) how many codebases have you personally seen and went "holy shit, this is masterful/flawless/..."? even just libraries as codebases is most definitely 0...? our industry is basically few solid competent people followed by an ocean of mediocrity and incompetence... always been that way and always will be the way
I don't think it's possible to write a flawless codebase. That doesn't mean SWEs don't seek mastery of their craft. Moreover, achieving mastery doesn't mean you would actually want to write an 'ideal codebase', that seems like an art project disconnected from the purpose of the craft.
“mastery of the craft” is a myth… whatever codebase you see (and I’ve seen more than I can count) you will go “wtf is this?!” over and over again. furthermore, whatever codebase someone was lucky enough to initially start with, after X amount of time you asked those same masters (if they are still around) and they will inevitably tell you “oh boy, if I can start this over, I would have…” there just is no mastery, there are just people that deeply care about what they are building and try their best not to F it up along the way but all the “craft” and “mastery” talk is just empty words people talk around fireplaces and/or at various conferences where people pitching “craft” and “mastery” and “you need [insert dev process du jour XP/agile/…]” are there to make money selling the bullshit
I think you are conflating mastery with some kind of beautiful codebase that is completely obvious to everyone else. Einstein had mastery over physics and yet his ideas required a lot of studying to understand and explore.
Engineering is the intersection of science and economics. You build the thing as best you can with the knowledge you have and you often discover things you didn’t even know once you start building. Combine that with time and resource limitations, and you have to make reasonable short cuts to deliver things.
Also remember that even if there’s one master on a codebase, organizations often pair them with many non-masters to try to accelerate things. What that looks like then is a mish mash of things that don’t make sense because the master is struggling to maintain a coherent vision that other people are executing; it’s hard to develop consistency even when there’s just one person let alone a broader team.
But your benchmark is fine if one master can show another master a codebase and explain why the pieces are there and which pieces are shortcuts and what the vision is. Trying to develop that knowledge by yourself in the middle of the dev cycle is a fools errand; one of the first things I do when I come to a codebase is ask a bunch of questions to build up my understanding of the history of the codebase and why things were done a specific way.
I agree with literally every word you wrote. But what is this “mastery” or “craft” then? if we agree (rightfully so) that some special people exist, eventually (or immediately) other people get involved, we as industry accept “we had a deadline so it was cool to ‘cut corners’ etc…” - where is mastery or craft in this process?
I have and I am sure you have worked with some amazing people over the years but to me our entire industry is so far removed from anything resembling mastery or craft that even mentioning it at this point in my life makes me chuckle (and at times literally laugh out loud)
I think people have a very weird notion of mastery and think it looks very different in other fields. That’s because mastery no longer looks like mastery once you attain it. Mastery also doesn’t look like the absence of imperfections - even art house films by master auteurs will have imperfections the masters will see and compromises they had to make to get a film done. Talk to a master builder and they’ll instantly start pointing out flaws in buildings. Electrical grids regularly see outages despite.
So my question then is how would you define mastery if you believe our industry doesn’t practice it.
I’m shocked to hear how different your experience is from mine. I very often see good code and bad code and the difference is very clear, even years into a project.
> Why is it necessary for big tech companies to act this way?
This question gets directly at the cause of the author's nihilism: the necessity is borne from the endless pursuit of positive quarterly growth, the "binding fiduciary duty to shareholders". Which is a lie, there is no such legally binding fiduciary duty. So the aforementioned necessity is also a lie. Companies could operate on a longer time horizon, let engineers write better code, make better products, maybe even consider societal good in their strategic planning, and still turn a healthy profit. But the cost of perhaps taking a few degrees off their YoY trend line is unacceptable to the insatiable greed of their controlling shareholders.
Interesting. Coming from big tech, it's actually pretty spot-on of an article. I think most folks at big tech have experienced this stuff too.
> Why is it necessary for big tech companies to act this way? Why does bad code bother engineers so much? Are they actually misguided for feeling like bad code is a catastrophe, or is it really the fault of the broader economic sphere we all inhabit? Is it actually maturity to 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.
I don't disagree that it's an accurate portrayal of reality. And of course, as I made clear in my post, I don't know if they're actually a burnt out nihilist.
My issue with the article is maybe more that the perspective and framing seem to want to lock out idealism from the conversation and encourage people to become ruthless, hard-nosed pragmatists in order to survive in this environment. Is that actually good, effective, or desirable? Again, lots of questions.
My feeling when I found this blog was "so I'm NOT the only one!". It's the painful truth about staff+ engineering that I've also experienced, but haven't felt safe to talk about.
You're not wrong that there's something cynical or nihilistic about it. The core thesis is "do what the company wants, even if it's not what they should want". That idea may be unpalatable, but getting ground up in the corporate gears is worse.
My personal feeling is that there's a way to both agree with the underlying issues Sean writes about while being more optimistic and providing better alternatives. Something I feel I should start writing about more.
I think one of the issues is that engineers define bad code on a different set of dimensions than the business, and even amongst each other. Early in my career I was definitely guilty of this, that if the code didn’t fit my definition of perfect code, it must be bad. I’ve met great programmers (I don’t consider myself in this group) in my career who put even more strict criteria on something to be considered ‘not bad’. Then I worked at small companies, big companies, was an owner at one, and my definition of bad code narrowed. While my criteria are still subjective, if the code meets the business goals and a baseline of quality I consider it fine. Because outside of some absolute genius programmers like Carmack, few of us will look at someone else’s code and not think of any type of improvement.
I've come to quite a specific definition of "bad code", at least the main form of bad code that infests corporate environments. It's overly complicated code, but people disagree on what that means too, and I have a concrete definition of that now.
Bad, over-complicated code is code that requires you to form an unnecessarily detailed mental model of it in order to answer a particular question you may have about it.
People rarely read code in its entirety, like a novel. There is almost always a specific question they want to answer. It might be "how will it behave in this use case?", "how will this change affect its behaviour?" or "what change should I make it to achieve this new behaviour?". Alternatively, it might be something more high level, but still specific, like "how does this fit together?" (i.e. there's a desire to understand the overall organisational principles of the code, rather than a specific detail).
Bad code typically:
* Requires you to read and understand large volumes of what should be irrelevant code in order to answer your question, often across multiple codebases.
* Requires you to do difficult detective work in order to identify what code needs to be read and understood to answer the question with confidence.
* Only provides an answer to your question with caveats/assumptions about human behaviour, such as "well unless someone has done X somewhere, but I doubt anyone would do that and would have to read the entire codebase to be sure".
Of course, this doesn't yield some number as to how "complicated the code is" and it depends on the question you're asking. A codebase might be quite good on some questions and bad on others. It can be a very useful exercise to think about what questions people are likely to seek answers for from a given codebase.
When you think about things this way, you come to realise a lot of supposedly good practices actually pessimise code in this sense, often for the sake of "reusability" of things that will never be reused. Dependency injection containers are a bête noire of mine for this reason. There's nothing wrong with dependency injection itself (giving things their dependencies rather than having them create them), but DI containers tend to end up being dependency obfuscators, and the worst ones import a huge amount of quirky, often poorly-documented behaviour into your system. They are probably the single biggest cause of having to spend an entire afternoon trawling through code, often including that of the blasted container itself (and runtime config!), to answer what should be a very simple and quick question about a corporate codebase.
>People rarely read code in its entirety, like a novel. There is almost always a specific question they want to answer. It might be "how will it behave in this use case?", "how will this change affect its behaviour?" or "what change should I make it to achieve this new behaviour?". Alternatively, it might be something more high level, but still specific, like "how does this fit together?" (i.e. there's a desire to understand the overall organisational principles of the code, rather than a specific detail).
+1. For me the most frustrating one is "where is the core logic for this one user-visible feature actually implemented?"
You look in all the obvious places and it's just nowhere to be found. Or it's shredded into tiny pieces and scattered across multiple files and seventeen layers of inheritance ...
It's hard to write about the broader context with any expertise in a blog post written from personal experience.
My own thinking is that the big competitive advantage that big tech firms have over small ones is the power to mobilize very large numbers of developers onto a project.
Large projects that don't depend on a small core group of irreplaceable competent individuals are more repeatable for a business. So it makes sense to focus on making the repeatable processes more likely to succeed than simply hope that you happen to have the right team assembled for the job.
Assuming that any of your engineers are above or below average hurts the ability for the business to plan.
True but this isn’t something big tech innovated. This is exactly how most large organizations work. For example, and specifically in the military, servicemembers are fungible and they are rotated every 2 years. The military even encourages attrition at certain ranks and points in people’s career.
I think you are ascribing too much into this. If he does not believe anything then there will be nothing to write about. It looks like he does not believe in _your_ ideals - that does not make it nihilism though.
> 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.
Nihilism is a defense mechanism when everything is moving against your world view.
STEM people of all walks of life join because of the challenge, the loveliness of an elegant solution, and the “art” you create that leaves your mark. Good engineers view their code as a makers mark. This code represents me as my art and I should do my best. Unfortunately (or fortunately) this is beaten out of you by senior engineer and the shell left is a nihilist and misanthrope.
Corporate programming strips you of your creativity, your autonomy, and your drive. It’s simultaneously strict, but too loose where it should matter. It’s spastic in its execution. There is often little rhyme or reason aside from “build fast make money”. No one appreciates your contributions. You show up to meetings where sales and PMs simultaneously wrestle to take the credit you rightfully deserve. You made it 10 years, here’s another low budget pizza party while the sales team gets an all inclusive in Ibiza. You wanted to make cool, elegant, things, and instead you’re just a factory worker that had to do 7 rounds of interview for the privilege of stacking premade widgets together until retirement.
The end result as I and many engineers at and over the one decade mark have realize. Nothing matters, no one respects you, and no one truly cares. You get paid and promoted whether or not your code is elegant, or safe. You get recognized by prostrating yourself in front of leadership. So why should I give a shit if my code works or not. It passes tests and I get to eat.
The industry is pathetic and we should stop calling ourselves “engineers”. Modern corporate programming is analogous to working on a widget assembly line in the limit. Most of us simply find our joy elsewhere and have learned “hearts and minds” as the rule of corporate life.
I worked on compilers and tools starting in 1981. Proprietary compiler technology has disappeared over the decades and the development tools/language/process/compute have changed considerably. But the skills and role of a compiler developer seem similar, although maybe it just means this sub-field of software has matured.
That's one of the many many reasons I miss my dad so much. He went straight from MIT to GenRad circa 1970. I didn't start doing software till 1998, but we had some years of overlap -- and it was profoundly gratifying to connect w/ him on engineering topics. The learning was even bidirectional tho I'm sure I got more out of our pseudo-professional interactions than he did. Sigh. I really miss him.
I think the engineer jumping between giant companies for three years or less every time rarely works on particularly key things. Big tech companies do a LOT of stuff, and most of it is crap that isn't moving the needle. This post describes teams that are constantly changing priorities (chasing trends?) and IME that's not true of the really core, central functions at companies. But very true of the "support/enabling" or "what else can we do?!" side functions.
For instance, Github Actions being a meh product is called out in the article - that's a classic "check the box" feature that's good enough for a lot of people (let's not forget that Jenkins was no picnic before it) but is never gonna massively increase GH's bottom line.
Those sorts of projects are easy places for politics to fester since they are easy to ignore for the most influential-and usually strongest-parts of leadership.
On the other hand, if you're on a core, mission-critical team and other people's code is turning into your bad performance review, you need to figure out if the problem is (a) bad/toxic manager or (b) a failure to keep your management chain informed at what the root issues are and how you can improve it.
Every time I read his article I regret it. I literally mean every time, 100% of it. Judging by the title of the article, I didn't expect his reason to be "engineers working outside their area of expertise". I've seen good engineers figure out problems outside of their expertise plenty of times, so that's not a good reason either.
I feel like this article is the equivalent 16 paragraph stating you're likely to be correct only 10% of the time when you guess a random number from 1 to 10
> 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.
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.
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
Few things that I would tell my kid of she was starting out in this industry today
- never work FAANG or any bullshit company like that
- look for companies that are small (up to 100 SWEs max, preferably 1/2 that) that have solid business (20+ years, profitable)
- when you get hired volunteer to fix every problem everyone else is running away from (there will be plenty). you will work hard in the beginning to understand the nuts and bolts of everything
- along with nuts and bolts of the technology / stack / ... learn the domain as much possible (so much so that you could get a job tomorrow in that domain, e.g. if your company is providing software for automation of say state&local courts then you need to learn everything there is to learn about state&local courts so much so that you could legit get a job as a court administrator)
"soon" you will be the first that:
- fixes all the issues
- puts out production fires
- is in every meeting
- ...
there are other ways to do this but this 100% is one of them...
quite the opposite on the burn out part… if you are curious (this in my experience is in the top-5 traits of exceptional SWEs) you will instinctively want to learn everything there is to know about what you are building. and do it at your own pace, to use a cliche, this isn’t a sprint, it is a marathon.
the leadership also does not have to be competent, you actually want slight incompetency because competent leaders would not allow project to heavily rely on one or handful of people.
"At your own pace" exists only in a handful of very privileged spheres. Maybe part of the USA scene and that's it. Everywhere else is "fall in line or get fired".
You hiring? I got rejected twice from US companies with the explanation that they wanted to have me and the CTO pushed for having me but compliance does not want people from my region.
Replies like yours are wholesome and nice... but they also assume the only problem is in one's head. I am long past this. I just can't find good companies to work with in the last few years is the chief problem now.
pick your battles. You decide what extra work is worth your effort.
learn to say "no", by which i mean "yes, but...". e.g. "can you look at this production issue?" --> "yes, but it is outside my comfort zone, so i will have to charge at least 8 extra hours of overtime towards that issue".
Sure. The problem is more like that during the interviews I was made to believe this is welcome and on day one I was told in no uncertain terms that I'll follow a script to the letter or get fired. Which ultimately happened.
Shitty luck and all sometimes, of course. But really, most of the HN crows very quickly glances over how many toxic and terrible places to work at exist out there.
I think not necessarily. It also means freedom and power.
The flip-side is: you need the money more than your employer needs you. Which puts you in a bad position to negotiate salary, makes it hard to stand-up against bad decisions, etc.
I think that it can (not sure if the author meant this) also mean that you have a buffer and are OK with switching jobs, but are also in a position where your employer wants you (because of something you can do). This puts you in a GREAT negotiation position.
quite the opposite, if you are worth to the company more they are worth to you you can demand high, high, high... rates - especially if you eventually make the right choice and go 1099-way
> this is a deliberate choice to make labor less powerful...
To be fair, though, I don't trust modern labor either if they can't figure out how to NOT vote for a rapist pedophile real-estate billionaire. Twice. Including a pandemic and a coup.
Or look at how bad the coronavirus response was, for such a rich country.
Something's deeply wrong with American political culture, like from watching too much Game of Thrones or something. It’s not just being misled, it’s ingrained.
I think for many Cruelty <=> Power. Like how guns make them feel powerful. I wasn't born here originally so I don't really get it (thank god). It won't end well.
Has it been many people's experience that big companies intentionally remove experienced engineers from your team to something unrelated, in the name of fungibility? I've surely seen efforts within a team to make sure that there's not a single person who's necessary for the team to reach full productivity, and I think most would agree this model does not make for resilient teams. But many of the best engineers I know have had much more energy invested in getting them to stay than to leave
Maybe it's things like 4-year tenure, or shorter tenure, or something else.
But I think it's a matter of motivation, Bob.
> The thing is, Bob, it's not that I'm lazy, it's that I just don't care. It's a problem of motivation, all right? Now if I work my ass off and Initech ships a few extra units, I don't see another dime, so where's the motivation? ... my only real motivation is not to be hassled. That, and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.
No, big tech engineers are highly motivated. There's lots of money, good management, and plenty of incentive. (I'm a Google engineer myself).
The problem I observe is a fairly universal one: management doesn't care about good code, it cares about results.
It's generally hard for anyone without specific experience with a codebase to tell what you're doing with it. Management can't evaluate the value of maintenance work, so it doesn't value it at all.
> The problem I observe is the universal one: management doesn't care about good code, it cares about results. It's generally too hard for ANYONE to tell what's going on in a codebase unless you're experienced with it. Management can't evaluate the value of maintenance work, so it doesn't value it.
I think this is a very telling statement, but perhaps not in the way you intended. I would agree that management only cares about results, but I would posit that maybe that's a good thing. If you don't have ground-truth knowledge of a problem, you must rely on either the word of someone who does, or metrics that can be used as a yardstick.
When all a manager has to go on is someone's word, it can be really hard for them to gauge the depth, severity, and impact of the problem being expressed to them— and without any metrics, they have no way of tracking progress on resolution. In a modern codebase, you could spend YEARS on improving maintainability and still not "finish". The key (that I've found, personally) in this situation is to give the manager some form of metric to describe the problem. If you can establish a number to measure what you're advocating for, and quantify the consequences of not doing it into actual business impact, I've talked managers into taking my suggestion more often than not.
> in this situation is to give the manager some form of metric to describe the problem
how do you have a metric to measure a future issue that got prevented by having good maintenance?
Either you cannot actually imagine nor describe the problem that was prevented, or you could just make something up which cannot be disproved nor falsifiable. So if you asked for time/resources/budget to do maintenance, you cannot then give proof that this maintenance was useful!
The only way to get a metric is to have an incident or have issues crop up, and then in the retrospective, claim that certain maintenance work could've prevented it.
It's because the only people who can understand the code are people who write the code every day. And sometimes the devs don't even really understand it.
Occasionally you'll have a manager who manages in the day and codes at night, which is fine if not bad for his personal life. But HIS manager almost never does that. And his manager's manager? Forget it.
To be fair to management, it is the results that matter.
Management cares about what their management cares about. So this boils down to what the CEO cares about. The CEO cares about what the board cares about. The board cares about share prices going up.
I do believe that e.g. retaining engineers is something that helps the business. It's stupid that someone ramps up for 2 years and then goes to a different job just as they start becoming really effective. It costs companies a ton of money which they could instead just use to get people to stay. But I'm not on Google's board. It's only when Google board decides that fostering the right engineering culture is important enough for the business that something is going to change. And so far- they don't (s/Google/BigTech).
Re: Incentives- Obviously(?) the incentives are not right. So when you say "plenty of incentive" what it really means is incentive to ship sloppy code and get promoted. Or the incentive to go from Google to OpenAI and get a pay increase or whatnot.
> To be fair to management, it is the results that matter.
To be fair to me, I don't recall ever signing a contract through which I am directly responsible for the company's financial and customer-acquisition / retention efforts. I sign up as an individual contributor who helps advance the customer & product mission forward. I am NOT a cofounder.
So that shows, yet again, how myopic and egocentric managers are. Wise ones -- the all 2-3 I have met throughout a 20+ years of experience -- understand that they must enable you to produce the outcomes they care about.
Unsurprisingly, I worked fantastically well with those managers and we achieved near-miracles in some measly 4-5 months.
But all others? "I never gave you time to optimise cloud spend but now I am angry at you for not doing it in your sleep", more or less. Or "I pushed you to the brink of 12-hour workday regularly and started reaching into your weekends and you rushed that feature I pressured you for and it has one small performance regressions? You are fired!". Deal with it.
/rant.
Not directed at you, obviously. Got triggered a little.
We need to disconnect the question of bad managers from the structural issues though. I try to be a good manager but I still have people jump ship for better comp and where we won't match it. I still need to deal with an incentive structure that doesn't match what I am trying to do with my team.
This same structure is also what helps bad managers. Who is going to get promoted to a director role? The person who stands up for their team and argues with the VP or the person who toes the line? The things that you think are near-miracles are not visible and the people that play politics will make their stuff look more valuable to the company.
Yours and my experience are not mutually exclusive, I think we both see it. I dream of managers like you but I never get hired under them for some reason. (Likely regional culture, experience shows.)
I'm at a stage of life and career where I'd happily take a small pay cut for a year just to establish myself in a place and have stability. Then we'll talk about competitive compensation.
My chief issues are with people that are best described with the proverb "give them an inch and they will take a mile".
Yours seems to be that you deal with people that constantly think that they can do better in terms of how much they take home (let's not sugar-coat it, they're spoiled -- I was too).
Heroics being invisible and people who have their coffee with leadership getting the money and the influence is the wrong system. Always was and apparently always will be.
It's interesting that you talk that there's a lot of good management, followed by a list of things I'd call bad management: Forget about good vs bad code, of course that's unimportant. But insufficient maintenance that causes lower velocity on the next set of changes matters. Good engineering will tell you when the issue isn't just about code that is ugly, but code that slows changes down so much you'd be better off improving it.
If you set incentives that say that being sloppy and leaving landmines for the next group of people is the way to get promoted, guess what? the management is bad. Often because they are also looking at their own self interest, and expect to leave the consequences to whoever comes after them. This isn't new to big tech: You'll find this all described in books about corporate dysfunction written in the 90s.
It's all traditional principal agent problems, which just get worse and worse as you add layers of management, as the principal has agents upon agents underneath, all using the misaligned incentives. One either wants t avoid getting fired while doing the minimum, or sacrifice the health of what is around them for a good enough promotion packet/review. And since there's no reasonable way for individual objectives to align well with long term objectives, people leave landmines. When there's enough landmines everywhere, you are always better off in greenfield development. And at that point, doing any maintenance, or being stuck in a project that isn't getting fed a bunch of capital to grow it is career suicide. All about bad incentives, set by bad management.
> The problem I observe is a fairly universal one: management doesn't care about good code, it cares about results.
The thing is, good code is a form of a good result. You need to solve the underlying problems (which manifest as impact) but if you used code to get there, that code if well designed is extensible, reusable, then you pay low maintenance on it and that same code can be used to solve other problems (ideally).
It's a difficult judgement call to make though. If your org doesn't have the right technical leadership and the performance management structure doesn't reward it then you get what you see.
It's a lesson that's always learned far too late when it becomes slow and costly to deliver something new because you've amassed so much tech debt so it's often cheaper to start from scratch (which is saying something).
I see this all fwiw in big tech myself and with my peers at peer companies.
> It's a lesson that's always learned far too late when it becomes slow and costly to deliver something new because you've amassed so much tech debt
No, it is just standard operating procedure: deprecate a working system and write a new system from scratch, with 50% of features not supported. This side-steps the tech debt and gives everybody artifacts for promotion. It screws all users of the system but who cares about them!
"management doesn't care about good code, it cares about results."
And management is probably right: code is a mean, not an end
It is us, as software engineers, to make that better code brings better results
Some benefits of better code can be:
- less infrastructure cost
- more speed / efficiency / whatever metrics available from the users
- easier to integrate new features
- less issues, less time spent in maintenance etc
At my current job, we have some instance of people who animate around bad practices: they scan everything, identifies some "bad practice" (which can be whatever) and then raise the issue to all teams and give them a month to fix the issues
Very political stuff
I try to do good code. My team is rarely cited in that list of "bad players". Management does notice.
Corollary: our roadmap is not messed up. Product managements notices.
Also, good code must mean robust infrastructure. We have very few incident. Almost all our changes are successful. Incident and change managers notice.
Anyway, my point is : if good code brings no benefits to the outside world .. how is it good, exactly ?
Yup, tolerating inappropriate tech debt for too long leads to bad results. I see this going wrong all the time and I thought it was mostly due to being surrounded by bootcamp grads given nothing but year after year of pressure and no examples of what good code can look like. Surprised to hear the same thing happens in big tech.
The thing is shipping sloppy code is orders of magnitudes easier, because that's the default result. Any sufficiently determined hack-job can do it. On the other hand, steering a team of 5-10 engineers to deliver quality on (or before!) a deadline requires excessive amounts of coordination and skill. Now, is this trade-off "worth" the effort? I guess that's a matter of opinion, though I would argue in the long term quality wins out by a large margin.
Sometimes teams will do the sloppy thing because it's the quickest path to resolution of an issue deemed to be critical, which can make sense in the moment, but if you do this too many times without spending the effort to improve the solution after the immediate pressure is gone, issues like this will continue to get more common. I like to use an analogy of trying to put out a fire on the other side of a building by filling a cup in the sink and then running across to toss the water onto the fire; in the short term, it might be the best fix, but if you keep finding yourself having to do this, you're probably better off installing a fire hose even if it requires a lot more effort up front.
There 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.
That'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.
Was McNamara really thinking that's how you win a war and people just went along with it or was it just another excuse in a long line of excuses to keep the gravy train going?
I used to be an extremely motivated engineer. I cared about the code that I wrote, the other people on my team, making sure things were documented and understandable. I tried to write good code where I could, and detailed PRs and issue writeups where I couldn't.
Despite that, I was always paranoid I wasn't doing enough, because it always felt like there was someone else that was shipping more code than I was. Some of this was almost certainly social comparison bias and impostor syndrome-like feelings at work; but I also had a string of managers that pointed out all the work I was doing, and how I was helping the team as a whole.
Eventually, the company got acquired by exactly the sort of company this article is about, my manager got a new director from outside the company, and my manager had to go on extended medical leave after a cancer diagnosis, leaving the director with ~7 new reports. I started hearing about how the number of PRs I was opening weren't as numerous as some other people's, and the code didn't look "hard" enough to their glance. Never mind if the easy code was hard to come to, or if talking through it after the fact they agreed with my assessment, or if I had performed a detailed investigation and writeup, or if my peers left reviews or public plaudits about work I had done. Those weren't PRs, which is ultimately were what they wanted, since that was the metric they could easily see, and justify to their boss.
I did _try_ to do better by their metric, though I never had a definition of what "better" would actually be. Funnily enough, that person was fired a few months after I was.
Also kind of funny to me is that, if I weren't motivated and didn't care, none of this would've affected me all that much.
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
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
> 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
I moved teams a few years ago, and the very first thing I did was push hard to re-structure the schema they (sorry, pals) slapped together without much thought. It took some fair amount of arguing, and maybe a PR that I had reviewed by only a single person and pushed through because it's easier to ask for forgiveness, but we got there in the end.
Luckily, we were able to do this before the code started hitting production traffic; it would have been significantly more difficult to fix once we started getting real data into the system.
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
Because businesses, as a rule, value moving fast. Being first to market makes money and generally results in winning.
Oftentimes the circumstances are "we don't know the requirements", not because of shitty management, but because the problem is inherently hard to define.
The business conditions that do heavily penalize bad architectural decisions, like physical structural engineering, can suck to work in compared to SWE.
It takes a decade or more before you're trustworthy enough to architect a building and there's a million layers of approvals. Then it takes years before groundbreaking, and years more as the building increases in size.
Your whole life might be dominated by a single large project like Hudson Yards, which has been floating around as an idea since 1956. The most recent proposal started in 2006, broke ground in 2012, and another 6+ years to finish. Then when companies were about to move their offices there, COVID-19 happened and the leases fell through.
I'd rather the system that gives average SWEs regular opportunities to lead large projects from scratch and make mistakes.
I think you are underestimating how many product problems at big companies are actually bad technical debt. They cant release new features or evolve the offering because the systems are too complicated to change. 1 year of quick development could stunt the whole org for the next five years.
The good news if you take 2 years to ship the system "properly" then you won't have to re-factor it because the company went out of business or that product was too late to market.
There is a phrase "million dollar problems". You do stuff at your startup that will take a million dollars to fix because it doesn't scale.
The point is that if your startup doesn't get to that scale then it doesn't matter. If you startup does reach that scale then you have plenty of money/people to spend a million dollars fixing it.
Replies like yours gloss over nuance. I don't mind prioritizing time to market as a programmer; I am not clueless, I understand that imperfect product that pours money into my employer's coffers is infinitely better than it sinking and we all get fired out of necessity.
My problem comes from the fact that the leadership _never_ compromises and never allows us to avoid at least some crises that are extremely easy to foresee (and have happened like clockwork in 95% of the cases where I or other colleagues have predicted them).
Again, sure, let's go to market and start making sales. I completely agree. But scolding a dev for fixing a DB schema anomaly that slows down ~40% of _all_ feature requests and that it took him the grand day or two to do so, is not just myopic. It's moronic.
---
Even shorter / TL;DR version: If the balance of power was 80% leadership and 20% engineers, I'd still be completely OK with that. But wherever I go the "balance" of power is more like 99% leadership and 1% engineers (and that's only when stuff really has hit the fan; they'd take away that last one percent as well if they could).
That is the problem. There's no balance. No compromise. Just people barking orders.
It is not only being first. It also is about responding to customers - not fun part is your customers don’t care about your app. They have to use dozens of different apps on daily basis, so when you have customer interaction you better be able to do stuff right there because they might be available in 3 months or next year to talk about your app.
I don’t like all the fantasy about “just talk to the customers” - nah it is not just, it is super hard to get their time.
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.
All systems eventually turn bad. The idea that you can gold plate something so it won't is naive. It isn't about getting it right from the start, its about having the will to change it once your system or uses evolve into something that turns it wrong.
> 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.
In the context of reviews my experience has only been code review quality brought up as a negative thing for folks and the bar to not be a negative is low enough that folks slowly take less and less time to review code well because it isn't valued come review time.
Its hard to have good enough requirements gathering and documentation and product design practices to let an engineer really wrap their head around a problem well enough to come up with and then consistently follow a thoughtful, long-term-maintainable design for a system during implementation.
And its even harder to make sure everyone who reviews or tests that code has a similar level of understanding about the problem the system is trying to solve to review code or test for fitness for purpose, and challenge/validate the design choices made.
And its perhaps hardest of all to have an org-wide planning or roadmap process that can be tolerant of that well-informed peer reviewer or tester actually pushing back in a meaningful way and "delaying" work.
Thats not to say that this level of shared understanding in a team isn't possible or isn't worth pursuing: but it IS a hard thing to do and a relatively small number of engineering organizations pull it off consistently. Some view it as an unacceptable level of overhead and don't even try. But most, in my experience, hope that enough of the right things happen on enough of the right projects to keep the whole mess afloat.
I've seen too much of the same. It strikes me that the pattern you describe also matches a lot of AI generated code I see, especially when it's big chunks of generated code. Are we automating this problem and going all-in on the long term costs?
100% yes. The most dangerous developers you’ll ever work with are the tactical tornadoes who crap out extraordinary amounts of code that mostly implements the exact feature that product asked them for with zero thought given to any other concerns.
AI makes these types of developers much more dangerous because they will accept anything the AI generates tha looks like it works, and they’re experienced at pushing nonsense through code reviews.
AI also provides more of a “productivity” boost to these types of developers because unlike everyone else they actually spend the majority of their time typing code.
This was the case before AI tho, people were copying coding patterns from companies randomly even without understanding. I mean there was an interview with some DoorDash architect that literally stated that whatever their architecture was just fad chasing at that moment.
Every company I've ever worked at (from ISPs to health insurance to finance) every organize was just copying the fad of something else.
At the time I felt like it was because that was "the best way" but it was more likely do to engineers not having the freedom to actually explore good solutions. The made up constraints imposed by organizations against their workers are rarely for the benefit of the company.
It's not a surprise to see this being the case, most companies on the planet are ran like centrally planned dictatorships with the results being obvious in retrospect.
Catching architecture problems in code review is usually a red flag for process problems. Anything substantial should have been reviewed for architecture prior to a code review, especially if it spans multiple commits. Code review should feel rote and focus on rubrics around style and best practices in an ideal case. Of course you will still find architectural issues during code reviews in many cases but that shouldn't be often as it's not reliable to expect the reviewer to have the necessary context to catch them.
It's getting much worse with AI now too. People just blindly trust the AI's decisions which even as of Opus 4.5 is generally misguided for nontrivial problems and best-case doesn't even consider the bigger picture given context-window limitations.
So the mountain of syntactically correct functional slop is growing faster than ever before.
The 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?
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.
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.
It is possible that some projects like Oracle are beyond hope but in general cleaning up a messy code base is done piece by piece and by refusing to merge most patches which make things worse. Better than you found it is the main principle.
Just wanted to comment on the fact that I remember seeing that comment, and it left such an impression I remember it 7 years later.
Thanks for the reminder, going to bookmark it this time.
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.
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.
> 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
> I'd go further and say you're not a senior if your code isn't good you shouldn't be a senior.
You say that until you are tasked with doing impossible - three lines, all perpendicular, five green, two anti-green, seven in ten or more dimensions, any color; while customer only uses purple lines.
Last guy that worked on it committed seppuku. Rest of team is in mental ward. Your only team member is guy that programmed his entire life in PHP, and doesn't know backend's language. Just teach him.
Documentation, is spread between Jira, wiki, Markdown, ftp server and some napkins.
CI stands for continuous Indians. You send code to India, where a team will assemble it. It may take anywhere between a few minutes or few hours. But it beats GitHub actions. Make sure to inspect artifacts, the Indian team has a habit to add some of their ""bug fixes"" covertly.
Words aren't absolute. No reasonable interpretation of my comment suggests I'm saying you should do the impossible.
If someone asks you to do the impossible you have to say no. Better yet, you should figure out what they actually do want. They can't get the impossible, that's not on the table.
The worst thing an engineer can do is not learn how to say no.
I'll even say, if you don't know how to say no then you're not qualified to be a senior
My CTO, when told that adding scope, reducing headcount, and keeping the same timeline all while discovering new unknowns in the codebase was not possible, we were simply told to make the date and asked who's performance review will be impacted. The "no" was entirely ignored. "I don't accept that."
I think bosses are like cats, when training them you have to make it think it is their idea. As I said in a sister comment the best way to do this is to not say the word "no" but to ask clarifying questions[0] so that all the puzzle pieces get placed on the table. Together you can assemble most of the puzzle, taking the lead but not lecturing them. But the final pieces have to be put together by them. Management is egotistical and if you just tell them then they get upset.
Your loyalty should be to the company, not the person. So by just "falling in line" you are failing the company.
Remember, if the project fails (and it will fail if it is impossible) people get fired anyways. Sure, getting fired later is better than sooner but it is still gonna happen.
[0] In your exact case, find out what they are actually after. Sounds like it might be a budgeting problem and they only know how to pull a few levers. They're business people, not technical people and they're working in a world that is highly technical. They're really a fish out of water and they don't know it[1]. It might be greed or panic too, which are harder to deal with and in those cases yeah, you should start looking for new work.
[1] I'm not saying a techie as a CEO or in a management position wouldn't be a fish out of water either. That'd be similarly as naive. But a well functioning workplace has to understand that these are different skillsets and we have to intermingle. You can't know everything so we have to work together to leverage our niche expertise.
Actually I worked for a failed startup where everyone left because they disliked management. In that startup I was the lowest paid engineer and the only non "staff" level one who had a contract bringing in money to the company. My last employee review with the company was terrible even though they admitted in the meeting that I had achieved all the goals and gone above and beyond what they had requested I do to get a promotion[0]. It was pretty clear it was about money, I asked if this was actually a performance issue or a money issue. The conversation changed though still ended up being very political...
This is part of why I'm insisting you need to work with me to be able to communicate. You are reaching for assumptions that justify your position. My opinions are shaped by these TERRIBLE experiences.
Management makes or breaks a company. As an employee it is your job to help ensure the culture works. But you can only do so much too. I'm not saying change the world. As a standard employee if things are going south, it is time to brush up your resume and start shopping around. You can interview without taking a job. You're not stuck where you are, so stop acting like that. The problem with your point of view is that you act like you have no options. It is either work for where you work now or have no job. Don't quit until you have something else lined up. But also don't be afraid to quit. It's not worth being miserable. Interviewing to find a better fit is infinitely better than hating yourself day in and day out, more and more as time goes on.
I'm not saying it is easy either btw. It definitely takes work! But neither are you stuck.
[0] I came with receipts. I had them give me a comprehensive goal list in my previous year's performance evaluation because I had already recognized some of these issues. So I wanted something in writing. It helps. (And btw, I even had a meeting with my direct manager 6mo in and 3mo before the yearly review to make sure I was on track)
> This is part of why I'm insisting you need to work with me to be able to communicate. You are reaching for assumptions that justify your position. My opinions are shaped by these TERRIBLE experiences.
Not really. I'm reaching my conclusion after several experiences in various domains (fintech, ad tech, logistics software, and government-adjacent firms). Each company is terrible in its own little way. The reasons aren't always the same, but they can vary from colleagues to bizarre pipelines, to management to CEOs.
I have communicated this to management, to PO, to scrum masters, to a point. I don't want to get fired of course.
And I can see the outlines of what caused these issues and why management is doing what it is, but that's again tied to a larger economy at play.
> You're not stuck where you are, so stop acting like that.
Again, you're assuming you understand my condition.
It's a different pickle. I'm waiting for an external thing to happen (it has been continuously delayed for nearly 12 months) to be able to change jobs. Not that it's easy in the current market.
The GP has been homeless and lived off of discarded food.
You're right that saying "no" is a privilege. But also there's nothing as empowering as knowing that it's not going to be as bad as it was before.
Stop making assumptions about me and start trying to communicate with me. We can't talk if you want me to be wrong and just reinforce your position.
And sorry, I'm not as good as doing the cat wrangling in social settings as I am in technical ones. It's a different set of tools to work with and much harder to do in an online setting.
You're right that it is the whole structure, but the whole structure is made of people, individuals. Collective action can't happen without individual action. You don't just magically go from no people doing something to everybody doing something. You start with one person doing something, then more, and more, and it spreads like a virus. Both good and bad behavior spread this way, not instantly.
Look, our literal job is to take hard problems and break them down into small and more manageable problems, right? Addressing the whole company is too big of a problem, you have to break it down. You, you are an addressable problem that you can change. The people close to you? Harder, but easier than those far away. They're also easier to convince when you make the change yourself.
Or you can just give up and rot in the soup. Would you rather try to remove the rot from the soup or bathe in it?
Your assumption that seniors will be able to output good code in any situation is what is the issue.
As a senior I've been tasked with impossible tasks, with insane deadlines, in ""enterprise"" code bases. Sure, saying NO is an option, but being the NO guy is surefire way to getting fired. And nothing looks better on resume than repeated firings.
Again, you need to reasonably interpret what I'm saying. Picking out an edge case and acting as if it is some mic drop is disingenuous. We can't communicate if you hyper fixate on one tree when our discussion is about the forest. Language isn't precise enough to do that without getting extremely verbose. So either I can write a novel in response (I'm not going to) to explain what I said above or you can work with me here. If you're really not getting it I'm sure an LLM could help you out if you also fed it the responses.
> As a senior I've been tasked with impossible tasks
Sure. Even juniors get this. But an impossible task is an impossible task.
> Sure, saying NO is an option
Saying no is always an option. When given an impossible task it's the only option. There's many ways to say no. Not delivering is one of them
> being the NO guy is surefire way to getting fired.
You do not get fired for saying no, you get fired for how you say no. You get fired because the project fails. You get fired because you push back against an egotistical manager who doesn't understand the problem and none of the other engineers back you up.
It's all about how you say no. You don't have to use the word to do so. Instead lead them down the right path and make them understand. You don't lecture them. Managers are like cats, you have to make them think it's their idea. So you have to ask clarifying questions and when doing so you can introduce explanations that let them know that it's not possible. The goal is to put all the puzzle pieces on the table, put the right ones next to each other and let them put the final pieces together. If they don't then they don't feel like they did anything.
You are not a mindless automata directed by your manager. That's not the role of a senior. Your job is to get things done. A senior knows that "the customer" (in this case your manner) doesn't know what they want and doesn't know how to say what they do. The job is to figure that out as best as possible
> We can't communicate if you hyper fixate on one tree when our discussion is about the forest.
All I'm saying is you can't expect perfect code in impure systems.
> You are not a mindless automata directed by your manager.
I never said I was, but I also can't turn a ship on a dime. I'm asked to perform a task; I'm going to perform to the best of my abilities, but in impure systems the best you can do is patch the leaking part with code and do some basic refactoring. Any moment spent trying to simplify and fix the software will be rightfully considered a waste.
Because a feature sold is better than performance gained (unless it's utterly abysmal).
> The goal is to put all the puzzle pieces on the table, put the right ones next to each other and let them put the final pieces together. If they don't then they don't feel like they did anything.
Again, in impure systems half the puzzle pieces have left, some other parts of other puzzles have been mixed, and it's the clock is running.
The more you focus on cleaning code, the more you are falling behind feature wise. Up until a point that you can present to managers "Shit is very bad, we need to refactor."
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.
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.
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.
Of course you should not wait around. I think rather the opposite that the engineers should be more involved in working on the requirements. The issue is more rushing and being expected to magically just conjure something. Changing requirements is a fact you just have to live with in many industries.
Changing requirements is fine. Changing requirements when it was eminently avoidable is very, very bad.
If I asked you 6 months ago if you might ever consider something other than credit card payments, urged you to seriously consider this and you say no, you shouldn’t come to me now and say that bank transfers (bank transfers!) are absolutely indispensible.
It works as designed if your goal is to get your next promo package. It does not work as designed if the goal is to actually make the company more profitable. This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.
> This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.
Being delivered faster or cheaper isn’t the goal. The goal is to look good while doing it. Telling your bosses ‘Yes sir!’ Is apparently a lot more palatable than saying ‘No can do’.
> 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 proje
You have a very charitable view of the competency of the typical engineer at big tech nowadays. Ten years ago, sure. But with the advent of people purely studying for coding interviews that's changed.
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...
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, 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.
The 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.
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.
I 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
The bricklayer's building that falls over, or the cook that makes food that tastes bad and no one wants to eat and makes people sick isn't going to have a job for very long, however. And of course, the job of "cook" runs the gamut from minimum wage at a shitty diner, to being very well paid at a Michelin star restaurant. So shipping code > beautiful code, but three years from now, that one "quick and dirty hack" just to get the next version out the door has become three hundred hacks, and that tech debt is a liability preventing any movement, either fixing existing bugs or in shipping new features.
So maybe not every line of code needs to be even more beautiful than the last, but there's clearly a balance to be had. And yes, sometimes the business people are right. Sometimes they are wrong, however.
When I started programming I wanted everything I wrote to be museum-ready. I was slow as shit and waaay too precious about code. As I've matured I realize that's not a good way to work.
I think my lowest acceptable quality bar is still pretty high (and I'm fortunate to work somewhere that is valued). But as time has gone on I've tried to emphasize speed and knowing when something is "good enough"
I feel that it's an important skillset for the profession, but often craft-oriented engineers dismiss it at "business people not understanding"
As always this depends a bit on where you work and your projects
Your analogies don't work. Nobody pushes a cook or a bricklayer so hard that they cannot have a basic level of quality to their work. A meal that makes a customer sick or an entire floor of a building collapsing due to bad bricklaying is the limit the managers in those areas generally don't cross.
Not the case in commercial programming. If you manage to pull a heroic and still deliver something that does not fall over in a near-impossible deadline and with a lot of pressure then you are actually doing a huge disservice to yourself because the leadership will think "welp, obviously he can do it in those conditions" and next thing you know, next time around it will be even more difficult.
"Give them an inch, they will take a mile". Sadly this proverb very often applies to business people.
Most commercial programmers are extremely squeezed. I started daydreaming for another profession lately but yeah, ain't happening in my 40s with a very unstable financial situation.
I've read your sibling comments. It seems like you were on the other extreme and it does seem to me that now you are overcompensating by being too sympathetic with business and management. Whiplash effects are very understandable while one is still trying to find their balance. Still, don't give those people too much credit.
What are you being pressured to do to meet a deadline that's on the level of building collapse?
"skimp on the tests" or "do this hard to maintain fix as the solution" is maybe the hardest I've gotten pushed. Are people telling you to skip auth to hit a deadline?
> A cook cannot spend time making every dish perfect.
That's too generalised. A fast food cook can't spend time to make things perfect. A tiny, fancy Japanese place will spend time to manually craft a perfect dish and you'll wait while watching the whole process.
I suspect that you can find something similar in every category you mentioned.
I think this is worth exploring. Not shoving the details of work in people's faces to assert its quality, but somehow creating some drama or interest in its quality. In a way compatible with the immediate practical needs.
This isn't an easy problem to solve. And the example of a boutique Japanese restaurant is a good one. In this case, the process is designed to make consuming the food, the immediate practical problem, more satisfying.
Perhaps the code equivalent, would be seeing changes in sequence, where each change is obviously well done from the user's and manager's perspective. A process more easily achieved by green field work. Which is also relevant to the restaurant example, where each dish is its own creation (within a well thought out process).
> "... so you're saying they wrote bad code on purpose?"
Depends how you define "one purpose". I feel like I could polish any code to perfection forever. But the threshold of bad is going to be very murky. Is it still bad after 5min? After 30? After an hour? After a day?
Wherever you think is the right effort/benefit threshold, it will turn out to be different in a few weeks. And you'll find people who think it's too fancy and people who think it's bad. Rarely is there objectively bad code. (Yeah, sometimes there is)
> Wherever you think is the right effort/benefit threshold, it will turn out to be different in a few weeks.
Very true. And experiencing this has absolutely been a useful lesson to me. I remember feeling pained over some code I wanted to write in a more robust and principled way in front of a big deadline, and after a bit of friendly push and pull with my manager, I agreed to console myself by throwing in some TODOs and FIXMEs in the comments instead of getting carried away overengineering or burning rubber just beautifying my style. I remember this ritual feeling painful at the time, though it helped me cross the finish line sooner. A few months later, it was clear that ~80% of that code would be good enough for the next year or so— by which time other parts of the application would have evolved as well. I even ended up glad I'd deferred a few of those changes just so the small refactors could be informed by things we'd learned in the meantime.
Sometimes it goes the other way, or course! Many times I've been glad for some extra care I put in early, or regretful about some I didn't. But you're right that that balance always seems to change in retrospect, one way or the other.
> I feel like I could polish any code to perfection forever.
Then you know what to work on to become an even better engineer. My recursive function for improving code has clear exit conditions. One of them indeed includes aggressive timeboxing, so on that point we're aligned.
I feel you are trying to make an argument against better code. I get it, there are very fussy programmers out there who can indeed polish stuff until the heat death of the Universe (and still be unhappy) but bringing up extremes is not very interesting in a discussion IMO.
> Is it still bad after 5min? After 30? After an hour? After a day?
Generally, time spent on code has near-zero correlation with the quality you'll get. That correlation only becomes stronger when you have a lot of trust in the person writing the code (including yourself).
As above, don't try to make managers look like the reasonable people. I've met some and I adored them but the 99% are egotistical snowflakes that will fire you the first time you say "no".
---
Nobody is saying "accommodate the insufferable nerds and give them two weeks to do what junior Joe will do in 2 hours and it'll be pretty good" here in this entire thread. People are saying "maybe we the programmers should have SOME power in some decision-making as well". I am OK with my influence being somewhere between 10-15%; that's expected, I am neither a manager nor a financial stakeholder. What I am not OK with is when that number is 0-1% and sadly that has been the norm during my consulting and contracting period. And it's the main reason due to which I am trying hard to end this period right now and settle somewhere).
I'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.
Bad 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.
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.
IDK, my team at a FANG has an average tenure of around 7 years and the ones less than that are new hires. I keep getting refresher grants every year. I'm sure this article rings true for some people but not me.
I'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.
The job hopping thing was definitely a trend, but I think it died with ZIRP. kinda weird to reference it now, but I guess it does have relevance to the state of some of these older services. The original teams are long gone
I 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.
Good 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".
I think we can agree on a version of bad code, specifically extremely bad code.
Just as we might agree on universally panned bad movies, but disagree on cult followings or one of us for a particular reason can't stand a popular movie.
That is to say we can all agree on extremes, but just because something isn't extremely bad doesn't make it good in everyone's eyes and that's where the contention is.
I 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.
I 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.
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.
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.
Author'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.
In 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.
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.
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.
Deadlines 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.
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
Every 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.
Over 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.
I 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...
A 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".
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.
What 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.
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.
>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.
> I'm also dubious of your claim that compensation doesn't attract better talent.
Maybe higher compensation does work out for FAANG, but it does not at other larger employers, at least not for software developers. I am highly dubious about this at FAANG too though. My perspective is as a former 15 year JavaScript developer and a lot of what I saw coming out of FAANG in JavaScript land just wasn’t impressive.
I do see a lot of impressive things in the world of JavaScript but it’s almost always open source from small teams or single developers.
I 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.
I 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.
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.
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.
The 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.
Ah, 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.
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, just table stakes. Profitability is determined by the machine built around the product, like 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.
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.
Well maybe you get hit with the gray arrows because you first make a sweeping generalization and then say "I have no sympathy for you". Food for thought?
I have communicated the business value in addressing tech debt, as in I have pointed out how many critical customer features got delayed by it and we churn customers we really can't afford to.
Still got overruled. The tech lead stepped in and threw his weight around with zero explanation to the CTO or the CEO. Who needs to hear what the engineers on the ground have to say, right? They cannot communicate!
Man, tearing down strawmen is easy. You should do better and see nuance. A lot of engineers communicate very well and are still ignored.
When all leadership is asking is "what is the short term business value?", it's pointless to make that case. It's much easier to measure "yet another feature" than "fix the root causes of what makes our product subpar and slows us down". Not only that, but an incompetent engineer's "tech debt grooming" may make things worse.
I think that this may eventually become better now that there isn't so much dumb money around (no ZIRP) and with AI assistants taking on some low-effort work (enabling companies to lay off incompetent engineers). But it will take many years for companies to adapt and the transition won't be pretty.
In the long term, once the damage from vibecoding is better understood (for customer impact and team morale), there's an incentive to push them out, both from the leadership and the individuals side.
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...
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).
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.
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.
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.
> 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 ;)
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.
I 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”
Meanwhile, 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.
Not 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.
Oh, 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.
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.
I 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.
There'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.
This 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.
Big 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.
Yeah, 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.
It 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.
oh 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
There’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.
Bad 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.
In 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.
This 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.
I'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.
it 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.
At 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
when 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.
I 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.
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.
I 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.
1. 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.
There'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"?
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.
it'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.
Another 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.
I've read a few of this guys posts now and have consistently been rubbed the wrong way by them. I think I know why now. It's not that he's wrong. His analysis is reasonable and straightforward. I think it's that the basis for his analysis is ultimately a form of nihilism, coming from someone who (maybe?) used to be an idealist but was burnt by a bad experience and must now explain why believing in anything is 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.
> Why does bad code bother engineers so much?
I’ll take a stab.
Because I’m being held accountable for the bad results of the bad code. Because I’m being held to task to fix the problems caused by the bad code on a schedule that I didn’t agree with. Because management is using someone else’s bad code to deny me a positive annual review.
“You’re a senior engineer - why did fixing this take so long?” Because of the garbage I had to wade through to even find the problem. Because I wasn’t yet working here when this was written and I have to take time to get my head around the insanity.
Yes, these are management problems. I’ve spent years managing managers and attempting to educate them on how bad code causes errors and delays. But for many reasons, it’s a Sysiphean task.
I don't think it's that. It bothers me a lot too, and not because anyone else is judging me or anything. I think it's just that it's depressing... it sucks to be doing bad work, on top of other bad work, and unable to do good work instead. It is incredibly frustrating to care about quality but be surrounded by and constrained to work on crap. Just feels like everything went horribly wrong somewhere and you're powerless to do anything about it and your only option is to suck it up.
I know how to fix this but I'm not "allowed to" can eat away at you easily. Then there are things that I know how I might fix but I wouldn't realistically be able to because it's all a lot to take on, there will almost never be enough time and hands to get it done, within the set constraints.
This is due to the way how incentives are aligned. Systems that are powering things for, say a decade at least but worked on Quarterly basis.
Why is this alive and well, then? Because it doesn't actually matter as long as money keeps rolling in. It is also possible that the losses caused by or efficiency not achieved do not show up in the accounts.
>I know how to fix this but I'm not "allowed to" can eat away at you easily.
This really is the worst, and that's why I left my first job. Funnily enough, I just took that job back after a few years but I am now the lead and sole developer on it, I'm having the time of my life doing what I've always wanted to do back then, and seeing the product now flourish.
The bad code didn't really matter, it was the fact that I was not allowed to improve it and forced to build new features on top of crappy code that made me quit in the first place.
That's in addition to the parent comment. They are both true. Caring is for other people, the tickets must flow.
> “You’re a senior engineer - why did fixing this take so long?”
exactly!
If a senior engineer is responsible for the problem, but he wasn't given room to develop a proper solution in the first place, then he cannot be blamed for the outcome. And yet, this is exactly what happens.
If a system had been made well, and functions well, same senior engineer does not get the credit for not causing problems!
This is what happens when management/stakeholders don't understand what is going on, but have an expectation that is not well communicated to the engineers (and also inversely too, where engineers are not communicating the situation properly to management - or they refuse to hear it/ignore it).
Only the bottom line matters and the bottom line isn't a good product, it's a good bonus or stock.
> “You’re a senior engineer - why did fixing this take so long?” Because of the garbage I had to wade through to even find the problem. Because I wasn’t yet working here when this was written and I have to take time to get my head around the insanity.
The arguably unproductive part of my brain craves to reach a day where I can say literally everything straight - if this would be a true description of the circumstances, then say exactly that.
Unfortunately, in addition to not only not being a “team player” this would also be really mean to people that had different time and resource pressures when they wrote the original flawed implementation. So both burning bridges and being kind of a dick.
At the same time, there’s sometimes people that develop stuff in such a way that I will never agree with them and a few people like that are enough for me not to want at a particular team/org even if it’s maybe like just 5 to 10% (and even then often it’s about them being inherently mean/nitpicky/whatever, rather than purely technical stuff).
Obviously the irony of the above isn’t lost on me so I just bite my tongue, focus on being professional and fixing the things I can and let the rest be without picking fights that will lead nowhere - otherwise I’d be a hypocrite and the situation couldn’t be described as anything other than “a bad culture fit” from an outside perspective.
But I’ve seen a lot of really shit code and it baffles me that alarm bells don’t go off more often and people just trudge along.
Then again, you do see a lot of drama in plenty of open source projects, so maybe that’s just human nature.
I agree it's often difficult, but I think it's possible to balance honesty with humility and being a so-called team player.
For example, if you see something that's sloppy [1], your honest assessment will likely help both the coder and the manager. But you do have to temper your language, and sandwich the criticism in something that won't make the person interpret it as "you're sloppy/stupid" or "you don't deserve to work here".
The additional problem is: you have to test it with baby steps. If a coder/manager can't take any feedback [2], not even the friendliest suggestion, you have to pick whether to (1) slowly train each other to communicate better, or (2) leave (it alone).
But ultimately (IMO), it's not worth training yourself to be less honest or dishonest. You risk losing the ability to do your best among other smart, honest and feedback-accepting people, or being an honest and feedback-accepting manager/employer yourself [3].
[1] Like many blocks of copy-pasted code, or massive scripts with no separation of concerns, which can really grind my gears.
[2] I've personally had a few discussions with peers and leads in teams who would get defensive, or interpret my feedback as politicking, even in a cooperative environment, and I didn't love that. But I also didn't love getting (what seemed as) "holier than thou" evals in (what I saw as) more competitive environments. So, maybe my cooperative is another's competitive, and vice versa.
[3] Because you can easily get used to a skewed or toxic environment, and accidentally spread that toxicity to others, or unintentionally be seen as toxic yourself.
> your honest assessment will likely help both the coder and the manager
While I'd like this to be always true, there will be cultures and even individual egos for which this will never be true.
Someone who's considered a senior dev in the org might dislike your assessment (regardless of what external resources and industry practices and any number of people's experiences say) and might turn your suggestions for how to make their code a bit better into a bikeshedding argument until either one of you tires out and gives up (no relation to which opinion is even right or what's best) or the manager gets pissed off at the both of you and has to intervene (not necessarily thinking badly of you) and the traditional methods like "pulling rank" wouldn't work either if it's a senior engineer. Even if you do everything right in how you approach it and frame it positively and everything else.
In part, this might be because there's no one set of guidelines for "this is what good code looks like", especially because of how fast moving and disjointed and underregulated the whole craft is (might settle down in a century idk). It might also be because that mess leads to vastly different opinions on what's good (e.g. how some people take SOLID/DRY as gospel, others don't, to the point where WET is a thing). And some people just don't care and don't see things the way you do.
Concrete example: once saw a bit of code that had nested service calls. Suggested to the person that this will lead to the N+1 problem in database interaction. They said that it's okay because the other code is written like that in the app already and that this code is easier to reason about. A month later I had to actually show them cache hit/miss statistics after implementing caching as a band-aid on top of the nested code because there were deadlines and nobody could rewrite the whole thing as a DB view. In that particular case, there wasn't even mean exchanges or whatever, just endless bikeshedding about whether something is needed or not that lead nowhere, even when graphs and data were presented by me.
Same for opinions on how much logging or code comments should there be, stuff like dynamic SQL generation vs DB views and a bunch of more nebulous things, though often with a quality of life impact instead of something so concrete as above, where pages started taking 20-30 seconds to load once the DB was properly populated with a lot of data.
So yeah, absolutely do your best effort and try to orient yourself towards open minded egoless developers in a cooperative environment. But sometimes that's not what life will give you and you might just realize "hey, naah, person X is the problem 100% here but it might be possible that I cannot do anything about it in this environment". I've also been person X, of course, but in general I think more honesty would be good.
Like figuring out why our national e-health project failed so badly as it did and putting the people responsible for the failure in jail after a proper root cause analysis is done, if they didn't seek proper remedies in an adequate amount of time: https://www-lsm-lv.translate.goog/raksts/zinas/latvija/09.04...
Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it.
I got into this career because I like mucking about with this kind of work. Programming is sort of like building thought sculptures. Ok, maintaining them too. I spend a lot of my adult life working with these systems, so of course I care about their quality.
It is unpleasant to work on a hack-filled creaking monstrosity of a codebase. My skills, such as they are, don't help as much as it feels they should, because I rely heavily on understanding a system based on how it sort of has to work given what I know about the constraints, and hacky systems constantly confound my expectations. That means I have to spend way too much time and effort learning the idiosyncrasies and unpredictable corner cases, and so have less time to make the changes I want to make. It's like a carpenter working on a house where nothing is straight, nothing is level. Or a cook given flavorless or half-rotten ingredients to use. You spend more time picking out the bad (or picking out the good and discarding the rest) than actually cooking.
Any my scope is limited. Some changes are just not feasible to make, because there are too many hidden and/or unnecessary dependencies buried in the code. If you change one thing, everything falls apart. If you patch it together well enough to more or less work, you're faced with a long tail of subtle bugs that you'll be battling for a long time to come. There's no conceptual integrity.
Furthermore, working with a team that accepts a never-ending accumulation of creeping technical debt is also unpleasant. You can't trust that a positive review means anything. If you try to do something right and take pride in your work, your teammates will be resentful that you're not closing your bugs fast enough. Who cares that it means less maintenance overhead in the future if nobody's planning on sticking around, or people are depending on things being constantly broken so that they can spend their days knocking off relatively easy whack-a-mole style bugs?
Bad code is actually fine. It happens. But I want to know why the code is bad, whether the reasons are defensible or not. If they aren't, I know that the codebase is going to be littered with similar crap, and that my job is going to suck. That's what bothers me so much. This is true even if I'm the author of the bad code. Why didn't the reviewer point it out? Is it like the article said, and there's nobody competent enough to spot glaring issues? That is also a component of a job that sucks.
> Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it.
Well, I don't know that we can separate external forces from why people might dislike bad code... being held to a standard that is unachievable because of someone else's mess and someone else's expectations is all too common in life, and the reality is that your livelihood might depend on meeting those expectations. If you like programming, you might also like maintaining or refactoring code; it goes with the territory, and it can be fun to see how something can be improved or challenge yourself to see how far you can improve it. But it tends to be less enjoyable when your ability to eat and house yourself rides on someone else's bad code.
> If you try to do something right and take pride in your work, your teammates will be resentful that you're not closing your bugs fast enough.
Right, but why would they resent that? Probably because management has expectations on the team, and they are concerned that you're sandbagging the metrics. It ends up being a management or cultural problem regardless.
> Bad code is actually fine. It happens. But I want to know why the code is bad, whether the reasons are defensible or not.
Agreed!
> Well, I don't know that we can separate external forces from why people might dislike bad code...
I'm not denying the validity of the reasons stemming from external forces. I'm just enumerating a bunch of additional reasons why developers might have a problem with bad code.
>> If you try to do something right and take pride in your work, your teammates will be resentful that you're not closing your bugs fast enough.
> Right, but why would they resent that? Probably because management has expectations on the team, and they are concerned that you're sandbagging the metrics. It ends up being a management or cultural problem regardless.
Heh. That's definitely a valid and common reason for resentment, but again I think the resentment can arise from more internal reasons as well. Even the craft coders recognize that you can't polish forever, and if one person spends 90% of their time polishing, then effectively that requires the others to pick up the feature work slack. That person is leaning on the rest of the team. It might be sometimes the right thing to do, but if it's a perennial pattern then even a team with 100% anal-retentive craft coders is going to get annoyed. Possibly because it cuts into their polish time, so they end up shipping worse code than they'd like.
But then, I'm not sure we're even disagreeing. The above could be labeled as "cultural". I think of the internal/external distinction as one where it's internal to the team vs imposed by management.
sandbagging or messing with metrics is an inevitable part of playing a role in $BIGTECHCO. Even if people don’t admit it or aren’t aware of it, it happens everywhere. If anyone resents it they just resent you’re doing it better than they could. much of what we do is all a political game. I’ve had situations where I cannot do something that clearly needs to be done, I in the past will find reasons to slow things down and point to (thing that needs to be done) as the reason why. Eventually the manager above you will prioritize it or discipline you. If you’re right and are valuable and your manager isn’t stupid, you’ll get your way, and they can take credit for the sudden velocity gain. I’ve also done the opposite in speeding things up to expose brittle unsustainable processes.
Not endorsing it, but, it just seems to me the way most performance management works at these companies (I came from a company that liked to think it was amazon with stack ranking) you have to do it or you will get shanked inevitably before you vest. This is just my personal experience. TLDR it’s how you make things “happen”
It’s very cynical. Thankfully these days I work on much smaller teams where everyone helps as much as they can because you’re constantly treading water, but there’s very little room for this kind of political maneuvering and bs.
> Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it.
From the perspective of the organization that pays you to do it, it is? At best there may be another mission that it genuinely cares about, usually there’s only a profit motive (which is also fine). If you want to create software as an end in itself or enjoy the craft without compromise, it usually can’t be in the context of a job or a business
Our job is to produce the best possible outcomes given the constraints we’re faced with, and inform leadership so that they’re aware of the tradeoffs when they make their decisions. Sometimes those decisions are going to be bad, and obviously it’s justified to be frustrated then. Other times they are correct, even when it means compromises on the engineering side. That’s when we have to just suck it up (or go elsewhere)
I still think there’s room for enjoying the work of creating software even under imperfect conditions. Striving for perfection is for hobbies, or the very rare circumstance when it’s justified by the goals of the organization
> From the perspective of the organization that pays you to do it, it is?
I agree. I'm just saying that if you limit yourself to explanations from that perspective, you will miss some of the explanations and be unable to describe real-world phenomena.
> If you want to create software as an end in itself or enjoy the craft without compromise, it usually can’t be in the context of a job or a business
Sure, but that's an extreme position. Maximizing the "ship features that make money" end of the balance doesn't end well in the long term. Maximimizing "all code must be perfect" also doesn't end well. There is very much a place for an appropriate amount of craftsmanship, and businesses do better and even make more money in the long run if that isn't choked out. ("Appropriate" varies widely by situation.)
I'm currently leading a team in a group of teams responsible for a terrible code base. It's riddled with tech debt, our DB is maintained by others and has absolutely atrocious performance, it often feels like I'm the only one who cares about all our tech debt, typescript errors, linting errors and browser warnings, and I worry that the reason I'm the only one is that I'm the most recent hire. I still care.
I'm now spending my weekend thinking about a problem where a really urgent feature I wrote doesn't work because the query behind it is too heavy for the database (the query isn't anything special, but it's against a view that clearly isn't properly indexed), and the DB people are complaining I'm overloading the DB. But it's going to be shown to the regulator for some important regulatory rule for which noncompliance is costing us tens of millions per year. Next Tuesday. Which they told me last Tuesday.
How am I supposed to write good code in that kind of environment?
Bad code bothers software engineers because it is often a reminder of their lack of agency in those companies.
Yeah. It's also painful to look at something that you know is worse than the alternative, but no one agrees with you or cares.
There’s another side to this I see - and have been guilty of committing - where “it took so long because I found some code that felt wrong and while trying to fix that I found something else that felt wrong and while trying to fix that…” at some point you just have to settle for making one thing better and then getting the job done while leaving some other ugliness still in place.
The complaints in this thread seem to ignore cases like that and I’m not getting the sense that it’s because everyone is spectacular at avoiding rabbit holes.
Agree. I get accountability for code I had no control over. That's a setup.
"You’re a senior engineer - why did fixing this take so long?” This is also maddening: it's not a question arising from technical indight or a management strategy ala Drucker, ishikawa, or any other serious approach. It's a guilt trip: it's like saying why did you dress so bad at this party? It's manipulative. And nobody likes these smeer tactics.
> “You’re a senior engineer - why did fixing this take so long?”
Now add "Why can't you use/ask AI agents to fix it?" which is being shoved through your throat by management.
have you ever worked with pivotal Labs? One of my biggest faults I guess is that I worked with femme and they have such an incredibly high bar for understanding, design patterns and cyclomatic complexity and solid and test driven development principles and so forth that once you've worked with them, anywhere else you go is going to feel like a dumpster fire. so then you'll just pull your hair out thinking everyone's an idiot, even if it's really just a lot of bad incentives.
[dead]
> Why does bad code bother engineers so much?
Others have said some true things but the core is missed. It bothers engineers who care about mastery. It’s the same for architects who see design flaws in buildings that were done by those who don’t care about mastery. Or a filmmaker who watches a movie with lots of flaws. Caring about obtaining mastery means having the capability of seeing the flaws and resolving them.
It could be maturity to resign to powerless forces or it could be the inability to obtain that mastery or the willingness to let go of that mastery. I would think it’s more mature to fight the good fight, but at some point you just get old and tired I imagine. And it’s interesting to posit the author is nihilistic when this “uncontrollable forces” itself is a nihilistic take imho.
there’s like 7 of these mastery-seekers worldwide
I don't think that's entirely true. Seeking mastery does not imply being a master.
If you have only ever seen one pattern to solve a problem, trivial example of inheritance, and therefore do that to the best of your ability then you have achieved mastery to your ability. Once you see a different pattern, composition, you can then master that and master identifying when which is suitable.
Lack of mastery is just using inheritance despite seeing alternative patterns.
Naturally mastery also includes seeking alternative solutions but just because a codebase uses inferior patterns does not mean those that came before did not strive towards mastery, it's possible that they didn't know better at the time and now cannot get the time to revise the work.
There's always a juggling act in the real world.
Assume incompetence and not malice, and incompetence is not a state of being. A person without experience can be seen as incompetent but quickly become competent with training or experience, but the code they write still stems from incompetence.
Strive to see your previous self as incompetent (learn something new every day)
Hard disagree. I’ve met at least 7 in the course of my career alone.
7 out of 4 million active SWEs sounds about right :) how many codebases have you personally seen and went "holy shit, this is masterful/flawless/..."? even just libraries as codebases is most definitely 0...? our industry is basically few solid competent people followed by an ocean of mediocrity and incompetence... always been that way and always will be the way
I don't think it's possible to write a flawless codebase. That doesn't mean SWEs don't seek mastery of their craft. Moreover, achieving mastery doesn't mean you would actually want to write an 'ideal codebase', that seems like an art project disconnected from the purpose of the craft.
“mastery of the craft” is a myth… whatever codebase you see (and I’ve seen more than I can count) you will go “wtf is this?!” over and over again. furthermore, whatever codebase someone was lucky enough to initially start with, after X amount of time you asked those same masters (if they are still around) and they will inevitably tell you “oh boy, if I can start this over, I would have…” there just is no mastery, there are just people that deeply care about what they are building and try their best not to F it up along the way but all the “craft” and “mastery” talk is just empty words people talk around fireplaces and/or at various conferences where people pitching “craft” and “mastery” and “you need [insert dev process du jour XP/agile/…]” are there to make money selling the bullshit
I think you are conflating mastery with some kind of beautiful codebase that is completely obvious to everyone else. Einstein had mastery over physics and yet his ideas required a lot of studying to understand and explore.
Engineering is the intersection of science and economics. You build the thing as best you can with the knowledge you have and you often discover things you didn’t even know once you start building. Combine that with time and resource limitations, and you have to make reasonable short cuts to deliver things.
Also remember that even if there’s one master on a codebase, organizations often pair them with many non-masters to try to accelerate things. What that looks like then is a mish mash of things that don’t make sense because the master is struggling to maintain a coherent vision that other people are executing; it’s hard to develop consistency even when there’s just one person let alone a broader team.
But your benchmark is fine if one master can show another master a codebase and explain why the pieces are there and which pieces are shortcuts and what the vision is. Trying to develop that knowledge by yourself in the middle of the dev cycle is a fools errand; one of the first things I do when I come to a codebase is ask a bunch of questions to build up my understanding of the history of the codebase and why things were done a specific way.
I agree with literally every word you wrote. But what is this “mastery” or “craft” then? if we agree (rightfully so) that some special people exist, eventually (or immediately) other people get involved, we as industry accept “we had a deadline so it was cool to ‘cut corners’ etc…” - where is mastery or craft in this process?
I have and I am sure you have worked with some amazing people over the years but to me our entire industry is so far removed from anything resembling mastery or craft that even mentioning it at this point in my life makes me chuckle (and at times literally laugh out loud)
I think people have a very weird notion of mastery and think it looks very different in other fields. That’s because mastery no longer looks like mastery once you attain it. Mastery also doesn’t look like the absence of imperfections - even art house films by master auteurs will have imperfections the masters will see and compromises they had to make to get a film done. Talk to a master builder and they’ll instantly start pointing out flaws in buildings. Electrical grids regularly see outages despite.
So my question then is how would you define mastery if you believe our industry doesn’t practice it.
if you have ever “cut corners to meet deadline” is where I’d start
Can you give an example? Every art, industry, or discipline I’ve ever read about has masters doing this.
I’m shocked to hear how different your experience is from mine. I very often see good code and bad code and the difference is very clear, even years into a project.
> Why is it necessary for big tech companies to act this way?
This question gets directly at the cause of the author's nihilism: the necessity is borne from the endless pursuit of positive quarterly growth, the "binding fiduciary duty to shareholders". Which is a lie, there is no such legally binding fiduciary duty. So the aforementioned necessity is also a lie. Companies could operate on a longer time horizon, let engineers write better code, make better products, maybe even consider societal good in their strategic planning, and still turn a healthy profit. But the cost of perhaps taking a few degrees off their YoY trend line is unacceptable to the insatiable greed of their controlling shareholders.
Fuck Jack Welch
Interesting. Coming from big tech, it's actually pretty spot-on of an article. I think most folks at big tech have experienced this stuff too.
> Why is it necessary for big tech companies to act this way? Why does bad code bother engineers so much? Are they actually misguided for feeling like bad code is a catastrophe, or is it really the fault of the broader economic sphere we all inhabit? Is it actually maturity to 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.
I don't disagree that it's an accurate portrayal of reality. And of course, as I made clear in my post, I don't know if they're actually a burnt out nihilist.
My issue with the article is maybe more that the perspective and framing seem to want to lock out idealism from the conversation and encourage people to become ruthless, hard-nosed pragmatists in order to survive in this environment. Is that actually good, effective, or desirable? Again, lots of questions.
My feeling when I found this blog was "so I'm NOT the only one!". It's the painful truth about staff+ engineering that I've also experienced, but haven't felt safe to talk about.
You're not wrong that there's something cynical or nihilistic about it. The core thesis is "do what the company wants, even if it's not what they should want". That idea may be unpalatable, but getting ground up in the corporate gears is worse.
Having tried both I would rather be ground up again than just accepting my fate. I rather die fighting than the alternative.
My personal feeling is that there's a way to both agree with the underlying issues Sean writes about while being more optimistic and providing better alternatives. Something I feel I should start writing about more.
I think one of the issues is that engineers define bad code on a different set of dimensions than the business, and even amongst each other. Early in my career I was definitely guilty of this, that if the code didn’t fit my definition of perfect code, it must be bad. I’ve met great programmers (I don’t consider myself in this group) in my career who put even more strict criteria on something to be considered ‘not bad’. Then I worked at small companies, big companies, was an owner at one, and my definition of bad code narrowed. While my criteria are still subjective, if the code meets the business goals and a baseline of quality I consider it fine. Because outside of some absolute genius programmers like Carmack, few of us will look at someone else’s code and not think of any type of improvement.
I've come to quite a specific definition of "bad code", at least the main form of bad code that infests corporate environments. It's overly complicated code, but people disagree on what that means too, and I have a concrete definition of that now.
Bad, over-complicated code is code that requires you to form an unnecessarily detailed mental model of it in order to answer a particular question you may have about it.
People rarely read code in its entirety, like a novel. There is almost always a specific question they want to answer. It might be "how will it behave in this use case?", "how will this change affect its behaviour?" or "what change should I make it to achieve this new behaviour?". Alternatively, it might be something more high level, but still specific, like "how does this fit together?" (i.e. there's a desire to understand the overall organisational principles of the code, rather than a specific detail).
Bad code typically:
* Requires you to read and understand large volumes of what should be irrelevant code in order to answer your question, often across multiple codebases.
* Requires you to do difficult detective work in order to identify what code needs to be read and understood to answer the question with confidence.
* Only provides an answer to your question with caveats/assumptions about human behaviour, such as "well unless someone has done X somewhere, but I doubt anyone would do that and would have to read the entire codebase to be sure".
Of course, this doesn't yield some number as to how "complicated the code is" and it depends on the question you're asking. A codebase might be quite good on some questions and bad on others. It can be a very useful exercise to think about what questions people are likely to seek answers for from a given codebase.
When you think about things this way, you come to realise a lot of supposedly good practices actually pessimise code in this sense, often for the sake of "reusability" of things that will never be reused. Dependency injection containers are a bête noire of mine for this reason. There's nothing wrong with dependency injection itself (giving things their dependencies rather than having them create them), but DI containers tend to end up being dependency obfuscators, and the worst ones import a huge amount of quirky, often poorly-documented behaviour into your system. They are probably the single biggest cause of having to spend an entire afternoon trawling through code, often including that of the blasted container itself (and runtime config!), to answer what should be a very simple and quick question about a corporate codebase.
>People rarely read code in its entirety, like a novel. There is almost always a specific question they want to answer. It might be "how will it behave in this use case?", "how will this change affect its behaviour?" or "what change should I make it to achieve this new behaviour?". Alternatively, it might be something more high level, but still specific, like "how does this fit together?" (i.e. there's a desire to understand the overall organisational principles of the code, rather than a specific detail).
+1. For me the most frustrating one is "where is the core logic for this one user-visible feature actually implemented?"
You look in all the obvious places and it's just nowhere to be found. Or it's shredded into tiny pieces and scattered across multiple files and seventeen layers of inheritance ...
It's hard to write about the broader context with any expertise in a blog post written from personal experience.
My own thinking is that the big competitive advantage that big tech firms have over small ones is the power to mobilize very large numbers of developers onto a project.
Large projects that don't depend on a small core group of irreplaceable competent individuals are more repeatable for a business. So it makes sense to focus on making the repeatable processes more likely to succeed than simply hope that you happen to have the right team assembled for the job.
Assuming that any of your engineers are above or below average hurts the ability for the business to plan.
big tech firms advantage is privileged access to public money, without focus on quality or cost. Good products start small.
True but this isn’t something big tech innovated. This is exactly how most large organizations work. For example, and specifically in the military, servicemembers are fungible and they are rotated every 2 years. The military even encourages attrition at certain ranks and points in people’s career.
Yep you just rediscovered alienation
https://en.wikipedia.org/wiki/Marx%27s_theory_of_alienation
Whoa. Who's this guy? Sounds like he might have some answers to some of my questions!
I think you are ascribing too much into this. If he does not believe anything then there will be nothing to write about. It looks like he does not believe in _your_ ideals - that does not make it nihilism though.
You are being a bit unfair to the author, but I think I know where you are coming from in this argument.
The writing comes across as “well this is the way it is and this is why it is.” That’s fine, but most of us kinda already know why it’s the way it is.
Maybe, tell us something about how to adjust the culture.
> 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.
Nihilism is a defense mechanism when everything is moving against your world view.
STEM people of all walks of life join because of the challenge, the loveliness of an elegant solution, and the “art” you create that leaves your mark. Good engineers view their code as a makers mark. This code represents me as my art and I should do my best. Unfortunately (or fortunately) this is beaten out of you by senior engineer and the shell left is a nihilist and misanthrope.
Corporate programming strips you of your creativity, your autonomy, and your drive. It’s simultaneously strict, but too loose where it should matter. It’s spastic in its execution. There is often little rhyme or reason aside from “build fast make money”. No one appreciates your contributions. You show up to meetings where sales and PMs simultaneously wrestle to take the credit you rightfully deserve. You made it 10 years, here’s another low budget pizza party while the sales team gets an all inclusive in Ibiza. You wanted to make cool, elegant, things, and instead you’re just a factory worker that had to do 7 rounds of interview for the privilege of stacking premade widgets together until retirement.
The end result as I and many engineers at and over the one decade mark have realize. Nothing matters, no one respects you, and no one truly cares. You get paid and promoted whether or not your code is elegant, or safe. You get recognized by prostrating yourself in front of leadership. So why should I give a shit if my code works or not. It passes tests and I get to eat.
The industry is pathetic and we should stop calling ourselves “engineers”. Modern corporate programming is analogous to working on a widget assembly line in the limit. Most of us simply find our joy elsewhere and have learned “hearts and minds” as the rule of corporate life.
I can find an experienced doctor, plumber, musician or mechanical engineer that was doing it 50 years ago.
I’m not going to find someone that was doing software 50 years ago. And if I do, their experience is completely unrelatable.
I worked on compilers and tools starting in 1981. Proprietary compiler technology has disappeared over the decades and the development tools/language/process/compute have changed considerably. But the skills and role of a compiler developer seem similar, although maybe it just means this sub-field of software has matured.
That's one of the many many reasons I miss my dad so much. He went straight from MIT to GenRad circa 1970. I didn't start doing software till 1998, but we had some years of overlap -- and it was profoundly gratifying to connect w/ him on engineering topics. The learning was even bidirectional tho I'm sure I got more out of our pseudo-professional interactions than he did. Sigh. I really miss him.
Bad code bothers engineers because it is fundamentally wrong to write bad code. It goes against the nature of things.
I think the engineer jumping between giant companies for three years or less every time rarely works on particularly key things. Big tech companies do a LOT of stuff, and most of it is crap that isn't moving the needle. This post describes teams that are constantly changing priorities (chasing trends?) and IME that's not true of the really core, central functions at companies. But very true of the "support/enabling" or "what else can we do?!" side functions.
For instance, Github Actions being a meh product is called out in the article - that's a classic "check the box" feature that's good enough for a lot of people (let's not forget that Jenkins was no picnic before it) but is never gonna massively increase GH's bottom line.
Those sorts of projects are easy places for politics to fester since they are easy to ignore for the most influential-and usually strongest-parts of leadership.
On the other hand, if you're on a core, mission-critical team and other people's code is turning into your bad performance review, you need to figure out if the problem is (a) bad/toxic manager or (b) a failure to keep your management chain informed at what the root issues are and how you can improve it.
Every time I read his article I regret it. I literally mean every time, 100% of it. Judging by the title of the article, I didn't expect his reason to be "engineers working outside their area of expertise". I've seen good engineers figure out problems outside of their expertise plenty of times, so that's not a good reason either.
I feel like this article is the equivalent 16 paragraph stating you're likely to be correct only 10% of the time when you guess a random number from 1 to 10
> 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.
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.
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
I find this insightful. Would you recommend anything in particular to get there? Other than staying frugal and being competent at your job?
Few things that I would tell my kid of she was starting out in this industry today
- never work FAANG or any bullshit company like that
- look for companies that are small (up to 100 SWEs max, preferably 1/2 that) that have solid business (20+ years, profitable)
- when you get hired volunteer to fix every problem everyone else is running away from (there will be plenty). you will work hard in the beginning to understand the nuts and bolts of everything
- along with nuts and bolts of the technology / stack / ... learn the domain as much possible (so much so that you could get a job tomorrow in that domain, e.g. if your company is providing software for automation of say state&local courts then you need to learn everything there is to learn about state&local courts so much so that you could legit get a job as a court administrator)
"soon" you will be the first that:
- fixes all the issues
- puts out production fires
- is in every meeting
- ...
there are other ways to do this but this 100% is one of them...
Excuse me but this mostly sounds like a recipe to be burned out extremely quickly, and also blamed for everything.
I think your ideas are sound but they very generously assume competent and somewhat benevolent leadership. Something I have very rarely seen.
quite the opposite on the burn out part… if you are curious (this in my experience is in the top-5 traits of exceptional SWEs) you will instinctively want to learn everything there is to know about what you are building. and do it at your own pace, to use a cliche, this isn’t a sprint, it is a marathon.
the leadership also does not have to be competent, you actually want slight incompetency because competent leaders would not allow project to heavily rely on one or handful of people.
"At your own pace" exists only in a handful of very privileged spheres. Maybe part of the USA scene and that's it. Everywhere else is "fall in line or get fired".
You hiring? I got rejected twice from US companies with the explanation that they wanted to have me and the CTO pushed for having me but compliance does not want people from my region.
Replies like yours are wholesome and nice... but they also assume the only problem is in one's head. I am long past this. I just can't find good companies to work with in the last few years is the chief problem now.
pick your battles. You decide what extra work is worth your effort.
learn to say "no", by which i mean "yes, but...". e.g. "can you look at this production issue?" --> "yes, but it is outside my comfort zone, so i will have to charge at least 8 extra hours of overtime towards that issue".
Sure. The problem is more like that during the interviews I was made to believe this is welcome and on day one I was told in no uncertain terms that I'll follow a script to the letter or get fired. Which ultimately happened.
Shitty luck and all sometimes, of course. But really, most of the HN crows very quickly glances over how many toxic and terrible places to work at exist out there.
Doesn't that just mean you are underpaid?
I think not necessarily. It also means freedom and power.
The flip-side is: you need the money more than your employer needs you. Which puts you in a bad position to negotiate salary, makes it hard to stand-up against bad decisions, etc.
I think that it can (not sure if the author meant this) also mean that you have a buffer and are OK with switching jobs, but are also in a position where your employer wants you (because of something you can do). This puts you in a GREAT negotiation position.
quite the opposite, if you are worth to the company more they are worth to you you can demand high, high, high... rates - especially if you eventually make the right choice and go 1099-way
It means that we are okay with being exploited and that's almost universal except for the sociopath class
> this is a deliberate choice to make labor less powerful...
To be fair, though, I don't trust modern labor either if they can't figure out how to NOT vote for a rapist pedophile real-estate billionaire. Twice. Including a pandemic and a coup.
What a mess we find ourselves in.
I think labor is worried about a bunch of practical things that the Democrats didn't know how to communicate and Trump did.
Did he mislead them? Yes but honestly, so did a lot of Democrats.
All that to say, yes, but Capital has a lot more resources available to mess with people's head.
Idk man, I'm pretty sure there's more going on than that. Look at this study for example https://link.springer.com/article/10.1007/s11109-024-10000-8
Normal people would become more liberal.
Or look at how badly teachers are treated https://www.census.gov/library/visualizations/interactive/te...
Or look at the way Americans punished Democrats really hard after Obamacare https://www.quorum.us/data-driven-insights/under-obama-democ... Democrats won't make that mistake again of listening to Bernie any time soon.
Or look at how bad the coronavirus response was, for such a rich country.
Something's deeply wrong with American political culture, like from watching too much Game of Thrones or something. It’s not just being misled, it’s ingrained.
I think for many Cruelty <=> Power. Like how guns make them feel powerful. I wasn't born here originally so I don't really get it (thank god). It won't end well.
Has it been many people's experience that big companies intentionally remove experienced engineers from your team to something unrelated, in the name of fungibility? I've surely seen efforts within a team to make sure that there's not a single person who's necessary for the team to reach full productivity, and I think most would agree this model does not make for resilient teams. But many of the best engineers I know have had much more energy invested in getting them to stay than to leave
We just went through a ton of layoffs, while those companies are making record profits.
Software engineers themselves curse each other out if only "Bob" knows "his" code. So it's not only management.
[dead]
Maybe it's things like 4-year tenure, or shorter tenure, or something else.
But I think it's a matter of motivation, Bob.
> The thing is, Bob, it's not that I'm lazy, it's that I just don't care. It's a problem of motivation, all right? Now if I work my ass off and Initech ships a few extra units, I don't see another dime, so where's the motivation? ... my only real motivation is not to be hassled. That, and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.
No, big tech engineers are highly motivated. There's lots of money, good management, and plenty of incentive. (I'm a Google engineer myself).
The problem I observe is a fairly universal one: management doesn't care about good code, it cares about results.
It's generally hard for anyone without specific experience with a codebase to tell what you're doing with it. Management can't evaluate the value of maintenance work, so it doesn't value it at all.
People who ship sloppy code get promoted.
> The problem I observe is the universal one: management doesn't care about good code, it cares about results. It's generally too hard for ANYONE to tell what's going on in a codebase unless you're experienced with it. Management can't evaluate the value of maintenance work, so it doesn't value it.
I think this is a very telling statement, but perhaps not in the way you intended. I would agree that management only cares about results, but I would posit that maybe that's a good thing. If you don't have ground-truth knowledge of a problem, you must rely on either the word of someone who does, or metrics that can be used as a yardstick.
When all a manager has to go on is someone's word, it can be really hard for them to gauge the depth, severity, and impact of the problem being expressed to them— and without any metrics, they have no way of tracking progress on resolution. In a modern codebase, you could spend YEARS on improving maintainability and still not "finish". The key (that I've found, personally) in this situation is to give the manager some form of metric to describe the problem. If you can establish a number to measure what you're advocating for, and quantify the consequences of not doing it into actual business impact, I've talked managers into taking my suggestion more often than not.
> in this situation is to give the manager some form of metric to describe the problem
how do you have a metric to measure a future issue that got prevented by having good maintenance?
Either you cannot actually imagine nor describe the problem that was prevented, or you could just make something up which cannot be disproved nor falsifiable. So if you asked for time/resources/budget to do maintenance, you cannot then give proof that this maintenance was useful!
The only way to get a metric is to have an incident or have issues crop up, and then in the retrospective, claim that certain maintenance work could've prevented it.
Why is the manager unable to understand? Maybe he should be able to in order to manage.
It's because the only people who can understand the code are people who write the code every day. And sometimes the devs don't even really understand it.
Occasionally you'll have a manager who manages in the day and codes at night, which is fine if not bad for his personal life. But HIS manager almost never does that. And his manager's manager? Forget it.
To be fair to management, it is the results that matter.
Management cares about what their management cares about. So this boils down to what the CEO cares about. The CEO cares about what the board cares about. The board cares about share prices going up.
I do believe that e.g. retaining engineers is something that helps the business. It's stupid that someone ramps up for 2 years and then goes to a different job just as they start becoming really effective. It costs companies a ton of money which they could instead just use to get people to stay. But I'm not on Google's board. It's only when Google board decides that fostering the right engineering culture is important enough for the business that something is going to change. And so far- they don't (s/Google/BigTech).
Re: Incentives- Obviously(?) the incentives are not right. So when you say "plenty of incentive" what it really means is incentive to ship sloppy code and get promoted. Or the incentive to go from Google to OpenAI and get a pay increase or whatnot.
> To be fair to management, it is the results that matter.
To be fair to me, I don't recall ever signing a contract through which I am directly responsible for the company's financial and customer-acquisition / retention efforts. I sign up as an individual contributor who helps advance the customer & product mission forward. I am NOT a cofounder.
So that shows, yet again, how myopic and egocentric managers are. Wise ones -- the all 2-3 I have met throughout a 20+ years of experience -- understand that they must enable you to produce the outcomes they care about.
Unsurprisingly, I worked fantastically well with those managers and we achieved near-miracles in some measly 4-5 months.
But all others? "I never gave you time to optimise cloud spend but now I am angry at you for not doing it in your sleep", more or less. Or "I pushed you to the brink of 12-hour workday regularly and started reaching into your weekends and you rushed that feature I pressured you for and it has one small performance regressions? You are fired!". Deal with it.
/rant.
Not directed at you, obviously. Got triggered a little.
We need to disconnect the question of bad managers from the structural issues though. I try to be a good manager but I still have people jump ship for better comp and where we won't match it. I still need to deal with an incentive structure that doesn't match what I am trying to do with my team.
This same structure is also what helps bad managers. Who is going to get promoted to a director role? The person who stands up for their team and argues with the VP or the person who toes the line? The things that you think are near-miracles are not visible and the people that play politics will make their stuff look more valuable to the company.
/rant I guess ;)
Yours and my experience are not mutually exclusive, I think we both see it. I dream of managers like you but I never get hired under them for some reason. (Likely regional culture, experience shows.)
I'm at a stage of life and career where I'd happily take a small pay cut for a year just to establish myself in a place and have stability. Then we'll talk about competitive compensation.
My chief issues are with people that are best described with the proverb "give them an inch and they will take a mile".
Yours seems to be that you deal with people that constantly think that they can do better in terms of how much they take home (let's not sugar-coat it, they're spoiled -- I was too).
Heroics being invisible and people who have their coffee with leadership getting the money and the influence is the wrong system. Always was and apparently always will be.
I'd say it somewhat differently:
Management doesn't know how good the code is. So they can only look at results.
Like you say, this easily ends up rewarding people writing quick and dirty solutions.
This problem is easy to describe and hard to solve. Yet some teams do it much better than others. One solution is that management also writes code.
It's interesting that you talk that there's a lot of good management, followed by a list of things I'd call bad management: Forget about good vs bad code, of course that's unimportant. But insufficient maintenance that causes lower velocity on the next set of changes matters. Good engineering will tell you when the issue isn't just about code that is ugly, but code that slows changes down so much you'd be better off improving it.
If you set incentives that say that being sloppy and leaving landmines for the next group of people is the way to get promoted, guess what? the management is bad. Often because they are also looking at their own self interest, and expect to leave the consequences to whoever comes after them. This isn't new to big tech: You'll find this all described in books about corporate dysfunction written in the 90s.
It's all traditional principal agent problems, which just get worse and worse as you add layers of management, as the principal has agents upon agents underneath, all using the misaligned incentives. One either wants t avoid getting fired while doing the minimum, or sacrifice the health of what is around them for a good enough promotion packet/review. And since there's no reasonable way for individual objectives to align well with long term objectives, people leave landmines. When there's enough landmines everywhere, you are always better off in greenfield development. And at that point, doing any maintenance, or being stuck in a project that isn't getting fed a bunch of capital to grow it is career suicide. All about bad incentives, set by bad management.
> code that slows changes down so much you'd be better off improving it
Note that the minimum amount of time necessary for a change is ~zero. A few minutes in practice because CI checks need to run, but that's it.
Is this facetious? Have you worked in anything remotely bad or complicated across teams?
I don't think we disagree? Bad code makes it harder to make changes, that's why it's bad.
> The problem I observe is a fairly universal one: management doesn't care about good code, it cares about results.
The thing is, good code is a form of a good result. You need to solve the underlying problems (which manifest as impact) but if you used code to get there, that code if well designed is extensible, reusable, then you pay low maintenance on it and that same code can be used to solve other problems (ideally).
It's a difficult judgement call to make though. If your org doesn't have the right technical leadership and the performance management structure doesn't reward it then you get what you see.
It's a lesson that's always learned far too late when it becomes slow and costly to deliver something new because you've amassed so much tech debt so it's often cheaper to start from scratch (which is saying something).
I see this all fwiw in big tech myself and with my peers at peer companies.
> It's a lesson that's always learned far too late when it becomes slow and costly to deliver something new because you've amassed so much tech debt
No, it is just standard operating procedure: deprecate a working system and write a new system from scratch, with 50% of features not supported. This side-steps the tech debt and gives everybody artifacts for promotion. It screws all users of the system but who cares about them!
There are always two systems, one is deprecated and the other not feature complete.
"management doesn't care about good code, it cares about results."
And management is probably right: code is a mean, not an end
It is us, as software engineers, to make that better code brings better results
Some benefits of better code can be:
At my current job, we have some instance of people who animate around bad practices: they scan everything, identifies some "bad practice" (which can be whatever) and then raise the issue to all teams and give them a month to fix the issuesVery political stuff
I try to do good code. My team is rarely cited in that list of "bad players". Management does notice.
Corollary: our roadmap is not messed up. Product managements notices.
Also, good code must mean robust infrastructure. We have very few incident. Almost all our changes are successful. Incident and change managers notice.
Anyway, my point is : if good code brings no benefits to the outside world .. how is it good, exactly ?
Yup, tolerating inappropriate tech debt for too long leads to bad results. I see this going wrong all the time and I thought it was mostly due to being surrounded by bootcamp grads given nothing but year after year of pressure and no examples of what good code can look like. Surprised to hear the same thing happens in big tech.
> And management is probably right: code is a mean, not an end
Absolutely!!!!
Our job is not to produce code, it's to produce a product. Code is just the way we happen to execute that goal.
The thing is shipping sloppy code is orders of magnitudes easier, because that's the default result. Any sufficiently determined hack-job can do it. On the other hand, steering a team of 5-10 engineers to deliver quality on (or before!) a deadline requires excessive amounts of coordination and skill. Now, is this trade-off "worth" the effort? I guess that's a matter of opinion, though I would argue in the long term quality wins out by a large margin.
Sometimes teams will do the sloppy thing because it's the quickest path to resolution of an issue deemed to be critical, which can make sense in the moment, but if you do this too many times without spending the effort to improve the solution after the immediate pressure is gone, issues like this will continue to get more common. I like to use an analogy of trying to put out a fire on the other side of a building by filling a cup in the sink and then running across to toss the water onto the fire; in the short term, it might be the best fix, but if you keep finding yourself having to do this, you're probably better off installing a fire hose even if it requires a lot more effort up front.
slow is smooth, smooth is fast
Thank you!
There 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.
That'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.
So it's a problem of motivation you say
Just linking this here hoping to back you up: https://www.businessinsider.com/block-cto-code-quality-suces...
Yeah, a business funded by debt can often beat one just funded by its own profits because it can scale faster.
But eventually that debt has to be paid off. Don't penalize people who are doing the invisible work of paying it down.
>Management can't evaluate the value of maintenance work, so it doesn't value it at all.
So it's the McNamara fallacy?
Was McNamara really thinking that's how you win a war and people just went along with it or was it just another excuse in a long line of excuses to keep the gravy train going?
Motivation doesn't necessarily help.
I used to be an extremely motivated engineer. I cared about the code that I wrote, the other people on my team, making sure things were documented and understandable. I tried to write good code where I could, and detailed PRs and issue writeups where I couldn't.
Despite that, I was always paranoid I wasn't doing enough, because it always felt like there was someone else that was shipping more code than I was. Some of this was almost certainly social comparison bias and impostor syndrome-like feelings at work; but I also had a string of managers that pointed out all the work I was doing, and how I was helping the team as a whole.
Eventually, the company got acquired by exactly the sort of company this article is about, my manager got a new director from outside the company, and my manager had to go on extended medical leave after a cancer diagnosis, leaving the director with ~7 new reports. I started hearing about how the number of PRs I was opening weren't as numerous as some other people's, and the code didn't look "hard" enough to their glance. Never mind if the easy code was hard to come to, or if talking through it after the fact they agreed with my assessment, or if I had performed a detailed investigation and writeup, or if my peers left reviews or public plaudits about work I had done. Those weren't PRs, which is ultimately were what they wanted, since that was the metric they could easily see, and justify to their boss.
I did _try_ to do better by their metric, though I never had a definition of what "better" would actually be. Funnily enough, that person was fired a few months after I was.
Also kind of funny to me is that, if I weren't motivated and didn't care, none of this would've affected me all that much.
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
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
> 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
I moved teams a few years ago, and the very first thing I did was push hard to re-structure the schema they (sorry, pals) slapped together without much thought. It took some fair amount of arguing, and maybe a PR that I had reviewed by only a single person and pushed through because it's easier to ask for forgiveness, but we got there in the end.
Luckily, we were able to do this before the code started hitting production traffic; it would have been significantly more difficult to fix once we started getting real data into the system.
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
Because businesses, as a rule, value moving fast. Being first to market makes money and generally results in winning.
Oftentimes the circumstances are "we don't know the requirements", not because of shitty management, but because the problem is inherently hard to define.
The business conditions that do heavily penalize bad architectural decisions, like physical structural engineering, can suck to work in compared to SWE.
It takes a decade or more before you're trustworthy enough to architect a building and there's a million layers of approvals. Then it takes years before groundbreaking, and years more as the building increases in size.
Your whole life might be dominated by a single large project like Hudson Yards, which has been floating around as an idea since 1956. The most recent proposal started in 2006, broke ground in 2012, and another 6+ years to finish. Then when companies were about to move their offices there, COVID-19 happened and the leases fell through.
I'd rather the system that gives average SWEs regular opportunities to lead large projects from scratch and make mistakes.
I think you are underestimating how many product problems at big companies are actually bad technical debt. They cant release new features or evolve the offering because the systems are too complicated to change. 1 year of quick development could stunt the whole org for the next five years.
The good news if you take 2 years to ship the system "properly" then you won't have to re-factor it because the company went out of business or that product was too late to market.
There is a phrase "million dollar problems". You do stuff at your startup that will take a million dollars to fix because it doesn't scale.
The point is that if your startup doesn't get to that scale then it doesn't matter. If you startup does reach that scale then you have plenty of money/people to spend a million dollars fixing it.
Replies like yours gloss over nuance. I don't mind prioritizing time to market as a programmer; I am not clueless, I understand that imperfect product that pours money into my employer's coffers is infinitely better than it sinking and we all get fired out of necessity.
My problem comes from the fact that the leadership _never_ compromises and never allows us to avoid at least some crises that are extremely easy to foresee (and have happened like clockwork in 95% of the cases where I or other colleagues have predicted them).
Again, sure, let's go to market and start making sales. I completely agree. But scolding a dev for fixing a DB schema anomaly that slows down ~40% of _all_ feature requests and that it took him the grand day or two to do so, is not just myopic. It's moronic.
---
Even shorter / TL;DR version: If the balance of power was 80% leadership and 20% engineers, I'd still be completely OK with that. But wherever I go the "balance" of power is more like 99% leadership and 1% engineers (and that's only when stuff really has hit the fan; they'd take away that last one percent as well if they could).
That is the problem. There's no balance. No compromise. Just people barking orders.
It is not only being first. It also is about responding to customers - not fun part is your customers don’t care about your app. They have to use dozens of different apps on daily basis, so when you have customer interaction you better be able to do stuff right there because they might be available in 3 months or next year to talk about your app.
I don’t like all the fantasy about “just talk to the customers” - nah it is not just, it is super hard to get their time.
Yep. "Oh you don't have that feature? I'm moving on".
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.
All systems eventually turn bad. The idea that you can gold plate something so it won't is naive. It isn't about getting it right from the start, its about having the will to change it once your system or uses evolve into something that turns it wrong.
A good system, i. e. one that got it right from the start, is one that is cost-effective to change. (“Will” has little to do with it.)
Change in which ways? A system designed to be cost effective to change in any way isn't going to be cost effective to change in a small set of ways.
> 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.
100% this. The architecture is what slows things down (or speeds them up), the code quality, variable naming, all that bs just does nothing.
Totally agree, I've found that as well working in big tech
People focus way to much on the superficial stuff like code cleanliness, formatting, organization, local structure of the code
Because that stuff is easy to talk about, kind of like bikeshedding.
Plus a lot of times code reviewers just want to comment something to show they aren't just rubber stamping it.
Whereas it takes a lot more brain power to think about logic, correctness, and "does the change actually make sense in the big picture"
Part of it too is that as a reviewer a lot of times you just don't have enough context to know if the change makes sense
In the context of reviews my experience has only been code review quality brought up as a negative thing for folks and the bar to not be a negative is low enough that folks slowly take less and less time to review code well because it isn't valued come review time.
>does the change actually make sense in the big picture"
Ideally by the time your at code review this is not a question. It sucks for everyone for it to come up.
I think people also avoid rejecting for this reason becasue of that
Its hard to have good enough requirements gathering and documentation and product design practices to let an engineer really wrap their head around a problem well enough to come up with and then consistently follow a thoughtful, long-term-maintainable design for a system during implementation.
And its even harder to make sure everyone who reviews or tests that code has a similar level of understanding about the problem the system is trying to solve to review code or test for fitness for purpose, and challenge/validate the design choices made.
And its perhaps hardest of all to have an org-wide planning or roadmap process that can be tolerant of that well-informed peer reviewer or tester actually pushing back in a meaningful way and "delaying" work.
Thats not to say that this level of shared understanding in a team isn't possible or isn't worth pursuing: but it IS a hard thing to do and a relatively small number of engineering organizations pull it off consistently. Some view it as an unacceptable level of overhead and don't even try. But most, in my experience, hope that enough of the right things happen on enough of the right projects to keep the whole mess afloat.
Eh, its either that, or the wrong people are getting promoted. Technical skills != business process modelling
I've seen too much of the same. It strikes me that the pattern you describe also matches a lot of AI generated code I see, especially when it's big chunks of generated code. Are we automating this problem and going all-in on the long term costs?
100% yes. The most dangerous developers you’ll ever work with are the tactical tornadoes who crap out extraordinary amounts of code that mostly implements the exact feature that product asked them for with zero thought given to any other concerns.
AI makes these types of developers much more dangerous because they will accept anything the AI generates tha looks like it works, and they’re experienced at pushing nonsense through code reviews.
AI also provides more of a “productivity” boost to these types of developers because unlike everyone else they actually spend the majority of their time typing code.
> Are we automating this problem and going all-in on the long term costs?
I feel that is a very likely scenario.
This was the case before AI tho, people were copying coding patterns from companies randomly even without understanding. I mean there was an interview with some DoorDash architect that literally stated that whatever their architecture was just fad chasing at that moment.
Every company I've ever worked at (from ISPs to health insurance to finance) every organize was just copying the fad of something else.
At the time I felt like it was because that was "the best way" but it was more likely do to engineers not having the freedom to actually explore good solutions. The made up constraints imposed by organizations against their workers are rarely for the benefit of the company.
It's not a surprise to see this being the case, most companies on the planet are ran like centrally planned dictatorships with the results being obvious in retrospect.
Yes, it was the case. AI just magnified the severity by an order of magnitude or two.
Well obviously this is the same code the AIs were trained on.
Catching architecture problems in code review is usually a red flag for process problems. Anything substantial should have been reviewed for architecture prior to a code review, especially if it spans multiple commits. Code review should feel rote and focus on rubrics around style and best practices in an ideal case. Of course you will still find architectural issues during code reviews in many cases but that shouldn't be often as it's not reliable to expect the reviewer to have the necessary context to catch them.
It's getting much worse with AI now too. People just blindly trust the AI's decisions which even as of Opus 4.5 is generally misguided for nontrivial problems and best-case doesn't even consider the bigger picture given context-window limitations.
So the mountain of syntactically correct functional slop is growing faster than ever before.
The 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?
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.
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.
It is possible that some projects like Oracle are beyond hope but in general cleaning up a messy code base is done piece by piece and by refusing to merge most patches which make things worse. Better than you found it is the main principle.
Just wanted to comment on the fact that I remember seeing that comment, and it left such an impression I remember it 7 years later. Thanks for the reminder, going to bookmark it this time.
Rewriting from scratch is also included in "take a few hours to ponder architecture" contained in your parent comment.
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.
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.
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
> I'd go further and say you're not a senior if your code isn't good you shouldn't be a senior.
You say that until you are tasked with doing impossible - three lines, all perpendicular, five green, two anti-green, seven in ten or more dimensions, any color; while customer only uses purple lines.
Last guy that worked on it committed seppuku. Rest of team is in mental ward. Your only team member is guy that programmed his entire life in PHP, and doesn't know backend's language. Just teach him.
Documentation, is spread between Jira, wiki, Markdown, ftp server and some napkins.
CI stands for continuous Indians. You send code to India, where a team will assemble it. It may take anywhere between a few minutes or few hours. But it beats GitHub actions. Make sure to inspect artifacts, the Indian team has a habit to add some of their ""bug fixes"" covertly.
But you gotta finish it by Thursday. Good luck.
Words aren't absolute. No reasonable interpretation of my comment suggests I'm saying you should do the impossible.
If someone asks you to do the impossible you have to say no. Better yet, you should figure out what they actually do want. They can't get the impossible, that's not on the table.
The worst thing an engineer can do is not learn how to say no.
I'll even say, if you don't know how to say no then you're not qualified to be a senior
My CTO, when told that adding scope, reducing headcount, and keeping the same timeline all while discovering new unknowns in the codebase was not possible, we were simply told to make the date and asked who's performance review will be impacted. The "no" was entirely ignored. "I don't accept that."
How do you say no in that situation? Just quit?
I think bosses are like cats, when training them you have to make it think it is their idea. As I said in a sister comment the best way to do this is to not say the word "no" but to ask clarifying questions[0] so that all the puzzle pieces get placed on the table. Together you can assemble most of the puzzle, taking the lead but not lecturing them. But the final pieces have to be put together by them. Management is egotistical and if you just tell them then they get upset.
Your loyalty should be to the company, not the person. So by just "falling in line" you are failing the company.
Remember, if the project fails (and it will fail if it is impossible) people get fired anyways. Sure, getting fired later is better than sooner but it is still gonna happen.
[0] In your exact case, find out what they are actually after. Sounds like it might be a budgeting problem and they only know how to pull a few levers. They're business people, not technical people and they're working in a world that is highly technical. They're really a fish out of water and they don't know it[1]. It might be greed or panic too, which are harder to deal with and in those cases yeah, you should start looking for new work.
[1] I'm not saying a techie as a CEO or in a management position wouldn't be a fish out of water either. That'd be similarly as naive. But a well functioning workplace has to understand that these are different skillsets and we have to intermingle. You can't know everything so we have to work together to leverage our niche expertise.
I get the feeling you didn't work in a dysfunctional company.
Here is some anecdata. I came onto a team, that had team lead, product owner fight tooth and nail to not use boolean special flags for some case.
Instead the Product Lead went to CTO and overruled them. A product lead that ain't a programmer told programmer's to shove it, and do how he wants it.
This flag along with many, many such cases has been caused problems ever since.
Actually I worked for a failed startup where everyone left because they disliked management. In that startup I was the lowest paid engineer and the only non "staff" level one who had a contract bringing in money to the company. My last employee review with the company was terrible even though they admitted in the meeting that I had achieved all the goals and gone above and beyond what they had requested I do to get a promotion[0]. It was pretty clear it was about money, I asked if this was actually a performance issue or a money issue. The conversation changed though still ended up being very political...
This is part of why I'm insisting you need to work with me to be able to communicate. You are reaching for assumptions that justify your position. My opinions are shaped by these TERRIBLE experiences.
Management makes or breaks a company. As an employee it is your job to help ensure the culture works. But you can only do so much too. I'm not saying change the world. As a standard employee if things are going south, it is time to brush up your resume and start shopping around. You can interview without taking a job. You're not stuck where you are, so stop acting like that. The problem with your point of view is that you act like you have no options. It is either work for where you work now or have no job. Don't quit until you have something else lined up. But also don't be afraid to quit. It's not worth being miserable. Interviewing to find a better fit is infinitely better than hating yourself day in and day out, more and more as time goes on.
I'm not saying it is easy either btw. It definitely takes work! But neither are you stuck.
[0] I came with receipts. I had them give me a comprehensive goal list in my previous year's performance evaluation because I had already recognized some of these issues. So I wanted something in writing. It helps. (And btw, I even had a meeting with my direct manager 6mo in and 3mo before the yearly review to make sure I was on track)
> This is part of why I'm insisting you need to work with me to be able to communicate. You are reaching for assumptions that justify your position. My opinions are shaped by these TERRIBLE experiences.
Not really. I'm reaching my conclusion after several experiences in various domains (fintech, ad tech, logistics software, and government-adjacent firms). Each company is terrible in its own little way. The reasons aren't always the same, but they can vary from colleagues to bizarre pipelines, to management to CEOs.
I have communicated this to management, to PO, to scrum masters, to a point. I don't want to get fired of course.
And I can see the outlines of what caused these issues and why management is doing what it is, but that's again tied to a larger economy at play.
> You're not stuck where you are, so stop acting like that.
Again, you're assuming you understand my condition.
It's a different pickle. I'm waiting for an external thing to happen (it has been continuously delayed for nearly 12 months) to be able to change jobs. Not that it's easy in the current market.
> How do you say no in that situation? Just quit?
Apparently so. It seems GP never had to pay for their siblings to get through college, while paying rent.
Just say no, quit, and ruin life of your loved ones, and become homeless. Ez.
The GP has been homeless and lived off of discarded food.
You're right that saying "no" is a privilege. But also there's nothing as empowering as knowing that it's not going to be as bad as it was before.
Stop making assumptions about me and start trying to communicate with me. We can't talk if you want me to be wrong and just reinforce your position.
And sorry, I'm not as good as doing the cat wrangling in social settings as I am in technical ones. It's a different set of tools to work with and much harder to do in an online setting.
I did talk to you. Seniors don't matter, neither do junior, janitors, and to large part execs and CTO.
Processes, and the whole structure of company, and past events determines the outcome not individuals. And on top of that broad economic movements.
A good carrot in a rotten soup, is just a rotting carrot to be.
You're right that it is the whole structure, but the whole structure is made of people, individuals. Collective action can't happen without individual action. You don't just magically go from no people doing something to everybody doing something. You start with one person doing something, then more, and more, and it spreads like a virus. Both good and bad behavior spread this way, not instantly.
Look, our literal job is to take hard problems and break them down into small and more manageable problems, right? Addressing the whole company is too big of a problem, you have to break it down. You, you are an addressable problem that you can change. The people close to you? Harder, but easier than those far away. They're also easier to convince when you make the change yourself.
Or you can just give up and rot in the soup. Would you rather try to remove the rot from the soup or bathe in it?
Your assumption that seniors will be able to output good code in any situation is what is the issue.
As a senior I've been tasked with impossible tasks, with insane deadlines, in ""enterprise"" code bases. Sure, saying NO is an option, but being the NO guy is surefire way to getting fired. And nothing looks better on resume than repeated firings.
Again, you need to reasonably interpret what I'm saying. Picking out an edge case and acting as if it is some mic drop is disingenuous. We can't communicate if you hyper fixate on one tree when our discussion is about the forest. Language isn't precise enough to do that without getting extremely verbose. So either I can write a novel in response (I'm not going to) to explain what I said above or you can work with me here. If you're really not getting it I'm sure an LLM could help you out if you also fed it the responses.
Sure. Even juniors get this. But an impossible task is an impossible task. Saying no is always an option. When given an impossible task it's the only option. There's many ways to say no. Not delivering is one of them You do not get fired for saying no, you get fired for how you say no. You get fired because the project fails. You get fired because you push back against an egotistical manager who doesn't understand the problem and none of the other engineers back you up.It's all about how you say no. You don't have to use the word to do so. Instead lead them down the right path and make them understand. You don't lecture them. Managers are like cats, you have to make them think it's their idea. So you have to ask clarifying questions and when doing so you can introduce explanations that let them know that it's not possible. The goal is to put all the puzzle pieces on the table, put the right ones next to each other and let them put the final pieces together. If they don't then they don't feel like they did anything.
You are not a mindless automata directed by your manager. That's not the role of a senior. Your job is to get things done. A senior knows that "the customer" (in this case your manner) doesn't know what they want and doesn't know how to say what they do. The job is to figure that out as best as possible
> We can't communicate if you hyper fixate on one tree when our discussion is about the forest.
All I'm saying is you can't expect perfect code in impure systems.
> You are not a mindless automata directed by your manager.
I never said I was, but I also can't turn a ship on a dime. I'm asked to perform a task; I'm going to perform to the best of my abilities, but in impure systems the best you can do is patch the leaking part with code and do some basic refactoring. Any moment spent trying to simplify and fix the software will be rightfully considered a waste.
Because a feature sold is better than performance gained (unless it's utterly abysmal).
> The goal is to put all the puzzle pieces on the table, put the right ones next to each other and let them put the final pieces together. If they don't then they don't feel like they did anything.
Again, in impure systems half the puzzle pieces have left, some other parts of other puzzles have been mixed, and it's the clock is running.
The more you focus on cleaning code, the more you are falling behind feature wise. Up until a point that you can present to managers "Shit is very bad, we need to refactor."
There is a magic word that adults sometimes use. It is a word you have to learn to master if you want to be any good at your job.
No.
Saying no is a privilege.
It's easy to say if you have other options.
It's extremely hard to say if others depend on you saying yes.
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.
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.
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.
Of course you should not wait around. I think rather the opposite that the engineers should be more involved in working on the requirements. The issue is more rushing and being expected to magically just conjure something. Changing requirements is a fact you just have to live with in many industries.
Changing requirements is fine. Changing requirements when it was eminently avoidable is very, very bad.
If I asked you 6 months ago if you might ever consider something other than credit card payments, urged you to seriously consider this and you say no, you shouldn’t come to me now and say that bank transfers (bank transfers!) are absolutely indispensible.
> If the foundation is built on sand then that needs to be fixed.
Except this is the system working as designed. Leadership 1000% wants to do things as fast and as cheap as possible.
It works as designed if your goal is to get your next promo package. It does not work as designed if the goal is to actually make the company more profitable. This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.
> This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.
Being delivered faster or cheaper isn’t the goal. The goal is to look good while doing it. Telling your bosses ‘Yes sir!’ Is apparently a lot more palatable than saying ‘No can do’.
It depends a lot on the circumstance.
Profitable over what time horizon?
Any really. Rushing the team is more about looking good so you get promoted than about profit in any form.
> 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 proje
You have a very charitable view of the competency of the typical engineer at big tech nowadays. Ten years ago, sure. But with the advent of people purely studying for coding interviews that's changed.
Maybe, but then they are not "good engineers". A blog post about bad engineers writing bad code is not very exciting.
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...
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, 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.
The 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.
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.
I 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
The bricklayer's building that falls over, or the cook that makes food that tastes bad and no one wants to eat and makes people sick isn't going to have a job for very long, however. And of course, the job of "cook" runs the gamut from minimum wage at a shitty diner, to being very well paid at a Michelin star restaurant. So shipping code > beautiful code, but three years from now, that one "quick and dirty hack" just to get the next version out the door has become three hundred hacks, and that tech debt is a liability preventing any movement, either fixing existing bugs or in shipping new features.
So maybe not every line of code needs to be even more beautiful than the last, but there's clearly a balance to be had. And yes, sometimes the business people are right. Sometimes they are wrong, however.
I think we're both arguing for balance here
When I started programming I wanted everything I wrote to be museum-ready. I was slow as shit and waaay too precious about code. As I've matured I realize that's not a good way to work.
I think my lowest acceptable quality bar is still pretty high (and I'm fortunate to work somewhere that is valued). But as time has gone on I've tried to emphasize speed and knowing when something is "good enough"
I feel that it's an important skillset for the profession, but often craft-oriented engineers dismiss it at "business people not understanding"
As always this depends a bit on where you work and your projects
Your analogies don't work. Nobody pushes a cook or a bricklayer so hard that they cannot have a basic level of quality to their work. A meal that makes a customer sick or an entire floor of a building collapsing due to bad bricklaying is the limit the managers in those areas generally don't cross.
Not the case in commercial programming. If you manage to pull a heroic and still deliver something that does not fall over in a near-impossible deadline and with a lot of pressure then you are actually doing a huge disservice to yourself because the leadership will think "welp, obviously he can do it in those conditions" and next thing you know, next time around it will be even more difficult.
"Give them an inch, they will take a mile". Sadly this proverb very often applies to business people.
Most commercial programmers are extremely squeezed. I started daydreaming for another profession lately but yeah, ain't happening in my 40s with a very unstable financial situation.
I've read your sibling comments. It seems like you were on the other extreme and it does seem to me that now you are overcompensating by being too sympathetic with business and management. Whiplash effects are very understandable while one is still trying to find their balance. Still, don't give those people too much credit.
What do you mean by basic level of quality?
What are you being pressured to do to meet a deadline that's on the level of building collapse?
"skimp on the tests" or "do this hard to maintain fix as the solution" is maybe the hardest I've gotten pushed. Are people telling you to skip auth to hit a deadline?
> A cook cannot spend time making every dish perfect.
That's too generalised. A fast food cook can't spend time to make things perfect. A tiny, fancy Japanese place will spend time to manually craft a perfect dish and you'll wait while watching the whole process.
I suspect that you can find something similar in every category you mentioned.
> watching the whole process
I think this is worth exploring. Not shoving the details of work in people's faces to assert its quality, but somehow creating some drama or interest in its quality. In a way compatible with the immediate practical needs.
This isn't an easy problem to solve. And the example of a boutique Japanese restaurant is a good one. In this case, the process is designed to make consuming the food, the immediate practical problem, more satisfying.
Perhaps the code equivalent, would be seeing changes in sequence, where each change is obviously well done from the user's and manager's perspective. A process more easily achieved by green field work. Which is also relevant to the restaurant example, where each dish is its own creation (within a well thought out process).
> "... so you're saying they wrote bad code on purpose?"
Depends how you define "one purpose". I feel like I could polish any code to perfection forever. But the threshold of bad is going to be very murky. Is it still bad after 5min? After 30? After an hour? After a day?
Wherever you think is the right effort/benefit threshold, it will turn out to be different in a few weeks. And you'll find people who think it's too fancy and people who think it's bad. Rarely is there objectively bad code. (Yeah, sometimes there is)
> Wherever you think is the right effort/benefit threshold, it will turn out to be different in a few weeks.
Very true. And experiencing this has absolutely been a useful lesson to me. I remember feeling pained over some code I wanted to write in a more robust and principled way in front of a big deadline, and after a bit of friendly push and pull with my manager, I agreed to console myself by throwing in some TODOs and FIXMEs in the comments instead of getting carried away overengineering or burning rubber just beautifying my style. I remember this ritual feeling painful at the time, though it helped me cross the finish line sooner. A few months later, it was clear that ~80% of that code would be good enough for the next year or so— by which time other parts of the application would have evolved as well. I even ended up glad I'd deferred a few of those changes just so the small refactors could be informed by things we'd learned in the meantime.
Sometimes it goes the other way, or course! Many times I've been glad for some extra care I put in early, or regretful about some I didn't. But you're right that that balance always seems to change in retrospect, one way or the other.
> I feel like I could polish any code to perfection forever.
Then you know what to work on to become an even better engineer. My recursive function for improving code has clear exit conditions. One of them indeed includes aggressive timeboxing, so on that point we're aligned.
I feel you are trying to make an argument against better code. I get it, there are very fussy programmers out there who can indeed polish stuff until the heat death of the Universe (and still be unhappy) but bringing up extremes is not very interesting in a discussion IMO.
> Is it still bad after 5min? After 30? After an hour? After a day?
Generally, time spent on code has near-zero correlation with the quality you'll get. That correlation only becomes stronger when you have a lot of trust in the person writing the code (including yourself).
As above, don't try to make managers look like the reasonable people. I've met some and I adored them but the 99% are egotistical snowflakes that will fire you the first time you say "no".
---
Nobody is saying "accommodate the insufferable nerds and give them two weeks to do what junior Joe will do in 2 hours and it'll be pretty good" here in this entire thread. People are saying "maybe we the programmers should have SOME power in some decision-making as well". I am OK with my influence being somewhere between 10-15%; that's expected, I am neither a manager nor a financial stakeholder. What I am not OK with is when that number is 0-1% and sadly that has been the norm during my consulting and contracting period. And it's the main reason due to which I am trying hard to end this period right now and settle somewhere).
I'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.
Bad 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.
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.
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.
Big companies oftentimes have cultures and leadership that lead to bad code.
IDK, my team at a FANG has an average tenure of around 7 years and the ones less than that are new hires. I keep getting refresher grants every year. I'm sure this article rings true for some people but not me.
I'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.
The job hopping thing was definitely a trend, but I think it died with ZIRP. kinda weird to reference it now, but I guess it does have relevance to the state of some of these older services. The original teams are long gone
github does not have a good engineering culture compared to FAANG, they've had some horrible outages and made some questionable scaling choices.
I 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.
Good 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".
Yep, you beat me to it. Arguing over good code is pointless. We should instead agree on various metrics on what a bad code is and try to avoid those.
I think we can agree on a version of bad code, specifically extremely bad code.
Just as we might agree on universally panned bad movies, but disagree on cult followings or one of us for a particular reason can't stand a popular movie.
That is to say we can all agree on extremes, but just because something isn't extremely bad doesn't make it good in everyone's eyes and that's where the contention is.
I 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.
I 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.
Anecdote:
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:
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.
Seems like a pretty easy thing to clean up. I am confused by these devs who just seem to give up. Just fix it!
No one had the motivation to fix it, including management. Many of the developers saw the problem as job security.
come on man, give us a clue tell me at least it won't kill anyone
This 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.
Author'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.
You don't need a second screen to do your job, denied. - your people manager that has to sign off on purchases
In 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.
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
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.
"I love deadlines. I love the whooshing noise they make as they go by." ― Douglas Adams
Then you've been fortunate to work at places that respect engineering.
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.
Deadlines 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.
> paying people more in bonuses for goals
Then this leads to people setting tight deadlines. It's a vicious cycle.
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
Every 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.
Over 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.
I 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...
A 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...
> 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.
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.
What 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.
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.
>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.
> I'm also dubious of your claim that compensation doesn't attract better talent.
Maybe higher compensation does work out for FAANG, but it does not at other larger employers, at least not for software developers. I am highly dubious about this at FAANG too though. My perspective is as a former 15 year JavaScript developer and a lot of what I saw coming out of FAANG in JavaScript land just wasn’t impressive.
I do see a lot of impressive things in the world of JavaScript but it’s almost always open source from small teams or single developers.
I don’t think the expectations are any less, it’s just different. Much more responsibility around ops and security
I 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.
> 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.
I 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.
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.
You have to realise there is a almost full complete disconnect between engineering and business value
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.
That is, until planes fall from the sky.
It's popular to mock aerospace engineering, but it's usually quite robust. Even if people still sometimes make bad decisions.
The 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.
Ah, 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.
And move slowly. So when things turn bad, they will be bad for a decade - or more. See Boeing.
Boeings (software) issues stem from a removal of their Engineering skillset and replacing it with an outsourcing model don't they?
Only if there are is organizational disconnect… which is the norm.
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, just table stakes. Profitability is determined by the machine built around the product, like 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.
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.
Well maybe you get hit with the gray arrows because you first make a sweeping generalization and then say "I have no sympathy for you". Food for thought?
I have communicated the business value in addressing tech debt, as in I have pointed out how many critical customer features got delayed by it and we churn customers we really can't afford to.
Still got overruled. The tech lead stepped in and threw his weight around with zero explanation to the CTO or the CEO. Who needs to hear what the engineers on the ground have to say, right? They cannot communicate!
Man, tearing down strawmen is easy. You should do better and see nuance. A lot of engineers communicate very well and are still ignored.
When all leadership is asking is "what is the short term business value?", it's pointless to make that case. It's much easier to measure "yet another feature" than "fix the root causes of what makes our product subpar and slows us down". Not only that, but an incompetent engineer's "tech debt grooming" may make things worse.
I think that this may eventually become better now that there isn't so much dumb money around (no ZIRP) and with AI assistants taking on some low-effort work (enabling companies to lay off incompetent engineers). But it will take many years for companies to adapt and the transition won't be pretty.
I think AI will make it worse since it will allow the incompetent engineers to do much more harm.
In the short term, definitely.
In the long term, once the damage from vibecoding is better understood (for customer impact and team morale), there's an incentive to push them out, both from the leadership and the individuals side.
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...
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).
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.
The point of a business is to generate profit.
* 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.
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.
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.
> 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 ;)
> 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.
I 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”
Meanwhile, 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.
Something 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.
Not 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.
Oh, 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.
I 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.
The referenced article Pure and Impure Engineering was discussed a few months back here: https://news.ycombinator.com/item?id=45165753
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.
I 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.
There'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.
This 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.
Big 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.
Yeah, 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.
It 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.
oh 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
There’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.
Bad 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.
In 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.
I 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?"
This 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.
I'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.
I'm just gonna drop this funny roast song here. Hope it's heard lightheartedly:
https://suno.com/song/d6d77518-16ca-455f-ade1-0e8d08fc4b0b
it 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.
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.
Tight deadlines and poor scoping. At least from my experience. When corners need to be cut, code quality goes out the window.
Great article. I quite appreciate this one and the Pure/Impure engineers.
At 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
when 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.
I 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.
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.
> 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.
I 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.
1. 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.
software-by-committee never works
There'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"?
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.
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.
Yeah that's true. As with most things it's a mix of factors.
Remember the Stanford Prison Experiment; "bad company corrupts good people."
it'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.
Another 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.
work vs capital
...and also bad engineers write bad code at small companies.
[dead]
[dead]