2 ms·

Always be refactoring - work that shit into the ticket.

• JohnFen 7y ago
  Yeah, that was my intention when I saw what I had to work with. But it was also specifically prohibited.
  • etxm 7y ago
    How do you prohibit making code better? > for each desired change, make the change easy (warning: this may be hard), then make the easy change And all that jazz... Was your boss a super dev reading the code and calling out if it looked better?
    • JohnFen 7y ago
      > How do you prohibit making code better? By instituting a "minimal change" rule. No code changes were allowed for general refactoring. If you're fixing a bug, only the bare minimum changes to address it were allowed. If fairness, the rule was not entirely irrational. It was very difficult to make changes that didn't break stuff all over the place, and "minimal change" helped to reduce the short-term risk. This did allow some refactoring to get sneaked in, of course -- sometimes a bug required rearchitecting code, which comes with the opportunity to refactor. And if you're adding a new feature, the new code can be properly done. > Was your boss a super dev reading the code and calling out if it looked better? Pretty much. He was involved in all code reviews. He single-handedly wrote the initial implementation, and I believe that he took any criticism of it, overt or implied, as a personal attack. The truly scary part of this (for me) is that this is an enterprise product that is pretty widely used by major corporations in system-critical deployments.