Don't get stuck maintaining legacy stuff.

If you move to new, preferably greenfield dev every so often then you'll naturally keep with the times (at least if you're working in a vaguely decent team.) If you stick in one place too long and get stuck maintaining legacy crap, then that will be your focus, and that will be where your knowledge sticks.

  • 2
    Understand and respect legacy, but don't live in it.
  • 2
    I... Don't get this. What exactly is legacy here? Say if there's a product that is 5 years old and has elements and modules "because its too risky to touch them" , then the company will have an ecosystem of adding new changes in a manner that doesn't effect the old code. This could be good or bad depending upon the implementation. In that case, the devs building new stuff would be considered legacy maintainers??

    Or if say the company has this same "legacy" codebase, but they are slowly transitioning and fixing it every sprint/at regular intervals in hopes of shifting to better techs, would those devs be considered legacy maintainers?
    For this case everyone will be working on something like what @bittersweet describes about their *beautiful* codebase :P

    I either case we are learning something very common and very useful.

    (Ps : can someone explain the title of this week's rant topic. Too much informal English for me)
  • 3

    I think the key to achieve that balance is being brave enough to delete things.

    When you ask clients or product managers what they want, they always ask you to ADD a feature.

    They'll never say: "Yeah I rarely use that button, feel free to remove it". Behind that unused button is often an unused route, an unused swath of backend code, maybe even unused database tables.

    So it's very important as a company to have people pushing for functionality reduction.

    Monitor which parts aren't used, and have the balls to just nuke them out of your product. Have tooling to detect dead code, and delete it. Git will have a backup if you ever need it again.

    Less is more.
  • 2
    @yowhatthefuck You can read it as "How do you avoid stagnating as a dev", or "What do you do to make sure you keep your skills sharp as a dev".

    When I talk about just "maintaining" legacy code, I mean just making bugfixes and maybe minor feature enhancements to the same 10+ year old software, day in day out. In short, you're just patching and bodging stuff in old code because no-one wants to touch it. You're not meaningfully improving it, there's no plan to do anything with it, you're just employed to keep the thing running, whatever it takes.

    Moving a legacy application bit by bit, or gradually improving it / bringing it up to date is a whole different ball game - that's actually one of the *best* things to do in my book, as you're gaining an understanding and appreciation of the old system while having free reign to use whatever modern features, frameworks & practices you choose to re-implement it.
  • 0
    @bittersweet those bold moves , the beauty :D . Can't wait to be in that nuking position someday

    @AlmondSauce hmm i think the definition of a legacy maintainers lies with how it is being maintained. For eg, if windows nt is to be made to run on some modern gen hardware, the devs could either rewrite some parts of it to to make it work or could nuke the biggest blockers out of the way to make that thing support even the latest version of edge or chrome.

    But yeah, Both of these could fall into the category of things that stagnates me as a dev.

    I am currently working on a not so old(2019) codebase with some technologies that are still new and running as best practices in the market. However the code as whole feels a giant Goliath that breaks here or there, like some legacy. So i am currently learning a lot as a junior, but yeah will like to work on more cutting edge techs in future
Add Comment