> Improving old code bases
From my experience, I think there's a great need in large tech organizations for people that are able to advocate for and drive initiatives that can scale up efforts to improve old codebases.
From my experience, I think there's a great need in large tech organizations for people that are able to advocate for and drive initiatives that can scale up efforts to improve old codebases.
But it's nearly impossible to find that kind of job because employers tend to go out of their way to hide the fact that they even have existing software, let alone that they want someone to work on it.
They do though, through platform teams. The React team at Facebook, for example, goes to enormous lengths to ensure they aren't hopelessly breaking their downstreams even as they try to pay off previous code debt (e.g. the context api efforts).
What makes it difficult for people to "sell" maintenance work (specifically for product work, as opposed to platform work) is that it usually gets framed in terms of maintenance vs new features, as opposed to e.g. improvements in reliability given some metric, etc. Another problem is that developers have a very strong tendency to want to dive straight into coding without necessarily doing the legwork of gathering metrics to show that some work is actually worth doing. This often gets a pass with new features, because it's easier to get people excited about shiny new things, but maintenance work is inherently going to get people asking for "data" to satisfy their reptilian brain's aversion to risk.
Personally I had trouble selling it but that's probably my fault. One had "clear text passwords of C-execs" before it got any attention and rewrites.