7 ms·

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

54 points by nus07 4y ago

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 ?

bombcar 4y ago
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.
- JLCarveth 4y ago
  > 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.
Arubis 4y ago
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.
thebenedict 4y ago
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.
- JohnBooty 4y ago
  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.
powerhour 4y ago
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.
canes123456 4y ago
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.
- RajT88 4y ago
  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.
lbriner 4y ago
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.
gwbas1c 4y ago
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.)
SoftTalker 4y ago
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.
icedchai 4y ago
You may need to complain more. If you don't like what you're working on, say so.
Test0129 4y ago
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.
- altdataseller 4y ago
  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.
- dmlorenzetti 4y ago
  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.
deleted 4y ago
[deleted]
sinenomine 4y ago
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.
yupyup54133 4y ago
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.
jmkni 4y ago
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?
PaulHoule 4y ago
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.
- happytoexplain 4y ago
  >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.
  - PaulHoule 4y ago
    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.
paxys 4y ago
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.
- pc86 4y ago
  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.
  - rdtwo 4y ago
    You don’t just go off. You pitch your project and get it approved and you run it
exabrial 4y ago
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.
- laumars 4y ago
  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…
- ironlake 4y ago
  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.
hnthrowaway0328 4y ago
Start by asking for new projects?
runjake 4y ago
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.
papandada 4y ago
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.
wnolens 4y ago
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.
mxuribe 4y ago
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!
jones1618 4y ago
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.
randito 4y ago
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.
- jollyllama 4y ago
  This. Legacy is where revenue is generated.
  - rdtwo 4y ago
    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
dgb23 4y ago
> 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.
- teh_klev 4y ago
  > 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.
- rdtwo 4y ago
  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
eighteyes 4y ago
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.
happy_path 4y ago
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.
danabrams 4y ago
I'm a really big fan of Chad Fowler's reframing of legacy: https://www.youtube.com/watch?v=qH_y45he4-o 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.
- yobbo 4y ago
  > You're working on something that has stood the test of time Like the janitor sweeping floors in NY grand central station.
  - horsawlarway 4y ago
    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.
    - yobbo 4y ago
      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.
  - deleted 4y ago
    [deleted]
- PaulHoule 4y ago
justshowpost 4y ago
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
- gorjusborg 4y ago
  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... 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.
  - rdtwo 4y ago
    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
heywherelogingo 4y ago
So that you can avoid doing the bulk of the tedious crud.
wespiser_2018 4y ago
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.
- chernevik 4y ago
  > 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.
5cott0 4y ago
cause it makes money
petalmind 4y ago
> 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.
- rdtwo 4y ago
  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
  - petalmind 4y ago
    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".
bjourne 4y ago
You can begin to say no.
bluesnowmonkey 4y ago
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.
alexdowad 4y ago
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.
time0ut 4y ago
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.
swatcoder 4y ago
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.
AlwaysRock 4y ago
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.
wenbin 4y ago
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.
yobbo 4y ago
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.
glitchc 4y ago
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.
dangerface 4y ago
> 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.
s1k3s 4y ago
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.
Tarucho 4y ago
Maybe you are better than your coworkers at maintaining code.
yandrypozo 4y ago
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 :)
freedude 4y ago
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!
gushie 4y ago
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
chernevik 4y ago
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.
giantg2 4y ago
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.
demarq 4y ago
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.
sys_64738 4y ago
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.

54 points by nus07 4y ago

bombcar 4y ago

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.

JLCarveth 4y ago
> 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.

Arubis 4y ago

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.

thebenedict 4y ago

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.

JohnBooty 4y ago
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.

powerhour 4y ago

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.

canes123456 4y ago

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.

RajT88 4y ago
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.

lbriner 4y ago

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.

gwbas1c 4y ago

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

SoftTalker 4y ago

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.

icedchai 4y ago

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

Test0129 4y ago

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.

altdataseller 4y ago
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.
dmlorenzetti 4y ago
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.

deleted 4y ago

[deleted]

sinenomine 4y ago

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.

yupyup54133 4y ago

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.

jmkni 4y ago

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?

PaulHoule 4y ago

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.

happytoexplain 4y ago
>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.
- PaulHoule 4y ago
  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.

paxys 4y ago

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.

pc86 4y ago
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.
- rdtwo 4y ago
  You don’t just go off. You pitch your project and get it approved and you run it

exabrial 4y ago

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.

laumars 4y ago
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…
ironlake 4y ago
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.

hnthrowaway0328 4y ago

Start by asking for new projects?

runjake 4y ago

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.

papandada 4y ago

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.

wnolens 4y ago

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.

mxuribe 4y ago

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!

jones1618 4y ago

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.

randito 4y ago

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.

jollyllama 4y ago
This. Legacy is where revenue is generated.
- rdtwo 4y ago
  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

dgb23 4y ago

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

teh_klev 4y ago
> 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.
rdtwo 4y ago
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

eighteyes 4y ago

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.

happy_path 4y ago

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.

danabrams 4y ago

I'm a really big fan of Chad Fowler's reframing of legacy: https://www.youtube.com/watch?v=qH_y45he4-o 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.

yobbo 4y ago
> You're working on something that has stood the test of time Like the janitor sweeping floors in NY grand central station.
- horsawlarway 4y ago
  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.
  - yobbo 4y ago
    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.
- deleted 4y ago
  [deleted]
PaulHoule 4y ago

justshowpost 4y ago

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

gorjusborg 4y ago
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... 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.
- rdtwo 4y ago
  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

heywherelogingo 4y ago

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

wespiser_2018 4y ago

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.

chernevik 4y ago
> 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.

5cott0 4y ago

cause it makes money

petalmind 4y ago

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

rdtwo 4y ago
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
- petalmind 4y ago
  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".

bjourne 4y ago

You can begin to say no.

bluesnowmonkey 4y ago

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.

alexdowad 4y ago

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.

time0ut 4y ago

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.

swatcoder 4y ago

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.

AlwaysRock 4y ago

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.

wenbin 4y ago

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.

yobbo 4y ago

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.

glitchc 4y ago

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.

dangerface 4y ago

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

s1k3s 4y ago

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.

Tarucho 4y ago

Maybe you are better than your coworkers at maintaining code.

yandrypozo 4y ago

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

freedude 4y ago

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!

gushie 4y ago

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

chernevik 4y ago

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.

giantg2 4y ago

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.

demarq 4y ago

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.

sys_64738 4y ago

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.