I consider the ability to work with legacy codebases an essential skill. If you can’t do that, you’ll be changing jobs like other people change underwear. Any

I consider the ability to work with legacy codebases an essential skill. If you can’t do that, you’ll be changing jobs like other people change underwear. Any codebase that sees real usage will accumulate cruft, odd behavior and legacy code over time. Dealing with that and assessing what’s worth refactoring and what’s best cut or even just left as it is to reach a business goal is the skill that differentiates a seasoned engineer from a code monkey. That shitty legacy code is often what brings in the money to sustain the company, otherwise it would have been turned off long ago. Microservices don’t help much in that regard: each micro service can look squeaky clean from a code perspective and the whole system can still behave in shitty, unpredictable ways. (Been there, seen that) It’s also not about fitting in: taking on a shitty codebase and transforming it into something better is an outstanding skill and requires constant communication with all stakeholders, especially when you want to cut legacy stuff. It’s certainly not something for people that prefer a quiet corner.