Ask HN: Why am I always stuck working on legacy software | Hacker News Reader

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

54 pointsnus0778 comments

I never seem to get picked for the new projects that involve new tech stacks and migration efforts. At my current company I am still maintaining an old codebase and Oracle database where some peers are working on migration to AWS and snowflake. Even at previous jobs I was always staffed on the unimportant legacy projects despite expressing interest in newer exciting projects . I do try to self learn and get certifications but somehow never get chosen to work on new exciting projects . Am I a bad engineer or do I come across wrong to management ? My performance reviews go great. What can I do or change ?

View on HN

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.

I'm a really big fan of Chad Fowler's reframing of legacy: https://www.youtube.com/watch?v=qH_y45he4-o

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.

If you're working on a new project the probability that it will ever go into production is less than 100%. Say a company can afford to pay you $150,000 for the value you deliver if the system goes into production 50% of the time they can afford to pay you $75,000. This is one reason why this kind of work is often done by an endless series of short-term freshers.

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

Thanks for sharing the video. I'll also mention that reading Michael C. Feather's 'Working Effectively with Legacy Code' changed my perception of the word 'legacy' in the context of software.

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

> You're working on something that has stood the test of time

Like the janitor sweeping floors in NY grand central station.

I would say more like the restoration company coming in to fix the cracks, tune the escalators, remove the grime from the murals, etc...

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.

Not arguing with this.

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.

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.

Yeah, I think that's a very good point. It can be brain-damage inducing to constantly learn new frameworks, new infrastructure, and new ways of doing things.

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.

being a janitor often pays really well

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.

This brings to light the importance of managements messaging to the "legacy" and "Greenfield" teams.

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.

OP doesn't want to learn new stacks all the time, they simply want a change for a while. One new stack maybe. But that's what happens when you're too good at what you're doing. No I'm not suggesting they should suddenly suck, but the managers will mostly think at the products - do I want somebody less capable taking over this legacy life-saving component? The only way out is to teach somebody else in the intricacies of those old parts, while getting a chance at some new stuff. This needs management commitment and one must make a solid case in front of them. If they realize that you might be thinking to change jobs out of frustration (no threats please), I'm sure they will make the mix possible.

Two things: One, if you don't like the work assigned to you by a job, it's time to find a new job. There's no other way! As long as you fill that role, you'll be working at the behest of your employer, and although you can try, changing the distribution of work you get is ultimately beyond your control.

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.

> adding features to and improving legacy systems, IMO, is just as valid of a skill

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.

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.

I’ve recently started using node for a new client and it’s been a horrible experience. I’ve found bugs in PGP implementations. Bugs in SSH implementations. And bugs in certificate handling for TLS too.

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

As someone who was writing code 25 years ago... it crashed all the time and it was plenty non-essential. My OS crashed most days. Even phones crashed all the time. It's much better now.

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.

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

> Code maintenance is hard and requires experience and familiarity

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

Being too good may make the op stuck. Nobody wants to let go of their best engineer. These folks often become too valuable to move

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.

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.

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.

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.

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.

This is just not how it works in most companies. Unless you're a very senior engineer (and even then sometimes), just going off and doing your own thing will not be tolerated more than once.

You don’t just go off. You pitch your project and get it approved and you run it

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.

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

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.

This creates psychological and political problems.

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.

I was one of those developers who was always picked to start new projects. I started hundreds of them so far. I don't know why I was picked, but I can give you a list of things that I'd say differentiated me from my colleagues who'd never get the chance:

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.

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.

This. Legacy is where revenue is generated.

But often not where the resources are allocated. You want to be in the area of the company that’s raining money not the cost center. Code maintenance is more of a cost center

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

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.

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.

> most code is legacy code

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.

So, first thing: Legacy code is a profit centre for the company. All NRE costs have been amortized over the years, and the company counts on it to make money every year, money which actually goes to fund those other mostly hare-brained projects. The work you’re doing is often more important to the company than the shiny new port which has a high risk of failure.

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.

So, they are taking advantage of you by exploiting your loyalty and passing you up for opportunities for growth and responsibility.

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.

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.

Or, sometimes a move which can work, is you start your own skunkworks project.

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.

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

Have you asked? That would be the first thing I'd do. Make it known you want to do xyz. If a project doing that comes up and you are not chosen for it ask why. Not in a confrontational way but like,

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

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.

Yeah, this! Step one is letting your manager know. If I may suggest a strategy?

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.

> Am I a bad engineer or do I come across wrong to management ? My performance reviews go great. What can I do or change ?

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.

New things require initiative, outside the box thinking, ability to test and think around the test for flaws. How to break, fix and document those things in regard to the existing current state of technology at your workplace.

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!

It's possible that you are more accommodating than others of the company's needs and thus more easily assigned to the legacy maintenance.

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.

From Hacker News or Techcrunch, it seems that engineers are creating exciting new software projects everyday, using exciting new technologies.

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.

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.

There is a huge amount of "legacy" software out there and a huge amount of software dev work involves maintaining it.

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.

The people you perceive as getting “picked” for good projects are in reality probably generating those opportunities for themselves.

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.

Somebody has to mantain "legacy software", heck you can even tell that all software becomes "legacy" at some point.

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.

Hey take it as a compliment, would you throw a Junior developer into a complex and already working legacy system? try to answer it from the business point of view; it takes a lot of experience and knowledge to do what you are already doing.

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

It sounds like you’re good at working on those legacy systems and become more so as you keep working on them. As long as the legacy projects are there and need a maintainer, of course you’re going to be offered that opportunity.

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.

The grass is not always greener. In my experience, this is especially true of 'migration' projects. Migrating an existing system to a new stack can be the worst of both worlds if the existing system is complex and poorly designed. I am living through this right now migrating a 20 year old tangled mess of a system to 'the cloud' and it is a nightmare.

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

I got the exciting job migrating Oracle Forms to Oracle Jet and learning new JavaScript stuff. Job now: Spend half my life having to rewrite everything since the Oracle Jet team constantly deprecate features, replacing them with some new "Looks the same but completely new API" feature that I then don't have time to learn

I would just be happy that you have a job you're good at. I switched teams multiple times. I'm tired of it. I wish I could do the same stuff and actually build expertise. I'm too old to continue on this treadmill. I recently switched teams and I'm concerned about just being able to keep my job.

> unimportant legacy projects

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.

It’s unimportant because resources don’t really get allocated to that area and while it might be the companies core commodities the folks working then are largely overlook in the company hiarchy

Inadequate resource allocation does not make something unimportant. If you don't spend effort on better sleep, eat and physical exercise, that does not mean that those are "unimportant", it means that you suck at prioritization.

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

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?

I mean Oracle man, people don't use enterprise software if they're into the cutting edge. they're into cya and vesting. your stay-here option is to apply a new stack to a business problem, make that case to your boss as something to work on, and see if they say yes.

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.

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.

Software maintenance is the most important aspect of software development. It's great to work on new stuff but at some point it has to interface to legacy code so know that code becomes a requirement.

Did you consider the majority of work in large companies is legacy and maintenance.

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

Everyone literally has to work on something new.

in my last company, the under performing engineers were moved to work with legacy stuff. greenfield projects were given to senior engineers.

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

That inversion can happen, but it does make me wonder what's up with that company.

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

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.

I think this is the normal way of things. Managers don’t get prompt for making existing stuff work a little better, they get rewarded for moonshot and special projects. As such the core money makers often get neglected in favor of cool but useless new features

Start by asking for new projects?

Maybe you are better than your coworkers at maintaining code.

So that you can avoid doing the bulk of the tedious crud.

You can begin to say no.

cause it makes money

Reply on news.ycombinator.com