6 ms·

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.
  • mytailorisrich 2y ago
    A good way to secure your position is to be the go-to expert for a product with many years of life ahead of it. Fixing stuff on a legacy product may make management happy but if that product is discontinued next year then you haven't accrued technical expertise valuable to the company (but you may have built a reputation as a fixer and quick learner). So, as usual, it is a balancing act. Edit: this is my perspective from the embedded world. It probably applies generally, though.
    • ambicapter 2y ago
      It is indeed, but at the same time, things that have stuck around tend to stick around, and hot new things have a way more variable longevity score.
    • joezydeco 2y ago
      I'm referring to embedded, not web dev. When times get tight the new projects get shitcanned and the 10 year-old cash cow design gets the promised new features. One crusty project I worked on was a legacy control board for a piece of restaurant equipment. The customer, the company that built the actual machine, had been building this product for 40 years. It had been through two PCB redesigns and two different microcontrollers, but the logic was tried and true and had to survive. A port of the project from 6800 assembly to C had completely gone off the rails and the contractor was dumped. All it took was a 20-opcode fix to a routine that the contractor just couldn't grok.
  • deleted 2y ago
    [deleted]
  • no_wizard 2y ago
    > Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy Truth is harsh, however this seems to be 100% accurate for nearly all cases of employment. Rarely do you get to focus on simply interesting problems and good engineering as a primary concern
    • deleted 2y ago
      [deleted]
    • philipov 2y ago
      Boredom is in the mind, not the task. Things aren't boring, people are. An important type of intelligence is the capacity to find what's interesting about a task that others lack the imagination to see. One needs to be able to create their own interesting solutions rather than expecting them to be handed down on a plate.
      • tasuki 2y ago
        > Things aren't boring, people are. What a strange thing to say! Aren't people also kind of... things? Shouldn't they be at least as interesting as things?
      • deleted 2y ago
        [deleted]
      • johnnyanmac 2y ago
        Boredom is lacking stimulation. Even the most cutting edge task can grow boring if you need to plumb with it dozens of times over a year. Just because you can find what's unique doesn't mean it stimulates you. That's the exact issue with why neuro divergent individuals are demonize: they don't take as much interest with people as "normal people" would. >One needs to be able to create their own interesting solutions rather than expecting them to be handed down on a plate. You should tell that to every old manager I had.
        • philipov 2y ago
  • mardifoufs 2y ago
    That's a very narrow definition of engineering. And while it's not wrong, it's absolutely more of a "management" POV. Like sure, for management, engineering is mostly about what you said, but that's it.
  • dakiol 2y ago
    I wouldn't say that's the conclusion. If there's only one true thing about work is: management doesn't care about you. They can fire you for any reason, and thinking that by working on stuff nobody else wants to work on you are "safe", it's an illusion. If any the conclusion is: work on what you want, life is short.
  • bee_rider 2y ago
    Engineers have a special place in society like doctors and lawyers. Working with management is part of the job, but engineers have a professional ethical obligation to say no if they are asked to something against the public good. The split there isn’t in favor of doing stuff that’s fun and novel though; actually, the engineer should usually pick a boring proven solution if the public has a high stake in the outcome.
    • Glawen 2y ago
      Only valid when engineering something which can kill/hurt/pollute. These areas are regulated and can carry personal liabilities when it goes wrong. But the vast majority of HN topics are not concerned. Additionaly, it does not pay well
  • rkangel 2y ago
    > Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy. That's a perfectly reasonable thing to want out of engineering for yourself. I wouldn't state it as an absolute truth for all people though. Personally, I'd like to be working on something that extends the state-of-the-art a little, even if only by a tiny fraction. It can be one for the other disciplines involved - it doesn't have to be the software I'm writing that is responsible for that (and it usually isn't), but that's what I derive satisfaction from.
• 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.