[mikekchar]

I've been making my living as a programmer since 1986, though I've done some other jobs in between... I think "more than 25 years" covers my professional experience as well.

First, I always say, "programming is programming". People often get caught up in the application they are developing, thinking that it is new and exciting. However, the programming side of it is just programming for the most part. The number of hard domain specific problems you have to solve is quite small compared to the amount of code that you have to slog through.

As you say, languages and frameworks are only marginally interesting. React was interesting to me for a few days because it solved some problems in an interesting way. But I've used over 20 different languages in my professional career (and multiple different frameworks) -- almost one a year :-) For me, a lot of shops have a lot of legacy code in a variety of different languages and frameworks. I tend to specialise in legacy code so I see them all.

But there are definitely challenges -- it's just that they are challenges that most people don't see. One of the reasons I specialise in legacy code is that it's much more interesting for me. Greenfield development is about learning a new language/framework and arguing with people about "the way to do it right". Legacy is about taking code that everyone has already abandoned and making it good. That's hard.

I think it's a bit like drawing, actually. When you first start drawing, it's a big challenge: how do you get the proportions right? How do you draw hands? But eventually, it's all the same: How many hands do you need to draw? I often think about manga artists who have to draw 15-20 pages of manga every week: how many hands do they draw?

But it's not about the hands. It's about the composition. You can get the proportions all right. You can draw the hands perfectly, but it still might be an uninteresting drawing. People can teach you about the technical side of drawing, but it's hard to teach people about art.

For programming it's the same. Eventually you are just grinding through code and there is very little technical challenge. So why are all our code bases so awful? If you think that it's because we're always rushed, imagine those poor manga authors who are cranking out 150 hands every week (as well as faces and feet and bodies) -- and some of those are masterpieces. Maybe we can't meet all the expectations of getting it done yesterday, but why can't we right good code day in, day out and end up with a masterpiece?

That's the challenge. I don't suppose I'll be able to master that in my career, but it's fun to try.

[0x445442]

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.

[mikekchar]

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.

[0x445442]

Thanks for the detailed reply.