If you don’t mind me asking, how do you specialize in legacy code? Do you focus on short contract work? Have you built relationships with local companies. I’m genuinely curious in your process.
I actually do long term contracts at the moment. However, I have found that there are usually opportunities in full time positions. I tend to look for companies that are just past the startup stage, and moving into that awkward stage where they have to scale, but everything up to this point has been based on heroic efforts of a few people. Usually there are gaps from people who have left and as the business expands, there is a lot of greenfield work that people want to do and nobody left over to do the legacy work.
Short term contracts can get you in the door, but I would try to negotiate up into longer term contracts because legacy work is slow. It's not so much that you can't provide a lot of value up front, but if you want long term benefits, it usually takes 2-3 years before you've refactored enough to make a big difference. If going for the employee route, just keep your ears open during interviews about systems that are messy. If you express an interest in working on those kinds of systems, it usually provokes both surprise and interest ;-)
I think the key for legacy work is that normally people don't want to work on it. There are almost always systems that people are afraid to touch -- to the point where you may even be forbidden from touching it. However, you can often find big wins with small changes for such systems because they are usually neglected for a long time. If you cautiously make a change and manage not to break things, then usually there is a huge pent up demand for more.
I think there is one other thing that I always have in mind for some reason. In Taoist literature they frequently make the analogy that water runs to the lowest point. In the same way, it's easiest to make good changes in systems that are the worst. If you are working on a very nice system, you have to spend a lot of energy staying on high ground. But if you are working on a very poor system, you spend no energy maintaining your position at all -- you just fall into the low ground. So paradoxically, I tend to look for companies and positions where there is something wrong. If there is nothing wrong, then there is nothing to fix and my job becomes quite a bit harder.
Short term contracts can get you in the door, but I would try to negotiate up into longer term contracts because legacy work is slow. It's not so much that you can't provide a lot of value up front, but if you want long term benefits, it usually takes 2-3 years before you've refactored enough to make a big difference. If going for the employee route, just keep your ears open during interviews about systems that are messy. If you express an interest in working on those kinds of systems, it usually provokes both surprise and interest ;-)
I think the key for legacy work is that normally people don't want to work on it. There are almost always systems that people are afraid to touch -- to the point where you may even be forbidden from touching it. However, you can often find big wins with small changes for such systems because they are usually neglected for a long time. If you cautiously make a change and manage not to break things, then usually there is a huge pent up demand for more.
I think there is one other thing that I always have in mind for some reason. In Taoist literature they frequently make the analogy that water runs to the lowest point. In the same way, it's easiest to make good changes in systems that are the worst. If you are working on a very nice system, you have to spend a lot of energy staying on high ground. But if you are working on a very poor system, you spend no energy maintaining your position at all -- you just fall into the low ground. So paradoxically, I tend to look for companies and positions where there is something wrong. If there is nothing wrong, then there is nothing to fix and my job becomes quite a bit harder.