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.