Ask HN: Do jobs exist for doing refactoring, readability or technical debt work? | Hacker News Reader

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

9 pointsdmos6211 comments

I'm at my best when I'm doing refactoring, improving readability and maintainability, addressing technical debt. I'd love to have a role doing that majority of the time, but I'm not sure that's realistic. I would appreciate any insight.

View on HN

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?

Good points. Those are the main problems I've run into. One is pretty much having to ask others to trust you that what you're doing is worthwhile (because big refactors are exploratory, in my experience). The other is an extension of that where if the refactor is larger others will have to come in for sizable PR reviews. In the end, the problem is that refactors cost money and time. Essentially, they are humble rewrites. The good part is that a big refactor opens doors in terms of where you can take that system and reduces maintainance costs, but those are long term gains. A short term loss, but a long term gain. I'd like to have a better concept of how to make that sell. I think some organizations will be more inclined to that type of investment than others.

That's a thoughtful approach, but if I were a (technical) business owner I'd still be skeptical about those large refactors.

As a fellow engineer I'd appreciate them, but for our overall organizational success I might still wonder if they were the best use of time -- especially because large refactors/rewrites can be risky.

If you started by developing test coverage (that would remain constant throughout the refactor) I think I'd find that an easier sell as both a tech business owner and a fellow engineer.

Another angle to consider could be handling 'known' technical debt as feature teams emit it.

For example, a feature team might be aware that there are some negative aspects to their implementation, but they may have other high-priority tasks to handle. Catching those "debt outputs" (perhaps detected during code review) could be a continuous task for a role like this.

The problem in that case would be alignment of incentives: how do you ensure that the feature team doesn't just take the easiest possible implementation and claim that all the downsides are just technical debt to be cleaned up by another team.

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.

Hey. Always interesting to find a like-minded developer. Care to share a bit about what you're looking for? Personally, while most work expects you to add new things, I'm somehow drawn to the opposite where I want to gradually take things apart and put them back together in a free-er way, if that makes sense. I could go on, I find this an interesting subject.

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

maybe just start out part-time.

Reply on news.ycombinator.com