[larrymyers]

This is one of those interesting paradoxes that I haven't figured out yet.

Owning the legacy software that runs the business tends to provide job security at your current job, but can hinder your professional growth at both your current job as well as any future jobs.

Getting on to projects that are intended to replace legacy software tends to get you a lot of positive visibility politically and the ability to learn new technology and skills. If the new project fails there tends to be little fallout from the failure, since so many people are attached to the project at all levels. The goal posts will move so it can be reframed as a success.

If legacy software fails it usually means long hours and a lot of people nervously asking you when it will be fixed.

Unfortunately there's just not a lot of value to being able to put on your resume that you're an expert at an older language that nobody has heard of, built on an in-house framework that will never be used outside of your current company.

[aeorgnoieang]

> Unfortunately there's just not a lot of value to being able to put on your resume that you're an expert at an older language that nobody has heard of, built on an in-house framework that will never be used outside of your current company.

I think this is, fortunately, only approximately true. Most of my career to-date has involved exactly this kind of work and it's certainly not true that there's no value in it, even on a resumé or mentioned in a job interview. And certainly some non-zero amount of people derive considerable value from exactly that kind of experience as some non-zero number of employers or customers need someone with it.

And, in a lot of ways, working on legacy systems can be both immensely fun and rewarding. Even just incremental improvement in or around such systems can itself be immensely valuable, e.g. setting-up automated builds or deployments, adding integration tests (to make future refactoring easier and safer), or rewriting or replacing a key portion of the system using newer tools or with a better design made possible due to the wisdom accumulated by a system performing real work over a significant period of time.

[noir_lord]

Most of my career has been working on legacy projects (or fixing broken ones), I like greenfield well enough but I’ve no preference for it over maintenance.

There is as much pleasure in making something broken work properly as creating the thing (imo).

It’s a steady career as well, most programming is maintenance outside of the fail fast world of startups.

[on_and_off]

Even at my current job in a startup, 90% of the code I own can be considered legacy.

The startup is 7 yo, I joined almost 2 years ago.

The gap between old and new features is enormous .. and it will take years to reach some cohesion.

[oaw-bct-ar-bamf]

I am relatively new to a project that is being sold and used in the order of millions for approximately 25 to thirty years.

It was refreshing to find out that one of the approximately 7 languages that contribute to the final executable that was abandoned in ~2007 has been revived and is now (2016ish) being maintained by Eclipse

These kind of things make you realise that the Silicon Valley way of doing things is not the silver bullet.

[on_and_off]

Yep .. it is always painful to hear stuff like "if you don't use [insert whatever is hype right now]; then you are not a real engineer" coming from a colleague.

People that have spent their careers in the silicon valley have a very distorted view of tech.

[the_af]

It is indeed a conundrum.

Working in maintaining and supporting legacy software is both an absolute necessity for the business and a possible career dead-ending move for you. You're at the same time doing important work -- if not particularly interesting or groundbreaking -- and signalling to your employer "I'm not marketable enough that you must raise my salary or risk me leaving".

Working on legacy software can also be a dead-end when interviewing with some startups. Interviewers from MuleSoft once told me to change jobs and work on more interesting, high-profile open source tech stacks before interviewing again with them. (I did, but didn't try another interview with them because I later learned what they do isn't particularly interesting, either).

Some people do specialize in obsolete software and make it their niche, but I find in my country (not the US) the degree of success with this is overstated. For example, I know very few COBOL programmers who earn a lot of money. Most are in a lose-lose situation, earning average money and... working with COBOL.

[Spooky23]

The upside of being a COBOL jockey is that you have a steady job and basically just work a runbook. Some people dig that!

[moksly]

> Unfortunately there's just not a lot of value to being able to put on your resume that you're an expert at an older language that nobody has heard of...

Depends on where you live I suppose. My city has more COBOL jobs than Rust/Elixir/Go/Haskel/Erlang/Ruby jobs combined. It’s still mostly C#/JAVA/PHP, but those hyped languages we read about all day on HN never actually become a thing around here. Node.js is the only exception I can think of. Python has certainly picked up, but most python jobs here require a degree in math or statistics.

I guess it’s probably very different in Silicon Valley and other tech hubs, but it’s my impression that most of the world still runs on something old.

[rolltiide]

> Owning the legacy software that runs the business tends to provide job security at your current job, but can hinder your professional growth at both your current job as well as any future jobs.

This became my issue with contracting. I had known expertise in one thing, but never a chance to work on another thing professionally. I could see the writing on the wall that this thing wouldn't be that competitive in the future, but the incentives to get out of it weren't there.

[simion314]

I take pleasure in refactoring code, fixing bugs that customers hit and the satisfaction I have when that user gets a quick fix or solution for his problem.

[amelius]

This only works when you have a test suite with total coverage. Otherwise, you're bound to introduce bugs and annoy users and colleagues.

[simion314]

Tests are nice to have but there are not that many tests in the projects I work. Sometimes the code is not that critical, no lives and money at risk. Then I do not refactor the entire project but only 1 section and I refactor it because it is required, like I discover a function with 5 level of nesting and 500 lines of code, if I do not rush then refactoring should be simple and I can reduce the big function in a few smaller functions , reduce some big unclear code in something that is readable like a story.

I agree that someone handing you a project that you have no idea what it does, what the features are and going and randomly refactor is stupid.

[8note]

one skill I've learned working on/deprecating and replacing legacy code is what I'd call Code Archaeology: the practice of identifying what a legacy system does given some edge case; why it does it; whether that's the right thing to do, given that the ecosystem has changed significantly; and whether that section can be safely turned off.

I haven't seen the results of putting that on a resume yet though.

[burnto]

Author Vernor Vinge describes a future "programmer–archaeologist" role in his books. The idea being that humans just keep building layer upon layer of abstractions and systems, and in the distant future there's value in exploring, understanding, and potentially modifying the older layers.

[luckylion]

Isn't that true for most things in most industries? Building an airport gets you recognition, but few people ever talk about the team that keeps it running.

Maybe that's a good thing though, because people sort themselves to the jobs they are needed at. You don't want overly ambitious risk takers who seek visibility to work on the mission critical core, you want people that value job security and long-term thinking if you really need to rely on that system. On the other hand, you don't want people planning every thing to last for decades if you're only interested in a general exploration of possibility.

[natalyarostova]

It's sort of a fundamental trade-off, the better you get at team specific actions, the more time you're spending not improving at general actions.

[draw_down]

Yeah. Stated another way, building new stuff is more highly valued than maintenance. Even though the new stuff may fail, or the maintenance may end up requiring more skill than building.

This is what our industry values; make your choices accordingly. It’s also one reason for the perception that developers are more obsessed with new shiny things than learning their older counterparts. We’re incentivized to act that way.

You can’t only look at your work in terms of what is most valuable for the business, because that may turn out to conflict with what is best for you and your career.