Hard to disagree. I can usually tell what type of type of experience devs have by the snarky, dismissive responses I've gotten on various internet forums over the last two decades. e.g. "Oh but you would never have this problem if you performed proper code review" - Random_Rockstar_Dev_254
However not all legacy projects are bad to work on. If they're decently developed, then often you'll find that most of the pain is in setting up your local codebase. e.g. sorting out make files, or header file clashes etc. And if you're lucky, some poor bastard has already done the hard work for you.
As an aside, I know tons of experienced "Senior" developers who just suck at their jobs. The problem is they have tons of experience in delivering terrible products based on terrible code and architectural decisions. They just never had anyone to show them any better. And now that they're "Senior", noone can tell them anything. Many devs who work in corporates understand this pain. Shoutouts to my peers who have to "fix" 3000 line stored procs with a 100 line "change control comment saying stuff like "2009-04-03 JS Added TAX_REF_ID". I live your pain.
EDIT: Also, if you happen to work at company that thrives on terrible legacy products, try to drill it into their heads that BAU Support is not part of the solution. Every time I've raised the issue of the mounting tech debt I've gotten the response "Business does not have the apetite to solve these issues. And why would they? That's why we have support teams".
As an embedded engineer in a new position I always volunteer to take up an old crusty legacy product that nobody else wants to touch. It's a quick education into how the company approaches projects and all the ghosts they had to fight along the way. All the business logic is there, and sometimes it's even documented.
And once you have a semblance of knowledge about how the thing works and how to make fixes, you've built a small moat around your career there.
> Experience is what you get when you don’t have any.
The only better experience than working on a legacy codebase is working on a greenfield project long enough to watch it become legacy and see the good and bad consequences of past decisions.
You're also not a senior engineer until you've been forced to adopt the coding style and practices of that legacy project. A lot of younger developers like to come into a new project and slap on the latest frameworks or coding practices that they've picked up recently, without acknowledging that breaking the standards of the project lead to higher mental load to maintain that code over the long term.
Might be true, but as someone who worked on a few legacy projects, the opposite, i.e. "You're not a senior engineer until you've worked on a greenfield project" is also true. There are skills that you won't pickup by working on old piles of code. Knowing what technology to pick, how to design your system for high-availability and how to avoid needless complexity are just as important to a well-rounded senior.
Perhaps in the end you are not a senior engineer until you've done a bit of everything.
There's no hurt feelings like the hurt feelings of a junior engineer, who has spent the last year kvetching about how much they hate working on legacy junk, hearing someone else refer to one of THEIR projects as "legacy junk".
Any code that's old enough to have its first birthday party is "legacy", which means that "legacy" is a completely useless category. Anyone calling anything "legacy" is generally just showing their own lack of experience.
It's funny because 90% of my experience has been legacy projects, and the greenfield projects for me were the hardest, because it's really hard to organize as a team to build something from ground up, not kill each other with shovels in the process, and not introduce technical debt early on that will be impossible to pay off down the road.
When joining a legacy project, most of the hardest work has already been done for you.
I started my career working on a large legacy project. It was the best learning experience, and super interesting. It certainly did not make me hate legacy projects. Work was like an investigation into who did this weird thing and when and for what reason - and there was usually a good reason. Then detangling if that reason is still valid today, or if we have time to refactor the thing appropriately to rewrite it in a different/better way, or how we can solve this obscure bug without breaking five other usages, etc. And doing all that as elegantly and non-disruptively as possible with hundreds of people on a tight timeline relying on the codebase. It was an extremely satisfying challenge.
I unironically like working on legacy projects. It's good to know it stood the test of time and my efforts spent on it won't be wasted, because it is unlikely to be dropped.
Of course this assumes there is a way to introduce improvements at all. Just keeping the lights on isn't as satisfying.
Legacy or not, I don't consider anyone really senior unless they have spent building and more importantly maintaining/fixing a system at least for 3-5 years at one single place and have done this at least 2-3 times across different companies. We all know that it is a lot easier to start a new/greenfield project with shiny tech etc. It is a lot harder to maintain especially once it is 2-3 years old and in production with tons of users.
I've run into a few engineers, very capable people and I'd be happy to work with them, but their experience was limited to very structured environments. It sounded like they were in well organized organizations.
One in particular worked for a sort of "side ways competitor". They were horrified to hear about my deploying a fix all by myself, no review, for a legacy product that really didn't have a good testing environment. It was inconceivable to them.
On the other hand, not long after, our organization of 4 coders put out a better product in 3 months than their massive organization did in 18 ... and using that some "inferior" legacy systems that just so happened to be better suited to the job than some fancy new framework.
Legacy projects are great! If you don't have any current critical time pressures, you've now got yourself a beautiful puzzle to slowly unfold and understand. If you've got things like git blame annotations turned on you can read commit messages, see past pull requests and really start to get a feel for the people who worked on the project previously and understand how their minds work.
The biggest challenge is of course trying to prevent those feelings becoming contempt, rage and resentment as you see the same mistake repeated over and over again by one person who should know better while they make funny little comments in their commit messages while writing bugs that end up causing data corruption a year down the line.
The trick is mindfulness meditation and definitely not going to LinkedIn, printing out a copy of their face and then ripping it up while screaming.
I know a guy who always says you're not senior until you've had to maintain your own project that's become legacy and I agree. Too many developers serially job-hopping every 18-24 months. They all have experience with other people's legacy code but not their own. They're all happy to build something new but if they don't stick around long enough to see the consequences of their decisions, they're lacking critical experience.
I don't like gatekeeping, but I think a Sr should be a well - rounded developer. They need to have seen enough issues to be able to make solid engineering decisions.
I would have loved more detail in the "The limited role of developers" (or maybe merits a separate follow up). On the one hand, this section feels so obviously right. On the other, roles like ops and QA evolved for reasons so curious in wrangling with this legacy product how that could've been better / different beyond just consolidating work / roles.
"The only thing left was to deploy it so that we could test it. This was a problem, of course – in this case, we were not the ones deploying it or testing it. Deploying had to be done by the ops team, and testing by the test team. Why couldn’t we, as developers, manage the whole feature from start to production instead of opening tickets and waiting for other teams before we could close our task?
Firstly, we couldn’t avoid manual testing since much of the code wasn’t covered with tests. We also couldn’t deploy the application ourselves since the infrastructure didn’t allow us to.
This had us thinking about the reasons behind the separation of duties and how our current approach is better. Seeing that our lead and cycle time on this project was significantly higher than usual (it took us weeks to deliver something we usually deliver in several days), the evidence was strongly in favor of that."
One of my most educational personal project has been to update a ten y/o mupen64plus OpenGL plugin (Rice) to OpenGLES for RPi.
So much code that looks weird that I had dig in a lot and finally understood why this tiny piece of non-sense code is actually what make the whole system working, and think about how smart the previous dev was and how dumb I would have solve the problem myself.
I prefer a flat structure where you're a junior developer if you're still in training. I've held positions where my title was senior while I worked on a few projects, both legacy and otherwise. However, I think labels like these are harmful and create an atmosphere of authority and gatekeeping. I still learn new and exciting things from everyone, including junior associates. On the other hand, I know people who label themselves as senior who could be called junior.
After enough time, none of these HR provided labels matter and the work you do signals your level, not the other way around. Just a fair bit of warning though, regardless of your level, you should know how to implement the solutions from the ground up without corporate support and IT setting everything up for you.
For readers, programmers, and engineers stopping in here asking "ok what can I do to better myself here?"
I really recommend "Working Effectively with Legacy Code" By Michael C. Feathers. It is a top notch read, and helps newcomers (and vets alike) approach these legacy systems.
A company I worked for had that classic problem of there being various older systems that didn't "belong" to any team and which nobody was confident in fixing or changing.
They did something which I thought was brilliant: they gathered a list of ALL of those projects and assigned every single one of them to an existing engineering team, whether or not that team had any relevant knowledge or experience (which was true for most of these older projects).
No team could complain about this because every other team was suffering through a similar challenge.
I think it worked really well! Bugs in older systems now had obvious owners, and teams were incentivized to dig in and figure out how the crusty old code they were now responsible for worked.
Projects are like people. Everyone shows great interest when they are being planned and brought to life. Some happen by accident and are more or less unplanned. Initially, everyone is enthusiastic about the new baby—or project. In the beginning, a lot happens, and things take unexpected turns. But after some time, things start to settle, and people's interest fades. Only a few loyal friends remain. Eventually, the project becomes a burden, and very few are willing to take care of it. In the end, many just want to let it rest in peace.
I find it incredibly satisfying to slowly figure out, document, tidy up, and very gradually morph a legacy project with the puzzle-like constraint of not actually breaking stuff or screwing over legacy consumers.
I think it’s less awful if your expectations are not that of a new project. Yes, there’s a ton of ugly bits at the interface level that you can’t fix. You make it as comfortable as possible while figuring out where to go next if anywhere.
We were lucky enough to experience explosive growth of tech industry in the past 20 years. A perk of this golden age is that one did not have to work on legacy code at all, if so we chose. Better, we got to build 0-to-1 systems[1] that could make a difference, like the first search engine, the first key-value store, the first machine learning pipeline, the first resource orchestrator, the first data pipeline, the first real-time OLAP system, the first distributed logging system, the first bespoke compiler, and the list went on.
Unfortunately, we had this level of luxury because we had growth, especially new business scenarios that involved thousands of companies and millions and millions of users, thanks to the confluence of internet, mobile, social network, cloud, and machine learning applications. I'm not sure we are going to have similar growth in the coming 10 years, but I hope I'm dead wrong.
[1] The downside, of course, is that engineers tended to abandon a project after version 0.1, like what Twitter engineers did to their Manhattan project.
Well, if you are long enough in the industry, in retrospective, most of the code, frameworks and platform you have worked on are now considered "legacy", given the dynamic fast pace of our environments.
Data-centers -> Cloud
Monolith -> API and Services
Databases....
Memcache -> Redis
JS/JQuery -> MVP Framework
Git.
and not to forget K8S.
Most engineers will scoff at the idea of patching up a legacy project if they see the slightest deviation from “best practices”. They will slam their fists on the table and claim that management keeps “piling on tech debt”. They will argue for a total rewrite and dismiss any concern of said rewrite taking years because “this is what it means to have high standards and best engineering practices”. They wear this as a badge of honor and frame the conversation as a question of morality and purity, in which they of course have the upper hand since they are not motivated by petty business concerns such as profit.
Engineers that refuse to acknowledge constraints, whatever the nature of those constraints may be, are not engineers. At best they are ideologues, at worst they are just incompetent. The most pathetic thing you can do is just continuously deny the laws of physics and reality, because it doesn’t suit you at some ideological level.
Truly elegant solutions are those that account for all constraints in the simplest, most concise way. It is those that do more with less.
It is interesting, if there is a bug reported in the legacy system, the ticket can bounce between juniors and mids for months without fix in sight. It's like they don't have ability to read and debug code.
When it is something new, it is "easy" - check Stackoverflow or ask LLM and then modify code until it "works" - which doesn't even need any understanding of how it works. Just tweak until there are no errors and screen makes the manager happy.
Since corporations started cutting budgets - don't pay for training and get developers who know how to write CV and memorised interview questions and agree to work for substandard pay, it is all slowly going downhill. More experienced developers are tired of handholding new employees through basics or very much developing the tickets for them on top of their own workload and so they quit and problems are getting bigger and bigger.
It's a very interesting experience working in a large codebase that's a few years old while we're in the middle of trying to dramatically rearchitect everything because we realized the old way of doing things was creating tons of technical debt and confusing abstraction. Even worse, we're always trying to optimize things because we've got some soft real-time requirements and we're using about 50% of our entire time budget after we upgraded our bare metal servers to Zen4 (it was more like 70% before that). Every fix turns something else into the long pole that needs to be rebuilt with the lessons we've learned about writing clear, concise, high performance code.
As it turns out, if you're operating on large data in bulk you should probably just have a dense ID map and then do everything in arrays. Nothing beats arrays :)
I kind of love working on a legacy project, its like reading a love letter from past devs, their hopes and dreams, classes describing an abstraction that was never used. It's like reading hate mail from past devs, towards their bosses, towards ways of doing things they didn't like. It's like uncovering a stack of newspapers from a time before agile, when people had eldritch and archaic ways of naming tables and variables and methods, when they spoke of things we've forgotten.
Sometimes it is a pleasure and sometimes it feels distant and alien and frustrating.
Everybody hates working on legacy projects, myself included.
I am proud that I am a part of a team that uses most of the best practices
Speak for yourself... I'm the exact opposite. Then again, outside of work I fix and maintain other physical systems which are many decades old, some close to a century, so perhaps that changes the perspective. I see so many in the software industry cargo-culting "best practices" dogmatically, creating constant churn via useless trendchasing, that they keep reinventing - badly - new ways to do the exact same things as before.
I really like turning legacy code into non-legacy code. It feels like getting to solve a mystery.
For example, maybe there's really crazy hard to follow code and the person who wrote it left a decade ago and there's no tests so it's too risky to refactor it but you can write new tests, really delve into the use case of the code and then refactor the original code.
Or, maybe the code is using a version of a framework that's 9 years out of date but you can incrementally upgrade it after gaining confidence in any way you can.
i've worked on many legacy code bases and i think an underrated skill that you need is courage.
courage to be able to push changes you think could be breaking changes but always be optimistic that you to be able to fix as soon as possible. tests are ideal, but not everyone has 100% coverage. sometimes you just have to trust your gut and do diligence and push the change. don't be scared to push something because you don't know the behavior in production. the only way to know is to try.
Then I became a senior engineer pretty early - as my first job was working on nuclear power software. We had code in Fortran that NOBODY was allowed to edit. But lots of other legacy Fortran was up for grabs.
Oh, and my favorite software tale is when we turned on the new software in the control room and the first thing the plant manager said when he looked at the new digital instrumentation was "that can't be right".
My first "software engineering" scale project was working on a existing massive 10 y.o js pub/sub and java templated webapp. Taught me why typed languages are valuable, why I should never listen to PMs, why I should be humble, why estimates are impossible but sort of important, and why long feedback loops anywhere in the entire process (including compilation) are productivity killers, along with not having an isolated private work area.
All projects I have done for the first ten or so years of my commercial work have been picking up an ancient code base long after the original team has left, and making it work. I reserved the nice and clean code for my personal hobby projects. At work, it was about getting the shit from the past working and maybe improve it a little along the way. You even adopt the coding style you hate, just to minimize diffs and making it easier to navigate the history.
> My feeling about legacy projects hasn’t changed – I still hate them (...) Instead of feeling resigned, we saw it as a place to ask questions and learn.
I see that you advocate embracing the opportunity to work on legacy projects, so I say even if you dislike legacy projects, try to avoid phrasing it so strongly. It might influence other devs in your team to develop a negative mindset toward them.
You are not a senior engineer until you work on a project from the beginning, leave no documentation, then leave the firm just as new assets are ramped up :)
I'd also add "until you've spent some time testing a code base you didn't write" to the mix. That definitely tightens your senses and busts some assumptions.
The next time you hear the phrase "... well, it worked on my machine ..." it takes on a very different complexion.
A big problem I see in software is that developers don't stick around on projects long enough to see that their mistakes are mistakes. Instead, they move on to the next greenfield project or rewrite the project in the newest shiny tech without ever actually addressing the core complexity of the problem they're trying to solve.
Ditto Network Engineer who hasn't worked on an ancient ISP, ditto System Engineer who hasn't managed an environment with decades old hardware and software.
If you can open up vendor documentation and the default solution works in your environment you are either lucky, or have gone through hell to get it there.
This may be true, but taking on too much responsibility in a project or having to do those responsibilities will make you a senior developer. Otherwise, it is not possible to get ahead of the senior developer you are affiliated with.
All I have been doing for the past 10 years is deal with legacy. At least with the current one, the legacy is more recent and provides opportunities for myself and the other on my team to iterate on whatever we got, particularly in the realm of making operational improvements.
I still remember my first job porting a VB6 code to VB.net. The code was written before object-oriented code was a thing. Back then I thought OO would have solved it. Looking back all it was really missing was a strong type system.
I have a love / hate relationship with legacy projects. They're a fun puzzle, but often times the client has suddenly realized it's not possible to reach X and then I'm called in to make X possible. It can burn me out a bit.
A senior engineer is senior because of his ability to solve problems (that juniors created). Legacy projects are a lot like a suitcase of problems that you never anticipated.
I'd be happy to have a look at anyone's legacy code to at least write an analysis paper on it. (I'm currently seeking contract work, been doing code for a long time.)
and that's why I'm a senior engineer since my first internship!
I always considered legacy projects more interesting than zero to one. A lot less reinventing the wheel and bikeshedding, a lot of puzzles - painful ones, sure, but at least it's not a bunch of CRUD (or the usual startup experience, which is a constant flux of rewriting-crud-very-fast)
Does replacing a completely unsalvageable legacy project count? It's done and dusted at this point, but I replaced a C/PHP codebase written by an IP-trolling freelancer who kept project sources as his personal IP, won back after a legal settlement. It was all deliberately obfuscated single letter naming and misdirected logic paths, along with a heavy reliance on global state. Investigating any individual part was manageable, thankfully, but I still had to unwind a great many useless stack frames and reverse-engineer several intense procedural bit-logic algorithms.
does everyone hate it? maybe I found my niche then because it’s actually pretty fun because you get to hack it up and come up with creative solutions, it’s like Indiana Jones exploring for lost artifacts, with all the perils
Legacy is when you have a shell script call an ant script that calls shell scripts that call make scripts that fire c precompile requests to a remote database. (Of course it's now packaged in docker because it runs on a version of linux that makes the infosec guys come visit you at your desk)
Oh and every subsystem shares dependency references that are only used by one subsystem.
Oh, and the C includes are wrong and overwritten by the shell scripts and make files.
GOOD LUCK
OH, and your team is too scared to use the simplified build because there are too many things they don't understand, even though you did hash comparisons for every built artifact.
Big code base. Big team. Big company. Different languages (and preferably in different paradigms; OO/FP and low/high-level). Different frameworks/stacks. And "in anger" also really helps IMHO (this means when shit went really bad and needs to be fixed fast).
You're not a senior engineer until you've worked on a legacy project (2023)
(infobip.com)777 points by tonkkatonka 14 February 2025 | 412 comments
Comments
However not all legacy projects are bad to work on. If they're decently developed, then often you'll find that most of the pain is in setting up your local codebase. e.g. sorting out make files, or header file clashes etc. And if you're lucky, some poor bastard has already done the hard work for you.
As an aside, I know tons of experienced "Senior" developers who just suck at their jobs. The problem is they have tons of experience in delivering terrible products based on terrible code and architectural decisions. They just never had anyone to show them any better. And now that they're "Senior", noone can tell them anything. Many devs who work in corporates understand this pain. Shoutouts to my peers who have to "fix" 3000 line stored procs with a 100 line "change control comment saying stuff like "2009-04-03 JS Added TAX_REF_ID". I live your pain.
EDIT: Also, if you happen to work at company that thrives on terrible legacy products, try to drill it into their heads that BAU Support is not part of the solution. Every time I've raised the issue of the mounting tech debt I've gotten the response "Business does not have the apetite to solve these issues. And why would they? That's why we have support teams".
And once you have a semblance of knowledge about how the thing works and how to make fixes, you've built a small moat around your career there.
> Experience is what you get when you don’t have any.
The only better experience than working on a legacy codebase is working on a greenfield project long enough to watch it become legacy and see the good and bad consequences of past decisions.
Perhaps in the end you are not a senior engineer until you've done a bit of everything.
Any code that's old enough to have its first birthday party is "legacy", which means that "legacy" is a completely useless category. Anyone calling anything "legacy" is generally just showing their own lack of experience.
When joining a legacy project, most of the hardest work has already been done for you.
Of course this assumes there is a way to introduce improvements at all. Just keeping the lights on isn't as satisfying.
One in particular worked for a sort of "side ways competitor". They were horrified to hear about my deploying a fix all by myself, no review, for a legacy product that really didn't have a good testing environment. It was inconceivable to them.
On the other hand, not long after, our organization of 4 coders put out a better product in 3 months than their massive organization did in 18 ... and using that some "inferior" legacy systems that just so happened to be better suited to the job than some fancy new framework.
The biggest challenge is of course trying to prevent those feelings becoming contempt, rage and resentment as you see the same mistake repeated over and over again by one person who should know better while they make funny little comments in their commit messages while writing bugs that end up causing data corruption a year down the line.
The trick is mindfulness meditation and definitely not going to LinkedIn, printing out a copy of their face and then ripping it up while screaming.
Senior engineer has come to terms with feeling like an idiot all the time and now seeks this feeling because that's where the progress lies.
Nothing else to it.
But an interesting article for modern times.
"The only thing left was to deploy it so that we could test it. This was a problem, of course – in this case, we were not the ones deploying it or testing it. Deploying had to be done by the ops team, and testing by the test team. Why couldn’t we, as developers, manage the whole feature from start to production instead of opening tickets and waiting for other teams before we could close our task?
Firstly, we couldn’t avoid manual testing since much of the code wasn’t covered with tests. We also couldn’t deploy the application ourselves since the infrastructure didn’t allow us to.
This had us thinking about the reasons behind the separation of duties and how our current approach is better. Seeing that our lead and cycle time on this project was significantly higher than usual (it took us weeks to deliver something we usually deliver in several days), the evidence was strongly in favor of that."
and nothing beats the legacyness of languages before the java/webtech times - and im not even talking about COBOL
So much code that looks weird that I had dig in a lot and finally understood why this tiny piece of non-sense code is actually what make the whole system working, and think about how smart the previous dev was and how dumb I would have solve the problem myself.
After enough time, none of these HR provided labels matter and the work you do signals your level, not the other way around. Just a fair bit of warning though, regardless of your level, you should know how to implement the solutions from the ground up without corporate support and IT setting everything up for you.
I really recommend "Working Effectively with Legacy Code" By Michael C. Feathers. It is a top notch read, and helps newcomers (and vets alike) approach these legacy systems.
They did something which I thought was brilliant: they gathered a list of ALL of those projects and assigned every single one of them to an existing engineering team, whether or not that team had any relevant knowledge or experience (which was true for most of these older projects).
No team could complain about this because every other team was suffering through a similar challenge.
I think it worked really well! Bugs in older systems now had obvious owners, and teams were incentivized to dig in and figure out how the crusty old code they were now responsible for worked.
I think it’s less awful if your expectations are not that of a new project. Yes, there’s a ton of ugly bits at the interface level that you can’t fix. You make it as comfortable as possible while figuring out where to go next if anywhere.
Unfortunately, we had this level of luxury because we had growth, especially new business scenarios that involved thousands of companies and millions and millions of users, thanks to the confluence of internet, mobile, social network, cloud, and machine learning applications. I'm not sure we are going to have similar growth in the coming 10 years, but I hope I'm dead wrong.
[1] The downside, of course, is that engineers tended to abandon a project after version 0.1, like what Twitter engineers did to their Manhattan project.
Data-centers -> Cloud Monolith -> API and Services Databases.... Memcache -> Redis JS/JQuery -> MVP Framework Git. and not to forget K8S.
and this is just the tip of the iceberg.
Engineers that refuse to acknowledge constraints, whatever the nature of those constraints may be, are not engineers. At best they are ideologues, at worst they are just incompetent. The most pathetic thing you can do is just continuously deny the laws of physics and reality, because it doesn’t suit you at some ideological level.
Truly elegant solutions are those that account for all constraints in the simplest, most concise way. It is those that do more with less.
When it is something new, it is "easy" - check Stackoverflow or ask LLM and then modify code until it "works" - which doesn't even need any understanding of how it works. Just tweak until there are no errors and screen makes the manager happy.
Since corporations started cutting budgets - don't pay for training and get developers who know how to write CV and memorised interview questions and agree to work for substandard pay, it is all slowly going downhill. More experienced developers are tired of handholding new employees through basics or very much developing the tickets for them on top of their own workload and so they quit and problems are getting bigger and bigger.
As it turns out, if you're operating on large data in bulk you should probably just have a dense ID map and then do everything in arrays. Nothing beats arrays :)
Nothing better than somebody exclaiming, "what the hell were they thinking when they did this 20 years ago!" and the "they" is you.
Sometimes it is a pleasure and sometimes it feels distant and alien and frustrating.
-------------------
Axis one: quality of the code
Axis two: how many use the code
There are four quadrants:
-------------------------
Clean code no users: enjoy it while it lasts, it won't.
Clean code and users: what are you doing here, the code is done. Get out!
Dirty code no users: a waste of time
Dirty code and users: careers are made here.
I am proud that I am a part of a team that uses most of the best practices
Speak for yourself... I'm the exact opposite. Then again, outside of work I fix and maintain other physical systems which are many decades old, some close to a century, so perhaps that changes the perspective. I see so many in the software industry cargo-culting "best practices" dogmatically, creating constant churn via useless trendchasing, that they keep reinventing - badly - new ways to do the exact same things as before.
For example, maybe there's really crazy hard to follow code and the person who wrote it left a decade ago and there's no tests so it's too risky to refactor it but you can write new tests, really delve into the use case of the code and then refactor the original code.
Or, maybe the code is using a version of a framework that's 9 years out of date but you can incrementally upgrade it after gaining confidence in any way you can.
courage to be able to push changes you think could be breaking changes but always be optimistic that you to be able to fix as soon as possible. tests are ideal, but not everyone has 100% coverage. sometimes you just have to trust your gut and do diligence and push the change. don't be scared to push something because you don't know the behavior in production. the only way to know is to try.
A doctor who can cure patient illness from mallpractice are considered senior !.
Regardless their years of experience.
Oh, and my favorite software tale is when we turned on the new software in the control room and the first thing the plant manager said when he looked at the new digital instrumentation was "that can't be right".
> My feeling about legacy projects hasn’t changed – I still hate them (...) Instead of feeling resigned, we saw it as a place to ask questions and learn.
I see that you advocate embracing the opportunity to work on legacy projects, so I say even if you dislike legacy projects, try to avoid phrasing it so strongly. It might influence other devs in your team to develop a negative mindset toward them.
I'd also add "until you've spent some time testing a code base you didn't write" to the mix. That definitely tightens your senses and busts some assumptions.
The next time you hear the phrase "... well, it worked on my machine ..." it takes on a very different complexion.
A big problem I see in software is that developers don't stick around on projects long enough to see that their mistakes are mistakes. Instead, they move on to the next greenfield project or rewrite the project in the newest shiny tech without ever actually addressing the core complexity of the problem they're trying to solve.
If you can open up vendor documentation and the default solution works in your environment you are either lucky, or have gone through hell to get it there.
Excellent.
So do I qualify if almost every project that I created in my > 50 year career is now legacy?
(Might be made slightly easier as many of the companies no longer exist.)
I'd be happy to have a look at anyone's legacy code to at least write an analysis paper on it. (I'm currently seeking contract work, been doing code for a long time.)
I could work as fast as I deemed fit, because nobody understood what I was doing. Any feature could take a day or a month.
Good times.
It really helped to understand why SOLID principles are used.
I always considered legacy projects more interesting than zero to one. A lot less reinventing the wheel and bikeshedding, a lot of puzzles - painful ones, sure, but at least it's not a bunch of CRUD (or the usual startup experience, which is a constant flux of rewriting-crud-very-fast)
Oh and every subsystem shares dependency references that are only used by one subsystem.
Oh, and the C includes are wrong and overwritten by the shell scripts and make files.
GOOD LUCK
OH, and your team is too scared to use the simplified build because there are too many things they don't understand, even though you did hash comparisons for every built artifact.
Others:
Big code base. Big team. Big company. Different languages (and preferably in different paradigms; OO/FP and low/high-level). Different frameworks/stacks. And "in anger" also really helps IMHO (this means when shit went really bad and needs to be fixed fast).
Huh?