As a contractor, I have the option to become that person again and again and again after a year or two with clients. Instead, I say nope, and find other work instead. I have given this same speech to the dutiful employees I encounter many times. Their resistance seems to be rooted in being risk averse and committed to someone/something. But that's all it takes, applying elsewhere, and not accepting what you don't want.

TLDW: In most endeavors in life, legacy is a positive thing, a bequest or accomplishment that you leave behind for future generations. Only in software do we have such a negative feelings towards "legacy"

For software to become legacy code, a system has to survive and that means it has to a) work and b) be useful. You're working on something that has stood the test of time. Just as it's much harder to restore an ancient, archeological treasure like The Colosseum, it's harder to work on legacy software... You were chosen for a task that's challenging, but important.

Why do businesses pay all this money to maintain 'legacy' code, when they could just rewrite it in the newest, best tech?

1. Because the 'legacy' software often makes money out of proportion with its cost, either directly or indirectly.

2. Because much of the human understanding that is encoded into the legacy software is gone from the company and would be difficult, expensive, or impossible to recreate.

The first point should help you feel better about working on 'old' tech. While a million developers are all cranking out react webapps that nobody will care about in a couple of years, you are working on software that has proven itself valuable to the company over time.

The second point could help give you a hint at how to leverage a position maintaining legacy code into something good for you and the company. You are close to some 'secret sauce', and if you can identify and internalize what's valuable there, you become indispensable to the company. I've seen that turn out to be very lucrative for engineers if they play their cards right (a.k.a. learn things that nobody can find with any amount of searching the internet, and turn it into pay).

A legacy system is really in front of customers and making money and has a much more certain value to the business.

Like the janitor sweeping floors in NY grand central station.

Still has dirty work involved, but it's important and meaningful.

Not that I'm implying a janitor sweeping the floors isn't also meaningful (just have them stop for a few weeks and see how many people suddenly notice) but I believe legacy code maintainers often have significantly more control and leeway in how they resolve issues than they might believe at first.

The point is rather that the time and effort of [tuning escalators] does not contribute to career credits in the way new construction projects do.

You might think you are "unimportant" and maybe at your company that's true. Looking at it less cynically you could also be reliable, capable of parsing and improving code, and more familiar with a wide variety of code styles. These suit you well to this job and being a janitor often pays really well. Often times as I advanced in the ranks I spent more time modifying other people's code than starting something from scratch.

You don't want to be learning new tech stacks all the time. If that's your personal hobby - great. But these stacks come and go and collecting N number of tech stacks to throw on your resume won't make you any more desirable to a new position down the road that requires senior X or staff Y and you've spent so much time in varying tech stacks you're not at that level. At the end of the day people WANT "boring" engineers. They're reliable, predictable, and knowledgeable.

When I was a kid, maybe 5th or 6th grade, my family was driving out in the country and came upon a burning farmer's field.

We stopped to help, and my older brother and I were charged with keeping an eye on the smoking remains of a field that had already burned out. The adults, and my younger siblings, went to fight the actual fire.

By the time it was all over, my brother and I were both feeling slighted and sidelined. But as we got back to the car, my mother, may she rest in peace, told us how much responsibility we had been given, to be set such an important job, with no adult supervision, the farmer must have thought we were older than we really are.

Two points, I suppose. First, one doesn't always appreciate one's salient qualities. Second, 45+ years later, that episode still stands out in my memory for how rewarding it felt.

Frequently the Greenfield project is purely political, or just a punt.. and has a 50-50 chance of successfully launching in a way that ever replaces legacy.

People lose sight of the fact that until the Greenfield thing launches, 100% of the revenue keeping the lights on comes from the legacy system. Keeping legacy alive and thriving is critically important both to the firm and also to give the Greenfield team runway to build the new solution. Even beyond the launch date, a sliding % of the revenue will continue to go through legacy, often the majority, and often for years.

The reality is you could fire the entire Greenfield team and continue as a going concern for 5 years. If your legacy system fails, your firm might miss payroll within a few months.

Most often I find management slaps unrealistic optimistic timelines on the Greenfield project, and continues to stick with them as the new thing fails to deliver. This both stresses out the Greenfield team to build a more corner cut solution.. while also causing mass attrition on the legacy team out of job risk concerns.

And while it may seem companies are throwing the "new" stuff at important engineers, it may actually be the opposite. Since the new stuff isn't mission critical yet, they may actually be throwing that work at the less senior engineers. After all, it isn't keeping the lights on right now.

Second, working on legacy codebases is one of the most challenging things you can do as a SWE, you're in a maze where the walls are Chesterton's fence. I just left a legacy codebase to write a new app in NodeJS. Granted, it was a lot of work to get up to speed on the ecosystem and carefully decide how to set things up, but the CI is blazingly fast, and the complexity of the same feature in the new codebase might be 10x less, at least for the beginning. For example, in the legacy codebase, adding pagination to a route is a PR that touches 25-30 files. Yes, there are anti-patterns involved, but for the new app, and it's in Haskell, that same functionality can be done in a greenfield project much more effectively.

Of course, everyone wants to work on greenfield projects, make the architectural decisions, and build software without the constraint of past decisions weighing us down, but adding features to and improving legacy systems, IMO, is just as valid of a skill. Good luck navigating this.

Except you are invested in languages and technologies that are falling into disuse and may not be used anywhere else.

And most of the legacy maintenance roles are staffed by legacy employees. I don't think there is much of a market for this particular skill.

My take is, 25 years ago, people were writing software that _had to work_. We weren't writing stuff for "non essential" smartphones and social media networks. Nowadays, most node packages could care less if it crashes 1-15% of the time because they're just displaying kitten and instagram selfies anyway.

I'm in an industry that _needs_ exactness, and a huge swath of frameworks are insufficient; Poor handling of input verification, no edge case detection written, no unit tests, no branch coverage even if tests are written, and worse, just poor code sanitation in general: no formatter, no consistent architecture, no explanation of operating theory, no gpg signatures. These basic practices that were commonplace were something to be proud of and display of your professionalism, something that's been lost.

Call me old. I'm going to go yell at the kids on my lawn now.

It really doesn’t feel like the ecosystem is ready for prime time yet, yet here we are…

So basically you are really good at what you're doing so you get those assignments. Code maintenance is hard and requires experience and familiarity. Other reasons might be cultural.

In any case, if you want to move on to different types of work then expressing interest is a very weak way of doing it. Even in great teams/orgs you need to do more than just say "it would be nice if".

Make a _decision_ and then inform your peers and managers of that decision. If there is a conflict, then work on resolving that conflict within a reasonable timeline. Compromises can be fine, but you first have to assert where you want to go, basically force people to take you seriously. Do all of that in a professional and rational manner and you'll get there.

Exactly and also knowing when to be conservative about changes and when to be a bit bolder. That takes experience and trust.

It might be because they see in you very strong skill with old flaky code that others are not trusted to fix but it could be that they see you as old-fashioned, uninterested or unmotivated and therefore they don't "feel" that you will be the right person for new stuff.

You could always build some things and then talk to the bosses and ask them. If they can't give you an answer, it is likely to be a negative reason but if they can say e.g. "we didn't know that you knew this new stuff", you can show them what you have been working on.

You have to outbully the bullies (and develop a political presence where people have a bit of fear when they think about pushing their maintenance duty onto you), or at least to become inconvenient for such work.

It's office politics, plain and simple.

The adage “legacy code is anything committed to trunk” is informative; larger, longer-lived codebases/companies just have more old stuff by their nature.

That old Oracle database might be old but the business is running on it so it has a lot of importance to the organization. A new project might fall through before it is completed and the people on it would be the first to be laid off because there is nothing for them to do.

This is true in practice, but in my opinion it's self-fulfilling - maintaining systems often takes more skill because they were built (or modified) by people with less skill.

When skilled people build a new system, it takes less skilled people to maintain it. Of course, the longer the less-skilled people maintain it, the higher the skill floor creeps for maintaining it.

It's not at all unusual to hire a fresher to start a project and then have an experienced person do the final work to put it into production.

Maybe 1/3 of the time this works really well and you can deploy the system faster than management can approve the deployment. The rest of the time (which consumes more of your time because these projects drag on and on) the fresher got the project to the point where it seemed 80% done to management but the work that is really left to be done is intricate and immense.

Often management thinks the programmer who started the project was really productive and that the finisher is "slow"; they think it would be great if they could get more people like the starter but the reality is that with people like that they wouldn't deliver consistently and the quality of what they'd deliver would be terrible.

It's one thing to feel unappreciated but it's particularly destructive when the finisher internalizes this attitude that they really are unproductive.

1. I have high-level knowledge about a lot of tech stuff. I'm that kind of idiot who isn't an expert on anything, but knows enough to be able to pick the right tools and work with them successfully (as in, finish the project).

2. I think I'm really good at communicating with other people in a work scenario.

3. I had a proven track record of finishing legacy tasks on time.

4. I don't usually go around seeking approval from others, especially on the things that I'm really confident about.

5. I'm independent, not only in the code I write but I can also make project decisions, initiate change, handle high pressure situations.

It's a tough rut to get out of but I think you have some leverage if you choose to use it. New frameworks and new projects come and go, but that boring hideous legacy system is the one that survives and the one that brings in money to company. Use that to your advantage to get a raise, create some opportunity, or failing that, bounce to a different company.

Greenfield is always more stressful to me. The deadlines are ridiculous and the requirements sketchy.

1: Go work for a startup, or an otherwise young company. Just remember to screen the company very carefully, because working for a startup is inherently a little more risky than a large, stable, mature company.

2: In your 1-1s with your manager, make it abundantly clear that you're unhappy working on legacy technology and that you'd like to transfer to a team working on a newer stack. At the same time, network within your company to find a team that's working on a newer stack. There may be an internal job board you can look at too. (If your manager blocks you transferring to another team, see #1.)

I feel your pain. Legacy systems breed a laziness in me personally. Because I know at best I can make a 1% improvement here and there, so it gets less of my energy. Being new in a legacy thing can help, you come in with green eyes and start fixing things no one else thought to. But that runs out eventually.

Exactly this. I remember when I was in school it was definitely stressed to us that if we ever find ourselves working on a greenfield project to consider ourselves extremely lucky. 90% of software development is happening on established codebases.

The real problem here stems from the promotion cycle that over-rewards new features and under-rewards maintenance work. This is uniquely a software problem as in any other industry, replacing the plumbing is extremely well-rewarded.

Since you are intimately familiar with the flaws in legacy code, you are uniquely positioned to think about what a refactor or a complete rewrite on a different framework, or a different language, or even a new platform, would look like. Whatever you come up with would be a great step forward for the current product.

Once you have a vision, sketch out a strategy and present it to your manager. Then, this is key, regardless of what the manager says, start working on it on the side. Bring that vision into your legacy code either as piecemeal updates or wholesale as a brand new prototype. Once the prototype is working, present it to your manager. Once again, the key bit is that it does not matter what the response is. Keep refining it, because ultimately you know better than they do what legacy code needs. Ultimately legacy code will becom unmaintainable due to deprecation, platform switch or other factors. That’s when your prototype becomes the fastest replacement and gets you the promotions.

In short, you must create your own new work. Don’t wait for permission. Once you are successful at this a few times, the company will give you a much freer hand to implement new features wherever you see the need, since you have proven yourself to know better.

Like most of the time in similar situations, you probably have a temper and demeanour that makes it convenient for them to take advantage of you.

Whatever you're doing that makes it convenient for them, you need to change it.

If management deems it to have merit, you're shoe-in for dev lead. I've seen guys do this and make it up to Director level.

"Hey manager, I expressed an interested in doing xyz over the last three months during our one on ones. project x recently started which focuses on doing y. I wasnt chosen to work on that project. Is there a specific reason why?"

Or go find a new job where they tell you you will be working on xyz.

It's likely just because you are good at working on legacy work and unless you make noise you wont be moved.

DON'T SAY: "I want to work on greenfield projects."

DO SAY: "What would you like to see from me, so that six or twelve months from now I'm able to be a part of greenfield projects?"

This applies to asking for pretty much anything from management.

You are given legacy projects because you are one of a small group that has experience with those legacy projects. You work on legacy projects getting more experience than anyone else the cycle repeats.

The secret is that while you work on less valuable legacy projects your knowledge is more valuable because of supply and demand. Legacy systems demand people with the knowledge to maintain them, developers chase the latest and greatest tech so there isn't much supply.

Use the experience to your advantage take ownership of the projects and suggest that the legacy code should be replaced with whatever you want and as the person with the most experience you are the ideal candidate to lead the new development.

If this doesn't work ask for more pay or you will walk. Because no one wants to work on legacy stuff you can't be replaced and your boss will know this.

Your boss can pay you more or migrate the legacy system to a tech stack that every one knows so they don't have to pay for expertise. It's a win win for you, you get more pay or to work (realistically lead) the new tech.

Maintaining established things (no computer related stuff is truly old, only by our "standards"), whether hardware or software related, requires steadiness, and a predictable path. It requires a memory of past fixes and the results and pitfalls of changes made. It requires a knowledge of the complimentary interactions and competing goals of disparate systems on the same system (PC, network, domain, etc...).

There are two different skill sets involved. Perhaps management has evaluated you for one skill set over another. Honestly re-evaluate your ability and self-learn for the desired outcome but note that working with your natural ability is best.

Also note: It is possible you work for a bunch of screwballs that have bad management practices. You should at least consider this possibility but don't make it your primary consideration as it could destroy your career.

No matter what you find, Have Fun!

If so, the solution is to be less accommodating. Insist on being part of the new development, and that legacy maintenance should be a shared responsibility of the whole team. No one wants to do this stuff, so why should it all be dumped on a few? I think willingness to help with old stuff is good, maybe even necessary -- someone has to do it -- but it isn't reasonable to expect you to be the only one.

You must back this up by preparation to leave. Actually looking for another job may help. Finding a market for your skills may give you more confidence to say "I'd like to stay but I'm not growing in this job and that's career suicide." If, after a number of conversations and some time you aren't getting anywhere -- leave.

If you are a woman, it's possible that you are generally inclined to be more accommodating, and may need to do some thinking (and/or get some coaching) on how to effectively assert yourself.

But in reality, most engineering time in the world is spent doing maintenance work or incremental improvements. This is the nature of building intangible digital products - it's not like tangible products (e.g., building a house), there's not a clear finished line. It's hard to declare a software product as "done". There'll be a lot of ongoing bug fixes, incremental improvements...

In other words, most engineers in the world are doing things that are not hacker news/techcrunch-worthy.

To stay intellectually curious, I think you can try to build side projects while learning new technologies. But I think it's also okay to treat your day job like ... a day job, just like other professions. No need to feel guilty for not using new tech or doing exciting things. You are bring in paychecks to support your family, and this is a great accomplishment already.

Now, the optimist in me says, hey, don't worry, being good at the "maintainer" role, especially for legacy code is a highly desirable, excuse me, highly *hirable* experience to have. Do you know how much legacy code exists out in the world!?! This makes for tons of opportunities to make plenty of money as a consultant/contractor. Remember during the pandemic, i think it was the state of NJ was begging for COBOL programmers, and you think they would pay crap since they were in such dire straits? Ok, maybe COBOL is a stretch example, but believe me that you can make a very healthy and profitable living as being a maintainer of legacy code. I suggest you research what tech stack is most commonly needed out there by reviewing job descriptions.

Of course, if you really, really want to only work on the newest things...then startups are your likeliest destination, or maybe just do it on the side yourself. Nowadays, myself, i want to work on legacy stuff...because i would rather get highly paid for somewhat boring stuff to manage (extra great if its boring AND EASY)...and then on my own time, i can have my own side projects, or maybe volunteer (code-wise) for one of my local non-profits, etc. Good luck!

This is as it should be. It means that the software which people have already created is working and generating value. It's not necessary or desirable that as an industry, we should keep making new things non-stop.

Maybe you really want to be one of the people doing "greenfield" work. If that is really important to you, start looking around and see what other work opportunities are available. Your current employer might give you that opportunity if you ask, but they might not. If they don't, does it matter enough to you that you would switch jobs for it?

Don't worry about whether you are a "bad engineer" or not. That's just a distraction from the actual issue.

You can do it. Ask around and figure out what the important problems are for your organization, who is thinking about those problems. Talk to them. Design concrete solutions. Go ahead and start moving it forward.

No one is going to walk up and say, “Hey quit doing things we didn’t ask for!” Or if they do, ignore them. They’re not going to fire you when you’re working hard. Eventually someone will say, “Look how much initiative and leadership this person is displaying! Thank God somebody is doing their job around here!”

Not sure what precise industry you’re in, but general advice is to not bother with certifications. Just start solving problems and learn as you go.

Without knowing you it's difficult to know why are you selected to work on legacy software. Maybe you're great dealing with old code bases? Maybe other people has a better marketing and come as "rock star" engineers that can work with the last technology?

There are two possible "solutions" I can think of:

  - Move jobs once you're assigned to work on legacy software (change jobs each 2-4 years).
  - Work in a startup where all software is crucial for the company and even if there are no good-practices, you'll learn many "shiny" technologies.

My recommendation is to apply the 80/20 rule, use around 20% of the time to do fun stuff like refactoring that annoying class or package, add tools to react quickly to errors or to understand sql queries like tracing and better logging, take the time to write test benchmarks specially for slow functionalities and add faster or more readable code, it's fun I promise it, this's exactly what I'm doing now :)

So then what happens? You get offered that role. What do you say?

That’s the part you might need to work on. You might be giving an answer that is in more service to (say) your sense of duty than to your career ambitions and creative interests. Give some thought as to which is really your priority.

There is a lot of good advice from others here on how to pursue things though.

are they really unimportant? My goto question to find out how important something is: what happens if we turn it off?

Usually the answer is "haha please do not".

Ask the same question about "new projects that involve new tech stacks". Then proceed to the next step of the OODA loop.

I guess that my point was that OP should change the framing to something like "how can I find myself in the position where my work is appreciated".

The grass is always greener, maybe you could get a side-project on the go if you want to work with new tech?

They have you working on the thing that runs their business. They might be picking other people because your job can afford to let them go off and try something that may fail.

Something to consider, anyway.

Candidly though, any project with the word "migration" in the name is not one I'd be salivating at. Those are all long slogs of tedious fiddling, in my experience.

As a senior your best chances to work on new projects a early stage startups.

Everyone literally has to work on something new.

i think management put higher priority in the new project and needed more experienced engineers to get that going as fast as possible

Seems like business is so solid they can print money with existing systems and use it to fund the future...

OR

Business is in shambles and they're trying to moonshot their way out of it before the money runs out.

Either way, I can't imagine that situation being sustainable.