- cross-posted to:
- programming@programming.dev
- cross-posted to:
- programming@programming.dev
The really interesting part is IMO this one:
You must log in or # to comment.
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!
Consider that to go on a site specifically for programming questions and then take a survey about it, you have to be the kind of person that cares about getting their code “right”. The majority of programmers I’ve met would only go there to copy-paste a quick answer, and those people have all moved to asking chat-gpt for code now.
Why is that? I’ve read them referred to as dark matter developers (forget where I read this, maybe a book many years ago). They’re out there, they make up a majority of the field, yet they leave no trace because they do not blog, post on SO, or back in the day forums either as questioners or answerers.
Wow, hadn’t thought about that one in a long time. I thought it was an old Scott Hanselman blog and I was correct! I’ll have to reread it, been years now.
I’m not sure there’s much why to it exactly. I feel like a small fraction of people I’ve met in life were truly passionate and excited about the work they did. Most had some passion for an art, or a hobby, or for their kids very commonly, but people who really want to grow and master their craft are somewhat rare generally. Most folks just want to do well enough to keep their jobs and then go home to whatever they actually care about.
Job kills passion
I’m just a hacker. I’ll never be a thought leader. But I am passionate about my work. And my kids.
I love solving the problems. I have a few posts on the company blog but they put a chat bot on it a while back and didn’t care that it felt offensive to me.
But I’m here, reading this. Maybe I’m grey matter.
The memes that I remember being all over Reddit about “where did you get that code … I stole it [from stack overflow]” honestly terrified, and continue to, terrify me.
Yep, the ones who are doing some kind of input on stack overflow (even just a survey) are way beyond the “let’s keep everything the same because to get rid of tech debt sounds like a bunch of work” camp.
I’m currently chancing jobs due to fact that while we are getting rid of the legacy tech debt, we are rushing with the new stuff in a such stupid way that we are instantly building new tech debt. Change, hooray!
Actually makes me feel a bit better. Of all the issues this could be the easiest to tackle. Most other issues are completely above your pay grade, unless your boss/PO is adamant about always producing new features and tweaking old code is a waste of time.
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.
The good news is, with the fed lowering interest rates the cycle of
speculationinvestment will pick right up in a year or two where it left off for a whole 30 months of higher interest. I can’t believe they’re dropping it so soon, but we can’t have unsustainable businesses held to account can we? Better to destroy savers and fixed income elderly.
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.
I mean, the thing I work on hada great idea. Use microservices, because we genuinely have a need to independently scale different parts.
Few years down the line and there’s an endless list uff services, most with a single instance doing nothing all day, and having memory and CPU overhead of course. And being a nightmare to figure out what code is whereas they all communicate independently.
And being a nightmare to figure out what code is whereas they all communicate independently.
So much this. Especially in a larger company it can be basically impossible to find the code that implements an endpoint, and of course even if you can find it you can’t trace it in a debugger.
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.
Tech debt is like a hole in your roof that many teams don’t start trying to fix until water is flooding in. Companies missing the business value in addressing tech debt leads to perverse incentives for developers where they are encouraged to cram new features into the product and then leave for another job in 2-3 years before the consequences come knocking.
Fixing? We just moved to the kitchen!
And the replacement people all just assume that we’re supposed to be up to our waists in water.
There’s no value for the higher ups in fixing it
Well there is, it’s just long term value that they don’t even understand.
Really you should just make fixing technical debt part of your regular job. Don’t ask for permission, just do it. (Except for really big things obviously.)
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
That reminds me to read all his public letters (available on the website you just linked) soon. Using TTS, because that’s all too much text for my poor brain to handle.
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.
ive been in IT in some fashion for most of my adult life and I’ve often wanted to just abandon the whole field entirely but i have no other skills and as soul sucking as it is it still pays pretty decently compared to anything else i could possibly be considered for
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.
