Ask HN: Why am I always stuck working on legacy software

Join a smaller company that’s writing greenfield code. There’s still legacy stuff to deal with there, too, but the proportions will be more favorable.

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

You're good at maintaining legacy code. Probably the best way would be to switch jobs, but even then you'll probably find that most code is legacy code.

Have you spoken with management about your concern? Maybe they can help you spread the load amongst the folks doing the AWS migration, allowing you to take on some of that work. If they object you can frame it as cross-training or ensuring redundancy in case of emergency.

Expressing interest is not enough. Everyone wants to work on the exciting projects. You need to come up with ideas, get involved, and fight to work on the new projects.

Have you had discussions about this with your manager, and made it clear you're interested in working on different things? How did it go? You probably have more agency in this situation than you think.

It's hard to say without knowing you!

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.

I suggest two things. You can either do both, or pick one.

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.)

If you don't want to do something, don't learn how (or don't admit to knowing).

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.

You may need to complain more. If you don't like what you're working on, say so.

Advice from someone who regularly got thrown on "new tech stacks" and finally has fallen into the "boring" work of a popular language and very defined set of well known standards:

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.

In my experience there is a dynamics similar to bullying: employees compete for visibility (height unironically helps here lol) and shipping new projects, while pushing away the rest of us, naturally leading to this distribution of roles.

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.

From my experience, exciting projects get assigned to people willing to work 50+ hour weeks and be on call nights and weekends if something breaks because these exciting new products are market-share grabs. If you have shown resistance to working long or late hours you will be put on projects that are not as time and availability sensitive.

Well you're looking after the stuff which is working and making the company money, the other engineers are working on stuff which might make money, or could be a total trainwreck.

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

Maintaining systems often takes more skill and understanding than building new ones.

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.

If you wait for projects to get handed down to you by your manager then you'll always end up with work that no one else wants to do. If you want better projects, go find them. Or better yet, start them.

The grass _is not greener_ on the other side of the fence, this I can assure you.

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.

Start by asking for new projects?

In my experience, the bitter truth is that businesses rely on unsung heroes who do the crappy jobs with loyalty and duty. They will grind to a halt without these people even though it is seldom recognized or rewarded as such.

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.

There's really only two things you can do: ask for it directly and press for a good reason why not, and job hunt where that is what you're looking for (make it clear).

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.

By your description of the situation, it sounds like your job considers you reliable and valuable.

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.

The pessimist in me thinks that maybe there is some other factor that you're negatively being pushed to do what others might think of as boring. (I'm referring here to race, gender, etc. But i won't dive into those, as others have better advice.) Now, as a counter to my previous statement aboiut you being nudged into a less desirable role, well, you can always work to embrace the "maintainer" role, and work to command more in salary, etc. If management won't/can't pay more, then use "participation in newer projects" as a "reward" in place of compensation. This opens up a whole separate, bigger topic of overall compensation...but maybe you can use some of the good that already bring to the org. as a negotiation tactic to get what you want.

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!

Are you more junior or senior than the team working on greenfield projects? Management often keeps people in maintenance either because they've stereotyped them as too green or too seasoned or maybe just they have pigeonholed you as a backfield/anchor player. Another component is assertiveness. Sometimes you have to make friends with someone on the other project & inject yourself into it. You know, "it's easier to ask forgiveness than permission." The easiest way would be if something from the greenfield project interfaces with or shares functionality with legacy systems you've worked with. If the manager hears from another team member, "Ned is helping us interface with legacy Foo & knows a lot about Bar" then they'll see you bring cross-fertilization skills.

When fixing legacy code, you can become a victim of your own success. The old crusty systems are usually the company money-makers. Once you show some success at fixing and maintaining them, you become the "go to" person for fixing them. That can be a good thing.

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.

> My performance reviews go great.

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.