Definitely agree with tech debt. Seems like nobody except me cares about improving things, which is surprising given this survey!

Also definitely agree about reliability of tools/systems, but again it feels like it's just me that cares about robustness - everyone else is very happy to churn out hacky Bash scripts, dynamically typed Python and regexes with abandon.

Either you're all a bunch of hypocrites or the SO survey is quite a biased sample!

Personal experience bias in mind: I feel like owners and managers are less interested in resolving tech debt now vs even 5 years ago.. Business owners want to grow sales and customer base, they don't want to hear about how the bad decisions made 3 years ago are making us slow, or how the short-term solution we compromised on last month means we can't just magically scale the product tomorrow. They also don't want to give us time to resolve those problems in order to move fast. It becomes a double-edged sword, and they try to use the "oh well when we hit this milestone we can hire more people to solve the tech debt"... But it doesn't really work that way.

Its also possible I'm more sensitive to the problem now that I'm in them lead/principal roles rather than senior roles. I put my foot down on tech debt a lot, but sometimes I can't. Its a vicious cycle and it'll only get worse the longer the tech sector is stuck in this investor-fueled forever-growth mindset.

Too much "move fast and break things" from non-technical people, not enough "let's build a solid foundation now to reap rewards later". Its a prioritization of short term profits. And that means we, the engineers, often get stuck holding the bag of problems to solve. And if you care about your work, it becomes a point of frustration even if you try to view the job as just a job.

Not surprised that Tech debt is among the biggest. There seems to be a lot of complexity added to apps unnecessarily these days-especially web based apps. It's almost like companies purposefully force their engineers into creating web apps so bloated that users have no choice but to use the native app version.

Technical debt is a real doozy. There's no value for the higher ups in fixing it, so nobody does.

New features just take longer and longer to add, under a teetering pile of your own shit.

I think part of the problem is the ideal underlying structure for your project doesn't really reveal itself until several years in, and by then it's a nice to have for some other time that never arrives.

My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

——On the cruelty of really teaching computing science - E.W. Djikstra

There is no such thing as "done" anymore. Every app must be updated indefinitely, and not just security or bug fixes. Once my vision for my app is complete, I stop reinventing it. That's how you get AI added to fucking notepad.

My biggest gripe is the lack of respect/understanding for the importance of data models and clear domain boundaries.

Most things that end up as "technical debt" can be traced to this. Sometimes, it's unavoidable, because what the data models changes, or the requirements of the domain, etc.

And, it's very innocent looking differences sometimes. Like "We know that the external system state will change from A to B, so we can update that value on our side to B". Suddenly you have an implicit dependency that you don't express as such.

Or, things like having enum that represents some kind of concept that isn't mutually exclusive. Consider enum values of A and B. Turns out this really represented AZ, and BP (for some inherent dependency to concepts Z and P). Someone later on extends this to include ZQ. And now, suddenly the concept of Z, is present in both AZ and ZQ, and some consumer that switches on concept Z, needs to handle the edge case of AZ... And we call this "technical debt".

Most of the systems I worked on, were legacy, badly-engineered systems. I worked for five years "maintaining" (or trying to maintain) a commerce platform made with pure PHP, an old version of PHP that couldn't be really updated. The platform depended on an external API that's constantly changing (as we speak): changes that couldn't be reflected on this platform as it'd imply a complete rewrite of such system. No documentation, no worry about good practices, "just keep it" (while dealing with angry customers, as I was also responsible for internal support intricacies). Good thing I left, although I miss that money for... I dunno... surviving, as I have no prospect of being hired any time soon. I worked for 10+ years (cumulative experience) as an IT professional, but I'm sincerely thinking of abandoning my "career" for a simpler job. I love computers and I love math, but I hate being a cog inside a broken machine.

I relate. Technical debt is by far the most common source of frustration in my career. It’s that code someone inexperienced wrote years ago that no one longer understands, but it still needs to be maintained. Often the code is also unnecessarily convoluted, so there’s a high risk of introducing new bugs when working with it.

I’ve recently managed to refactor such code recently. No one could work with it with confidence, it was slow and it was buggy. A lot of the code was also completely unnecessary (like 100 line convoluted mess that could be done with 1 line of code).

Now someone else in my team who has never worked with this code wrote a major addition to it without much assistance, so I take it as a sign that my refactor is a great improvement.