13 ms·
You're not a senior engineer until you've worked on a legacy project (2023)
- deleted 2y ago[deleted]
- gregjor 2y agoEvery project either fails or turns into a legacy project.
- jmclnx 2y agoAnd I would add, you are not an "expert" until you had to reverse engineer a program who's source disappeared a decade or more ago :) But an interesting article for modern times.
- pjc50 2y agoIn contrast to sibling comment: this is actually quite fun in small doses. Wouldn't like to have to do it for an entire product, but I've done some "competitive analysis" before.
- droobles 2y agoI had to do this once and, while I do recommend the experience for professional growth, it was not fun for the most part!
- hindsightbias 2y agoThis is usually doable until it's DEWS/SAGE radar code from the 50's. That's what NASA started with and the last guy died in the 90s. We got every other subsystem off the mainframe, but had to keep it around for the radar stuff until 2004 or so.
- rramadass 2y agoI sense an interesting story. Details please ;-)
- hindsightbias 2y agohttps://www.baen.com/rip_moc https://www.baen.com/rip_moc 1990: https://www.ibiblio.org/apollo/Documents/MCC%20Development%20History.pdf https://www.ibiblio.org/apollo/Documents/MCC%20Development%2... Pirates: https://www.wbs.ac.uk/news/the-nasa-pirates-that-transformed-mission-control/ https://www.wbs.ac.uk/news/the-nasa-pirates-that-transformed... Head Pirate: https://historycollection.jsc.nasa.gov/JSCHistoryPortal/history/oral_histories/SSP/MuratoreJF_5-14-08.htm https://historycollection.jsc.nasa.gov/JSCHistoryPortal/hist... WEX/Display builder/etc: Even when I was there my young peers weren't too keen on legacy/back-end understanding. GUIs were the cool thing. I worked on something that touched many legacy subsystems so got to work with a lot of "dinosaurs" (what the Pirates called them). MCC testing was all AM shift, pirates/youts up front, retired controllers in the back. Test MOC took 30 minutes to recycle. I always sat in back if they'd let me.
- bluedino 2y agoOr the logic created by other staff that's long gone. "This is wrong!" Well, we actually do it that way because Frank told us to do it that way "Frank isn't even here anymore! That doesn't make sense! Let's just do it the right way." Three Weeks Later
- bravetraveler 2y agoOnly a little senior, if you're still working and not sitting in meetings all day - rungs remain
- syndicatedjelly 2y agoWhy is sitting in meetings all day considered the top of the IC developer ladder? I don’t want my career to end up like that
- bravetraveler 2y agoBeats me, I didn't want it either :(
- tayo42 2y agoIs there a significant amount of people not working on code that already exists? That's like the total opposite of my experience
- pavel_lishin 2y ago"Code that already exists" isn't necessarily the same as a "legacy project", though everyone's definition of what "legacy" means is different.
- tayo42 2y agoI guess, how do you define legacy then?
- esafak 2y agoOld tech
- pavel_lishin 2y agoHonestly, it's a "know it when you see it" situation mostly, but there are some strong smells indicating there's a legacy project in the walls: - none of the original authors are with the company anymore. - it's written in a language/using a stack/using technology that is used absolutely nowhere else in the company anymore. - it is big enough that migrating all of its functionality is a tremendously difficult undertaking, to the point where it's likely never going to get done, at least not in your lifetime (either in terms of your tenure at the company, or literally, before you die.) Outdated architecture/code practices/patterns are a smaller smell, as is the lack of documentation/testing - but those can be present even in greenfield projects written by a big enough dipshit - and I say this having been that dipshit at several points in my career :)
- kreco 2y agoIn one of my past job, for some reasons I was the only one diving into legacy 12+ years old code. The other members kept producing new code and debugging new code. Disregarding of whether it's fair or not, there was a kind of balance that kept the boat floating. I left since then and it wouldn't surprise me if the legacy was being rewritten from scratch (and over-engineered).
- lapcat 2y ago(2023)
- calebpeterson 2y agoI once had a manager that was fond of saying: > 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.
- pavel_lishin 2y agoEspecially when they're your decisions, decisions you pushed for and felt very good about at the time.
- calebpeterson 2y agoYep! There is no teacher quite like cause and effect.
- TeMPOraL 2y agoReinforcement learning, as usual, for the win!
- namdnay 2y agoAnd the only better experience than "working on a greenfield project long enough to watch it become legacy and see the good and bad consequences of past decisions" is working on a second greenfield project long enough to see that drastically overcompensating for all the bad things from the first one is not the right solution either :)
- calebpeterson 2y agoSo true!
- fjjjrjj 2y agoAnd the only better experience than that is killing a new greenfield project before it gets to production because the old software was good enough and the problems were organizational in how the software was being used.
- hiAndrewQuinn 2y agoBy this logic I've been a senior engineer since I started working!
- BurningFrog 2y agoSenior engineers need a better grasp of boolean logic than this.
- manojlds 2y agoNecessary, but not sufficient. By your reasoning, looks like you are still a junior /s
- jagged-chisel 2y agos/\/s//
- pseudocomposer 2y agoYou’re not a senior engineer until you understand the difference between necessity and sufficiency.
- throwaway422432 2y agoRefining/redesigning a process can be way more satisfying in the long run. Just have to remember to document those "avoided writing code" solutions for your annual review or to add to your resume.
- moltar 2y agoSame here. My first job was “take this spaghetti mess and make it better”. It was an old crusty Perl CGI codebase without any framework and a ton of bad decisions.
- joezydeco 2y agoAs 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.
- tobr 2y agoHaven’t you also often made a moat between yourself and doing literally anything else more interesting at the company?
- joezydeco 2y agoNope. If you're willing to take on the shitwork without a lot of handholding and show real progress (which actually impact earnings) you'll have a really good stab at new opportunities.
- cess11 2y agoWhat could be more interesting than code that has managed to survive in the trenches of production?
- bobthepanda 2y agoMore often than not it’s not enough work to just work on the legacy system that keeps chugging.
- powerhugs 2y agoEngineering isn't about working on the most interesting problems. It's about getting stuff done and management happy. Here, parent explained in detail how to get stuff done, management very happy and secure their position for years to come.
- ErikAugust 2y agoWell, that's just, like, your opinion, man.
- where-group-by 2y agoI 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.
- seanalltogether 2y agoYou'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.
- throwway120385 2y agoCoding practices are another tool with trade-offs involved in their use. Mental load is sometimes another word for learning. So I like to hear it from juniors because whatever is ultimately decided, it's an opportunity for them to have a real discussion around trade-offs and the benefits versus the costs of a particular approach which is invaluable for them.
- breckenedge 2y agoIt isn’t just younger developers doing this, nor even inexperienced ones. I’ve seen a ton of experienced people do this to themselves and their teams, mostly it seems to be able to pad their resume, but some honestly believe newest and shiniest is best.
- cess11 2y agoJuniors with tons of experience aren't very uncommon.
- raihansaputra 2y agoThe way i've seen it is Junior/Senior as a label of wisdom/engineering acumen and experience (not just a title) is not directly correlated to years of experience. Some people just have the same year of experience/level repeated 3-5 years. Some "Junior" with 1 YoE can come away with learnings some seniors never get in their careers. Not wholly their own fault, but it's a fact.
- breckenedge 2y ago
- varispeed 2y agoIt 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.
- tzury 2y agoWell, 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. and this is just the tip of the iceberg.
- bigpeopleareold 2y agoAll 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.
- Narann 2y agoOne 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.
- nateburke 2y agoLegacy projects usually are legacy because they have a river of money flowing through them. Making changes there is high-stakes work!
- codegeek 2y agoLegacy 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.
- milesrout 2y agoNo a senior engineer is someone with at least 3 years experience, haven't you seen any job ads?!
- jessekv 2y agoIt's like credit cards. You start with senior and from there it's gold, platinum, diamond and so on.
- hnthrow90348765 2y agoThat's nothing, I don't consider anyone a real senior unless they've maintained something for 10 years! But seriously, everyone tries to move these goal posts. We still have no good idea.
- Cthulhu_ 2y agoThe challenge there is that "legacy" codebase are just so much slower; you spend more time figuring out what needs to be done and how, than just writing code like in a greenfield project. And everyone knows the latter is just so much more fun.
- cies 2y agoLegacy is a good one. 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).
- Kuraj 2y agoIt'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.
- dlisboa 2y agoThere's also much more technical pressure on a greenfield project mainly because if it turns bad it's "your fault". There's no legacy to blame, no excusing bad choices (you made them!). It is part of the responsability but if and when it goes sour there's a bigger feeling of impostor syndrome than on a legacy project.
- thinkingtoilet 2y agoAlso, with legacy projects there is usually an array of helper scripts, classes and functions that do a lot of lifting. You have to rebuild all those as well.
- Boldened15 2y agoDid those teams have lots of senior engineers? I’d assume when you have a single tech lead over each area the team won’t fight each other since junior engineers will just follow their lead.
- luxuryballs 2y agodoes 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
- khyryk 2y agoCould be fun with a decently made legacy system without artificial pressure from POs, managers, etc., but hell when you inherit a mess and nobody (who matters) believes you when you say you need to first fix 12 issues before you can do something simple.
- elnatro 2y agoI have the feeling that I’ve mostly worked in legacy projects. What does it say about me?
- morkalork 2y agoI 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.
- abatilo 2y agoI job hop a bunch and a common theme that I have had in my jobs is to go in and understand the legacy, and bring it up to a more reasonable state. It's been interesting having to be the one dealing with someone else's consequences. I'll sometimes chat with the people who have had to maintain whatever ground work I had laid, and each time around, I get a little bit better at laying down a framework of infrastructure and operations that's better and better at staying sustainable
- ramoz 2y agoAugmenting a legacy government / mission-critical app with a chrome extension was the highlight front-end experience of my career.
- duxup 2y agoI'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.
- bornfreddy 2y agoIt's not one or the other though - a bit of safeguards here and there would make you even more productive, imho. Code reviews are indispensable for sharing knowledge within a team, automated deployments help deliver the system reliably and without unplanned downtime, and tests... People start appreciating tests when the red lights warn them about breakages in some completely unrelated places that they didn't even think were affected by what they did. And I'm not talking about 100% coverage - even covering just some of the trickier, but important flows helps immensely.
- duxup 2y agoI don't disagree generally, and in fact we're starting to build those safeguards where I am ;) Having said that process and bureaucracy is still what they are and they tend to eat up more cycles as time goes on, even if only because they're administered by humans.
- seansmccullough 2y ago> deploying a fix all by myself, no review, for a legacy product that really didn't have a good testing environment. This sounds like a great way to cause a live-site incident.
- duxup 2y ago
- nialv7 2y agoAny project that has been successful for long enough will eventually become a legacy project. So I guess it's not wrong.
- nadis 2y agoI 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."
- glouwbug 2y agoSome would say legacy code is code without unit or functional tests. I wouldn’t classify that as senior engineer worthy. Maybe masochism
- deleted 2y ago[deleted]
- diob 2y agoI 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.
- nickjj 2y agoI 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.
- urda 2y agoFor 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.
- cpeterso 2y agoMarianne Bellotti’s “Burn It With Fire: Manage Aging Computer Systems (and Future Proof Modern Ones)” is another good book about working with legacy systems, though its focus is more about managing system evolution and modernization than specific code techniques.
- urda 2y agoAdding that to my list thank you very much.
- lexicality 2y agoLegacy 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.
- HumblyTossed 2y agoI 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.
- connicpu 2y agoIt'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 :)
- begueradj 2y agoWhat about if you worked on legacy work but using AI?
- pmarreck 2y agoTruth. 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.)
- kerkeslager 2y agoI could not agree more. 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.
- xyst 2y agoYou 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 :)
- lukaslalinsky 2y agoAll 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.
- LowLevelMahn 2y ago"with almost a decade of experience" isn't a senior at all with or without legacy projects :) and nothing beats the legacyness of languages before the java/webtech times - and im not even talking about COBOL
- esafak 2y agoNot even COBOL, eh! https://www.youtube.com/watch?v=3d1phCytJyg https://www.youtube.com/watch?v=3d1phCytJyg
- herval 2y agoand 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)
- Waterluvian 2y agoI 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.
- drakonka 2y agoI 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.
- simonw 2y agoA 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.
- anal_reactor 2y agoYou're not a senior engineer until you get the skill to turn any little thing you do into a one-hour presentation and a chapter in a book.
- switch007 2y agoThis is too real Or a 6 paragraph Slack post in #general about what an amazing experience it was...to host a 30 minute Q and A on a certain topic. #community #growth #sharingiscaring
- westoque 2y agoi'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.
- juangacovas 2y agoAgree. But you need confidence on being able to debug / log / fix / revert, so having a strong knowledge of some of the parts is mandatory (i.e. server if it's web-dev, etc).
- nottorp 2y agoBut but... ant was used even in the first few Android SDKs! It's practically new and shiny!
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- InsideOutSanta 2y agoCounterpoint: You're not a senior engineer until a project you've started has become a legacy project. Nothing better than somebody exclaiming, "what the hell were they thinking when they did this 20 years ago!" and the "they" is you.
- deleted 2y ago[deleted]
- belval 2y agoMight 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.
- runeblaze 2y agoPersonally reading this thread I just realized that devs encompass so many areas. Requirement for senior engineers working on practical formal methods, real-time systems, Linux-kernel hacking, or those writing CUDA kernels all day are all gonna be different. System design is only for a broad kind, but not for all kinds, of senior engineers.
- joshghent 2y agoI agree with you. But, I have found the middle out effect in online discourse means we get articles (such as this one) polarising viewpoints for attention. Sadly, it works.
- brailsafe 2y agoMy 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.
- syndicatedjelly 2y agoLearning to never listen to PMs sounds like the opposite of being humble
- brailsafe 2y agoI was being a bit facetious with that one. In retrospect, I would have pushed back quite a lot more, but for different reasons than I did when I was in my early twenties. PMs are there for a reason, but the realistic pace that a given change can be expected to be made on this type of software, especially as a new team member, is a lot slower than I should have tried to achieve and that they would have liked, and it's important to avoid burnout. I thought I needed to earn my place and tried very hard, but slowing down and going home at the right time regardless of whether the thing I was working on was done or not, would have been smart. They placed a lot of pressure on me to produce perfect code at the same rate as all the java devs based on the assumption the assumption their job was harder because it was backend, but the tools and parameters of their work were wildly better at the time, and I had undiagnosed ADHD. So, I'd be protecting my sanity more and telling them it'll get done next week instead of trying to fit one more thing in because "it's just a button" or whatever.
- bdangubic 2y agowhat about if ALL you did was work on legacy project? :)
- bgribble 2y agoThere'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.
- milesrout 2y ago1 year old code is not legacy. Legacy is a useful category. COBOL is legacy. Maybe it is unclear exactly where to draw the line but if that were a valid reason to discard conceptual categories we wouldn't have any.
- jaggederest 2y agoI like the definition from "Working Effectively with Legacy Code", Michael Feathers says legacy code is code without tests.
- sethammons 2y agoHeh, so true in many cases. I had rewritten a utility that scanned a directory and moved files to s3 from Perl to Go and eventually a different team took over the code. A bug popped up and they were not confident to update the "legacy code." I could do not but chuckle to myself: this was like a fee hundred lines of well organized and fully unit and integration testable code with a readme and runbook and grafana/prometheus and structured logs aggregated in Splunk. And that has been running for like 2 years. They just didn't want to even attempt the fix and in fact pushed it off indefinitely.
- protonbob 2y agoLegacy code is code without tests. Doesn't matter if it's new or old.
- Boldened15 2y ago
- tcgv 2y agoGreat post! But I’d take it a step further: > 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.
- ilitirit 2y agoHard 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".
- Clent 2y agoIt feels like you're just finding other ways to describe people who are senior in title only which is far too common. Any senior that uses their title to justify a 'you can't tell me way to do attitude, is a senior in title only. I think the term is the issue. Senior development means something more intrinsic than it does in other title, like a senior manager. I think what we're attempting to define is something closer to seasoned developer.
- ilitirit 2y ago> I think what we're attempting to define is something closer to seasoned developer. I'm fully aware of that, which is why "Senior" is in double-quotes, but experienced (aka "seasoned") is not. My point is that you can be seasoned at delivering bad products. The point about seniority just speaks to tenure at a company. Sure, you can join a company as a "Senior dev", but that's not quite what I'm referring to here. One would think that they would be exposed during the interview process, but alas, we all know that's often not the case.
- losthobbies 2y agoI found doing a vb to vb.net upgrade of quite a messy codebase to be quite rewarding in its own way. It really helped to understand why SOLID principles are used.
- mordae 2y agoJunior engineer loves the rush of figuring things out. 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.
- mordae 2y agoSometimes junior engineers (of all ages) manage to green-field new project that is legacy in about a week.
- kittikitti 2y agoI 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.
- nashashmi 2y agoA 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.
- deleted 2y ago[deleted]
- ajross 2y agoBonus points if you got to watch your own greenfield work turn into a legacy project someone else maintains.
- hintymad 2y agoWe 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.
- wglb 2y ago> decade of experience in pursuing clean code 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.)
- nibab 2y agoMost 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.
- bdangubic 2y agoThey will argue for a total rewrite in my almost 3 decades in this industry THIS has been the number one way to tell a Junior from Senior SWE. nothing else comes close 2nd
- nullgazonk 2y agoProjects 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.
- amarshall 2y agoI usually say that when people say “legacy project”, it’s really “code I either don’t understand or don’t like”.
- wesselbindt 2y agoI specifically mean code not covered by automated tests. And this almost always falls in the dislike/misunderstand pile for me, but not conversely.
- Cthulhu_ 2y agoI'd argue that even with automated tests it can be considered legacy. Easier to change things if the test coverage is comprehensive enough, but I've yet to find a project like that, even the ones I built myself.
- wesselbindt 2y agoI hope you find one one day. It makes such a difference to have a test suite which you trust, and which doesn't erupt in false failures at the drop of a hat. I completely agree, not all tests are created equal.
- florianj 2y agoI 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.
- k__ 2y agoMy first job was working on a legacy project. 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.
- nvarsj 2y agoWhat if your entire career is working on legacy projects? ;-;
- userbinator 2y agoEverybody 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.
- menaerus 2y ago> 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. That's why software engineering is still very immature as a science field. It's pretty much the result of so widespread software engineers' inability to even define the problem they're trying to solve. Along with the inability to demonstrate the impact of the change and provide at least some cost-benefit analysis. And this is spreading like a cancer. Unfortunately, I see this almost everywhere and I am not sure when it all began because we were certainly not being taught such things at the University. Critical thinking seems to be lost in a signal-noise ratio.
- netbioserror 2y agoDoes 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.
- jmspring 2y agoOh boo hoo, I had to deal with Ant.
- deleted 2y ago[deleted]
- mkoubaa 2y agoThere are two axes: ------------------- 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.
- protocolture 2y agoDitto 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.
- goshx 2y agoalso, you are not a senior engineer until you’ve worked long enough at the same job to deal with the consequences of your own past decisions.
- Brian_K_White 2y agoAnd didn't cry like a baby the whole time about every trivial inconvenience and absense of magic.
- solarized 2y agoRefactoring legacy project while keeping the business running well is an arts. A doctor who can cure patient illness from mallpractice are considered senior !. Regardless their years of experience.
- bmurphy1976 2y agoAnd you're not a _seasoned_ engineer until you've worked on a legacy project with declining budgets, declining staff, and ever INcreasing demands.
- intrasight 2y agoThen 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".
- rjurney 2y agoYou're not a... engineer, engineer if you haven't worked on a legacy project. You're a junior engineer. Title inflation.
- tomlockwood 2y agoI 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.
- eay_dev 2y agoThis 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.
- bdelmas 2y agoI would also say: you are not a senior engineer until you’ve worked on a repo with the next kool aid tech where the repo’s owners left the company.
- Cthulhu_ 2y agoJust because it's the latest kool aid tech, doesn't mean it's legacy; it often feels like it becomes legacy as the people pushing it leave. But this is why technological choices need to be taken with care, and if you're in a managerial position, you should only agree on using new tech if there's dedication / guarantees for the ones pushing it, a healthy labour market, or budget to provide training for people that don't know it yet. And that's why so much is still 'boring' languages like Java, .NET, PHP and Javascript instead of Rust or what have you. I'm a Go fan though and will exclude that, as IMO Go is by design easy to learn by anyone.
- matthewsinclair 2y agoStrong agreement from me. 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.
- hoseja 2y ago>Using singletons wasn’t exactly a bad idea in this case since most of the code wasn’t covered with unit tests. Huh?
- i_am_a_peasant 2y agoI was born a senior engineer then :))))) for more than half of my career I worked on legacy stuff and now I'm at a startup and I'm killing it.
- csours 2y agoLegacy 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.
- black_13 2y ago[dead]