Like, as an engineer, I don’t doubt that this work is valuable

I think what you're describing is communicating the value in terms that the audience understands and appreciates. This is really a sales skill and most developers have little experience or recognize it as such. A good manager can help here, and I agree that a strongly aligned staff dev and engineering manager can accomplish a lot. That's been my experience and I'm always grateful for devs who work this way too.

I agree! You have to also remember that, if you're the person pushing for something to be priority, it's your job to make it make sense to whoever is responsible for prioritization. The easiest way to do that is to speak the same language everyone else is. Your product manager probably speaks in dollars (or euros, renminbi, etc). If you provide a good-faith estimate (ballpark ranges are totally fine) that increased test coverage or whatever your technical objective is will cost 200 dev hours, and save 400 dev hours on an annual basis, or reduce the rate of support tickets by 15%, or allow for X future business scenario to be supported or whatever, you'll generally have way better luck. My favorite "trick" is taking tech debt work, and framing it in a way so, not only do I not have to push for it as "tech work", but my PM will actually put it on the roadmap proactively because it just mak…

Just for the record, those have intangible results. They improve maintainability, reduce vectors for bugs (which are always based on misunderstandings) and increase velocity. Absolutely none of those can be measured (hence intangible) which is why they are a hard sell

Agreed. I have always thought about refactoring as developer responsibility. If it needs to be done do it while working on real feature and update deadlines accordingly. That way it is way easier to justify it because you talk about it only with technical people. In long run it makes code base way better. This results in easier maintenance and faster development of new features.

Although I agree with this, I can also think of a counter example by analogy. If you're on a construction project and you, say, spend a bunch of time inspecting and maintaining the safety systems so that you prevent any accidents that seriously injure or kill someone, it's an all-too-common problem that management doesn't think you've done anything and doesn't reward the effort. It's a huge failure of management that they don't seem to have any concept of benefits unless it can be quantified as ROI. And in the case where it truly is a life or death situation, I consider it a moral failure as well. In fact, this scenario isn't even a stretch of the imagination. This is Boeing, right now.

Think chefs at top restaurants for example: washing hands is something obvious, no need to get any customer infected with fecal bacteria in order to convince the restaurant management for investing into soap (hygiene takes time, you could serve additional customer!) It is one of career progression milestones for a programmer when they can set a bar for their craftsmanship themselves. Successful SWE is someone who got hired at a team which does not require this kind of education. A team where this type of engineering hygiene is obvious like breathing.

> But you have to imagine what it must sound like from the perspective of a PM or EM. Itd be like my PM saying “I spent the last month organizing all eng docs to be properly formatted with bullet points.” If your managers think that, and don't understand the value of refactors, you've already lost. You can try explaining it to them, but if this is how they perceive that type of work, it's a sign that you're working at a company that doesn't understand software engineering. Of course, new features have to be built, and bugs have to be fixed. Those are always priorities. But refactors are just as important for keeping the software in a maintainable state, precisely because they enable new features to be built faster, more efficiently, and in a more robust way.