Do jobs exist for doing refactoring, readability or technical debt work?

Those jobs exist and with a bit of job crafting you can definitely put yourself in such a role if you're working for the right company. It's just hard to get hired for such a position from the start because new positions open when someone leaves or when you need to ship something new; no one ever adds headcount for refactoring and maintenance. Also, you need some experience with the codebase before you can effectively address technical debt so it's rare to get started with work like this as soon as you're hired.

If you're working for a healthy team/company/manager and have a bit of experience already, you can actively seek this type of work and do more of the things you like. It's just unlikely that you'll be explicitly hired to do this. And as you pick up more of this kind of work, you need to communicate things clearly and make sure that it doesn't look like you're slacking or deliberately looking for lower profile work because that can hurt you too.

Both at my current startup job and at my previous Verizon job, a lot of my time is scaling out existing services and also boostrapping core infrastructure projects that prioritize reliability over adding features or addressing rapidly changing requirements.

Part of that is because I'v become very comfortable diving into very complex, established code bases because of my OSS experience, and enabled by the fact that I've had coworkers who didn't enjoy the deep dive/scaling part of coding compared to adding new features.

A lot of developers really enjoy the spotlight of having added the new killer feature that everyone recognizes, and sometimes that's even different skill set.

So my long winded answer is that there are two main ways to accomplish your goal:

1. Be able to refactor, address technical debt, scale out solutions, debug any problems, and find a team that complements your skillset, and get good at making sure your non visible contributions are known and appreciated. This often means having clear and easily available metrics that can show over time things like: less errors, more tests, faster build times, and so on. Really anything that you can point to that makes it easy to understand your value to those outside your team/org.

2. Become a team lead. A lot of times the tech debt/refactoring work isn't celebrated or recognized, but necessary. The job of a team lead is to both give guidance and enable your engineers to accomplish their tasks. Making code more maintanable, easy to read, and robust ensures your team will quickly and happily progress on their task, and you'll get to share in their successes even if you aren't the one contributing features. Unlike scenario 1, you don't necessarily even have to show as many metrics, as your value proposition is much simpler: Make your team productive and happy.

It's about time that we did have (and celebrate) this kind of role; it'd be something like a maintainer position, except - depending on the organization - perhaps a bit more focused on cleanup.

A couple of thoughts:

- If you work on open source projects, you can create and tweak this role for yourself by finding needful tasks in upstream projects; just be careful to validate your approach to make sure your changes are likely to be accepted

- If this were a role within a salaried organization, you'd ideally want a way to show -- or a shared consensus -- that the work involved is worthwhile and producing value. How would we do that for software projects?

Look at enterprise software jobs! A lot of enterprise software is massive old code bases that need people who are good at spelunking and understanding "what was this doing and what is it doing now". It might not be 100% refactoring, but a lot of the customer bugs that come in are caused by tech debt and the solution involves refactoring a tad. Even if the software is still growing with new features, there is a lot around refactoring existing code to fit in the new feature.

Some people will tell you that they dont allow developers to refactor because its risky and there are higher business priorities, but before you listen to them, ask about the context. My team's official line is no-refactor because we can't break our API because our support contracts are 5+ years. That's true, but under the hood we are refactoring a little every day (split a giant method into a few new classes, add wrapper classes so we can add a unit test to previously untested code, etc)

Also, if you're good at the skill "good at reading bad code", your teammates at any job are going to be very grateful! There's not a lot of people are good at it and enjoy that!

From what I've gathered most small software companies rarely invest in refactoring. Instead, they like to dangle the promise of doing so, perhaps with a new modern language, as a carrot and stick routine to keep developers from leaving or to entice new employees to join the "team". Large companies, however, will typically do unit testing and refactoring already. So my guess is go with a medium sized software business.

In most of non tech org software development is cost centre. Implementing new features always take priority over paying debt.

IMHO, it's difficult to get such job. Specially in today's world where technology is changing at very rapid pace.

In my case management philosophy have always been "why fix things that aren't broken" or it will be responsibility of next person.

YMMV

I am in the same place, I would like to get some advice.

curious if you've keyword-searched 'refactor' on contracting sites like dice.

maybe just start out part-time.