8 ms·

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 int

• tobr 2y ago
  Haven’t you also often made a moat between yourself and doing literally anything else more interesting at the company?
  • joezydeco 2y ago
    Nope. 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 ago
    What could be more interesting than code that has managed to survive in the trenches of production?
  • bobthepanda 2y ago
    More often than not it’s not enough work to just work on the legacy system that keeps chugging.
  • powerhugs 2y ago
    Engineering 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 ago
      Well, that's just, like, your opinion, man.
    • regularfry 2y ago
      It depends on your goals, though. Depending on the company, that can be a very good way to be treated as a cost centre to be minimised.
      • MassiveQuasar 2y ago
        Yes, let's minimize the only dev working on legacy software.
        • scarface_74 2y ago
          I don’t think the parent comment is saying that should be the case. But the way that corporate culture works, it is definitely a career killer.
        • SR2Z 2y ago
          Do you think that software becomes poorly understood and maintained because the company treats it as a prestigious job and rewards people for working on it?
        • ethbr1 2y ago
          Has said many a manager who thinks developers are fungible.
        • gecko6 2y ago
          This is how I got laid off. Working on legacy software, sole person on the team, eventually management decided that it could be replaced by AI or some such pixie dust.
        • spiffytech 2y ago
          Legacy software with a single dev can be on the fast track to getting shut down. If it was still a business priority, they'd be throwing more resources at it.
  • donatj 2y ago
    Depends on your definition of interesting? I find improving established code of far more interest and reward than greenfield. Coming to understand what a person was thinking while building something is fascinating. My updates are tangible life improvements to real human beings. That interests me, at least. Greenfield, I have the incredibly stressful job of making all the major architectural mistakes people will complain about for years to come. I'm not interested in that. There's also a much higher chance with greenfield that the product will just fail and no one will enjoy your work.
    • ninetyninenine 2y ago
      I’m interested in finding the patterns and architecture that prevents those mistakes. I think I’ve found it already.
      • donatj 2y ago
        Check back in a couple years ;)
        • ninetyninenine 2y ago
          I did it. There’s always things that went wrong. But I found the way to minimize it.
      • petsfed 2y ago
        You've found a way to correctly anticipate new user needs and new technologies years, even decades, in advance? And you've found a way to completely forestall the non-technical demands that force non-ideal design choices? You're sitting on a gold mine friend.
        • ninetyninenine 2y ago
          I should say not prevent it. But minimize it in the maximum possible way. I am sitting on a gold mine. But I can’t prove it. That’s the problem with this stuff. The industry moves horizontally with each design such that nobody knows if say the current design trend was better than the last. We go better or we go worse and nobody knows if it actually was. Maybe I am sitting on a gold mine. The problem is you’d never know about it. You’d never believe it. Because a proof isn’t possible. So because it’s not provable you have no clue about any design whether one is better or one is worse and thus you disbelieve everything. The overall question is how do you create a design or pattern that has maximum adaptability to anticipate any possible requirement change with minimal rewrites? Where you only swap in and swap out modules without changing structure? I think I found the best possible way. But you won’t believe me.
  • kerkeslager 2y ago
    I have hobbies. The most interesting work is going to be 10% interesting and 90% not interesting. In most cases it will be less interesting than that. Prioritizing "interesting" work means you'll always be exploited by the companies that can sell you on less pay, less benefits, less time off, less respect in exchange for some pittance of perceived novelty. Don't fall for this trap.
    • pmarreck 2y ago
      tell me you don't have ADHD without telling me you don't have ADHD
      • iwontberude 2y ago
        In a world where everyone has ADHD, I welcome these few non-ADHD aliens.
        • pmarreck 2y ago
          Never said I didn't!
      • seba_dos1 2y ago
        For what it's worth, I find it much easier for my ADHD to debug and improve existing code than to greenfield - it's actually interesting. Debugging is like a detective's work with small dopamine hit at each step of unraveling the situation and a huge reward once you finally grasp it. It's best to do on someone else's code, so you don't get too frustrated with your past self ;) Greenfielding provides some rewards too, but once I'd greenfielded anything remotely similar already there's a lot of forcing myself to do it around the beginning and end, where there's plenty of unrewarding work to do. For greenfielding to be fun and easy, it needs to be a completely new area that I had no previous experience in, but that doesn't tend to end up with excellent results.
        • _cenw 2y ago
          On the other hand, the infrastructure variant of this is the exact opposite. Trying to figure out if something specific is in use and who uses it or if someone just clicked around in your cloud console and forgot about it is the worst. There's only so many ways I can be inventive in building proxies to measure usage. We sometimes get incidents that things someone remembers should exist do not work, only to find out that that product was retired several years ago (but someone forgot to delete some DNS records, so there's an error message from... someone's server!). But only because we asked half the company on Teams.
  • lolinder 2y ago
    I pulled this strategy at a new company and found that it opened up a million opportunities I could take my pick of. I basically got to shape my own role going forward. Why? Because I very quickly made a name for myself as someone who learns quickly and then gets stuff done even in contexts where everyone else struggles. Solving problems that have long been considered intractable is a good way to show your value.
    • indymike 2y ago
      This is 100% true. Those problems you are solving probably don’t look all that important, but, in reality, they have been blocking sales, renewals, account expansions, or even access to markets for a long time. The business side of the house has probably given up or occasionally tries to wag the dog to get it fixed.
  • andyjohnson0 2y ago
    As a senior engineer your job is to take on the unglamorous hard problems, both technical and organisational, that are holding the team back. Doing this, and being seen to do it, early-on in your time with an employer will be somewhere between appreciated and expected.
    • o_m 2y ago
      If you do this you should also be good at story telling. Not working on the new things, but making sure the core business running, is often times looked down upon in my experience. Most leaders will see the greenfield project move fast and wonder why the established and "complete" software moves slower.
      • andyjohnson0 2y ago
        Yes, thats a very good point. And one that I learned to my cost in a previous job.
  • indymike 2y ago
    > Haven’t you also often made a moat between yourself and doing literally anything else more interesting at the company Nope, assuming that code works and handles UTF8 (sorry, but there is a point where it is too far gone to save). You’ve made yourself essential. You know the business better. You are strategic. And often, you become the one person who knows the legacy code base. And you will quickly find yourself a part of super important decisions. You’ll be called out regularly for fixing things that have gone unfixed for years. You’ll also drive value by helping the company avoid spending vast amounts of money re-implementing functioning code. On top of that, new product is often a mix of new and old, so you’ll quickly find yourself in the middle of new product teams.
    • le-mark 2y ago
      These insights are essential for playing the long game; it may sound distasteful for people early in their careers. That’s fine, but when you’re running out the clock to retirement, can’t go wrong.
      • kijin 2y ago
        It's not just about job security. Even at a young age, some people find it super fascinating to work with old stuff and study the traces of people long gone. If you're that kind of person, digging into an old assembly codebase is going to be so much more fun than learning some newfangled web framework.
  • GuB-42 2y ago
    > doing literally anything else more interesting I found that working on legacy projects is often the most interesting. There is the challenge of understating the original code base, which may look messy, but is full of history, you see the architectural mistakes and their consequences, how they managed to fix obscure bugs, tackle unexpected use cases, different code styles,... Then they ask you to implement a feature or fix a bug, you have to find what can be touched and what can't, what is a bug and what is a feature, see how much time you have, and decide on a strategy. This is production code and people are using it right now, and they are efficient with it, you have to help them and not force them to relearn everything for no good reason. And there is technical debt management, your goal is to make the code better or at least not worse, but without introducing breaking changes and under time constraints. You have to manage your off time to make improvements that will help you in the future (chose wisely) as the next truckload of tickets arrive. It includes having a good relationship with your managers as no one wants you overworked, as it would just cause technical debt to accumulate with no time to repay it. And good luck getting an AI to do that, if you want job security in the age of LLMs, that's your change. It doesn't mean you can't use AI, but you certainly won't be replaced by it.
• draw_down 2y ago
  [dead]
• jlund-molfese 2y ago
  The moat is real. A shiny new project can always be cancelled, but withdrawing support for a suitably large legacy application that doesn't have a replacement is harder.
  • doublerabbit 2y ago
    And if you want a boat for that moat recommend a modernisation project for the existing philosophy.
• itronitron 2y ago
  Additionally, reading through other people's code is educational and it also builds self-esteem.
  • thecleaner 2y ago
    > it also builds self-esteem. Well crafted dig.
    • yohannesk 2y ago
      I don’t think there was any dig implied. And I will second that it will add to self esteem. Specially during discussions if you have more understanding about the code you will have both better contribution and take away
      • baobabKoodaa 2y ago
        Sure, when you succeed in understanding someone else's legacy codebase, it builds self esteem. When you fail attempting to do that, it does the opposite.
        • lanstin 2y ago
          I have inherited projects where I just could never understand what they were thinking well enough to make the service good (not running out of memory and crashing). It was very humbling; I still sometimes wake up in the middle of the night with things I wish I'd tried, but the assumptions of how it all worked was just scattered throughout a bunch of files and the assumptions of everything was just not how I'd do it.
    • ethbr1 2y ago
      Imposter syndrome is fueled by colleague deification. It's easy to view smart coworkers as superpeople... until you're reminded that they, on occasion, make dumb human mistakes too.
      • 2y ago
• BMc2020 2y ago
  Smart move. The new guy always gets what no one else wants so you're going to get it anyway.
• stego-tech 2y ago
  Small, but not insurmountable. The time always comes when a new leader and their lieutenants come into the org and prioritize new features over maintenance, at which point your moat is null and void and you’re on borrowed time. I’ve yet to find a way to build a moat that withstands that level of hostility without actively harming the organization in the process. I’d love to hear how others deal with this inevitability.
  • pmarreck 2y ago
    if you've built up respect at the company and speak your mind regarding the maintenance vulnerability, the new crew should pay attention. if they don't, then you're screwed anyway, but so is the company. source: endured this while working at a startup that was bought out by SFDC. Kept my principles, but lost the job. /shrug
    • stego-tech 2y ago
      Yup, you and Shermantanktop get what I was asking perfectly. Seeking confirmation I hadn’t overlooked anything that I could’ve done better, but you’re both dead-on. The irony is that for those of us who enjoy maintaining, improving, and eventually replacing legacy stuff (code, systems, infrastructure, etc), what we really want is often just stability in career - hence the moat. It means it’s cheaper to keep us around for the long haul than rehiring us again at current market rates every few years, especially if we’re making ends meet with a high quality of life. But that’d mean focusing on the long term, which I don’t see many companies doing in general.
  • literalAardvark 2y ago
    When you're on a reasonably large legacy project that's a pipe dream. One of the old specialty C ERPs I've worked on has literally buried more than 3 (the ones I know of) "great Ruby rewrites". There are just _so many_ features, that the newcomers always ended up on the chopping block after 5-10 years and before they could achieve real customer traction. The old project just ended up getting some more interface fixes instead (aka even more features to catch up to) and to this day the compiler for the core hasn't even been upgraded to a version that can run on anything newer than XP SP1 (the improvements in SP2 break it). Now they're doing another modernization project with some web services and stuff. We're happy to take their money for those as well. I'd be quite shocked if those do anything other than enlarge the moat of the core.
• curious_cat_163 2y ago
  That's insightful! Especially the part about "all the ghosts they had to fight along the way."
• nxpnsv 2y ago
  Good advice, now I’m going to have to figure out the office printer, and find my linkedin account…
• sethammons 2y ago
  and forgo climbing more in the org because you become indispensable in that role
• orochimaaru 2y ago
  Agree. Also, not be judgemental about the state of things as in "which moron did this". Approach it from a point of understanding and respect rather than criticism. There are multiple reasons why the code base and tooling around it are in the crusty old state. They are usually decisions that engineers or middle management had no control over. I've been with my company for a while now. Too often I find someone come in with the "this is trash and all of you are idiots" mentality. I've typically not been keen to help such folks. They usually soon ask for rescue from the very same dumpster fire they created.
• neilv 2y ago
  Also, some companies and teams do versions of this, officially or unofficially. One pre-FAANG tech company I worked had a policy (known among the local schools) that each new hire has to "pay your dues" on grunt work, before you get to do fun/glamorous work. That kinda worked for them. A problem they had was that they were doing desktop development in C and C++, which, among other purposes, had to ship software bundled with new brand-name PCs (so not necessarily able to bugfix over Web later). The real problem was that very few new grads are minimally competent at production-grade C or C++. But, in early Web years, the company couldn't hire enough experienced software engineers to relocate to a college town. So they had to try to train and retain local grads of a top CS program. That might've been part of the thinking behind "pay your dues"... before you get to make rookie mistakes with greenfield.
• AtlasBarfed 2y ago
  ... just don't make the mistake of documenting too well :-) Developers need to realize that AI means that a lot of coddling our profession used to get is going away. Employment has always been a tenuous relationship with a fundamentally sociopathic entity, but things will be getting a lot worse in the future.
• cynicalsecurity 2y ago
  It's all fun and games until eye̶s̶o̶m̶e̶o̶n̶e̶ ̶l̶o̶s̶e̶s̶ ̶a̶n̶ ̶e̶y̶e̶ management demands some new feature and refuses to understand why it would take so long to implement it on such a stable and well-established p̶i̶e̶c̶e̶ ̶o̶f̶ ̶o̶l̶d̶ ̶c̶r̶a̶p̶ project.
• rr808 2y ago
  This can go wrong, as I found. Management and Tech leadership are focussed on the new projects with latest technology - they pay the biggest bucks for these and no one really cares about the devs maintaining the old stuff - even if important. The second problem is looking for new roles you resume is filled with old tech rather than new stuff that is in demand.
  • ljm 2y ago
    I’ve found it to be the opposite but it’s not really either/or. Over here in the UK, if I constantly chase the new hotness I will have plenty of new startups to choose from but I’ll almost always be low-balled on pay with some practically meaningless equity package. Gaining more in-depth experience opens up the better paying positions further up the ladder in more established companies. Don’t want to keep your head in the sand for years but at the same time, there are a lot of skills that can’t be learned if you stay exclusively at the bleeding edge.
• yibg 2y ago
  Similar here. First thing I do when joining a new project is to fix bugs in a legacy product. Forces me to read through the code, follow the data and execution. Nice thing about bugs is also they (mostly) have defined behavior.
• sbaidon94 2y ago
  Cannot recommend this enough, this mindset will set you up for success.
• devnullbrain 2y ago
  >embedded engineer Important note: building the moat means you can one day be promoted to principal and make junior webdev money