5 ms·

> 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

> 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.

sfink 11mo ago
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.
- brendoelfrendo 11mo ago
  > 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!
  - JohnMakin 11mo ago
    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.
ajkjk 11mo ago
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.
- stoneforger 11mo ago
  That's in addition to the parent comment. They are both true. Caring is for other people, the tickets must flow.
- chanux 11mo ago
  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.
  - phito 11mo ago
    >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.
chii 11mo ago
> “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).
- stoneforger 11mo ago
  Only the bottom line matters and the bottom line isn't a good product, it's a good bonus or stock.
black_13 11mo ago
[dead]
ludicrousdispla 11mo ago
Bad code bothers software engineers because it is often a reminder of their lack of agency in those companies.
- TomasBM 11mo ago
  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.
KronisLV 11mo ago
> “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.
- TomasBM 11mo ago
  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.
scrubs 11mo ago
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.
ClayShentrup 11mo ago
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.
zingar 11mo ago
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.
mesarvagya 11mo ago
> “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.

sfink 11mo ago

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.

brendoelfrendo 11mo ago
> 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!
- JohnMakin 11mo ago
  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.

ajkjk 11mo ago

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.

stoneforger 11mo ago
That's in addition to the parent comment. They are both true. Caring is for other people, the tickets must flow.
chanux 11mo ago
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.
- phito 11mo ago
  >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.

chii 11mo ago

> “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).

stoneforger 11mo ago
Only the bottom line matters and the bottom line isn't a good product, it's a good bonus or stock.

black_13 11mo ago

[dead]

ludicrousdispla 11mo ago

Bad code bothers software engineers because it is often a reminder of their lack of agency in those companies.

TomasBM 11mo ago
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.

KronisLV 11mo ago

> “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.

TomasBM 11mo ago
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.

scrubs 11mo ago

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.

ClayShentrup 11mo ago

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.

zingar 11mo ago

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.

mesarvagya 11mo ago

> “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.