I don’t entirely subscribe to the first paragraph – I’ve never worked at a place so dear to me that spurred me to spend time thinking about its architecture (beyond the usual rants). Other than that, spot on

  • blackbirdbiryani@lemmy.world
    link
    fedilink
    arrow-up
    7
    ·
    7 months ago

    Bosses will never understand this and discourage refactoring until months later nothing works and everything has to be rewritten…

    • nous@programming.dev
      link
      fedilink
      English
      arrow-up
      7
      ·
      7 months ago

      Refactoring should not be a separate task that a boss can deny. You need to do feature X, feature X benefits from reworking some abstraction a bit, then you rework that abstraction before starting on feature X. And then maybe refactor a bit more after feature X now you know what it looks like. None of that should take substantially longer, and saves vast amounts of time later on if you don’t include it as part of the feature work.

      You can occasionally squeeze in a feature without reworking things first if time for something is tight, but you will run into problems if you do this too often and start thinking refactoring is a separate task to feature work.

    • MajorHavoc@programming.dev
      link
      fedilink
      arrow-up
      5
      ·
      7 months ago

      So true! That’s why I never use ‘the R word’.

      Instead, I use synonyms:

      • performance tuning
      • proactive maintenance
      • fixed a subtle bug
      • fixed a failing test
      • corrected a CI/CD failure

      CI/CD failure is my favorite, because technically our CI/CD enforces a code review, so technically “we don’t like how this is written” counts as a CI/CD failure.