Dare Obasanjo on Twitter posts this meme & writes:

A genuine problem in tech is that we’ve created a culture where people switch jobs too often to experience the consequences of their product & technical decisions let alone have to fix them.

Deech responds:

There’s always 1 or 2 people who’ve been there forever who know everything about that janky opaque system and resist change (usually without meaning to). This is not a coincidence. So you can spend months getting up to speed and at least a year building the social capital to advocate for change or, y’know, just bounce. I’m not saying don’t try, just that if you want to change current behavior you have to know how it’s rewarded.

Many sides to this issue, & the threads provide insight, much I’ve personally experienced. Some cite leaving because they weren’t allow to fix the tech debt after years of trying. Others just leave because they can get higher raises/promotions and/or work on greenfield projects elsewhere vs. staying. Some cite rewarding incentives of maintenance so developers stay and grow.

Mehdi Vasigh writes:

Not fair to put this on ICs. It’s usually organizational problems that lead to constant reorgs and teams being moved around, and this burns people out. Most engineers I know want more time to fix bugs and refactor.

Dougword’s take is what I’ve seen happen when developers first have to “maintain their mess”, myself included:

Having stayed at my current job for longer than any previous gig, I am finally starting to see the impacts of decisions made 3-4 years prior. I regret pretty much all “magic”, “clever”, and “new tech” solutions I helped implement. I don’t regret any simple boring solutions.

This has a risk, though, as you use that experience to frame all other possible scenarios. For example, yes, a lot of new tech isn’t really new, but sometimes, SOMETIMES there are some wonderful new ideas and/or combined approaches in there that are worth investing in and could positively change your life. You have to fight hard to battle cynicism just because you burned yourself once. That’s why I believe it’s better to be insecure about what you believe in software so you always keep an open mind despite years of “living proof” under your belt forming your belief structure.

Codegumbo’s take exemplifies this challenging balance:

Truth; alternative is that people stay and fail to grow. No new skills means that they make the same assumptions as the past. There’s a balance, and the org needs to recognize the challenges from both approaches and adapt accordingly.

I feel like half my career has been learning how to quantify the business value for refactoring, balancing that with shipping new features, and providing opportunities for growth in both my peers and me. Sometimes it was obvious to me that we should do it, and obvious to others we shouldn’t. Sometimes I’d convince myself it wasn’t worth it, which I suddenly had no idea how to deal with that conclusion. Just like in SimCity, building more roads led to wonderful economic increases for your city, but had a cost to maintain them.

I don’t know how to fix the incentive problem, neither for developer, nor management.

I DO know, however, maintenance is worth your time for learnings. No need to do it forever, but 2 to 3 years will do you wonders for your career. Just don’t cement your belief system on it.

In short, I’d highly encourage you to experience, in order of importance:

1. start a greenfield project that you had a hand in, then maintain it in production for 3 years
2. inherit a project you didn’t build, and maintain it for a year
3. practice slicing pieces of refactoring, from code or tests or CICD that you think would provide business value, quantify it, and describe in business/product language.
4. Briefly step into a product/business role, and balance that cost/value proposition with the other business initiatives on the docket, and see how you can or cannot fit it. Visualize how you’d remove one or many to put yours in there, and how you’d sell that.
5. do all of the above in different business contexts; startup, consulting, mid-size and large companies.

Remember, a lot of the narrative focuses on “technical debt”, but product decisions are just as powerful too. Having a hand in that, and seeing the results years later are just educational.