• 0 Posts
  • 15 Comments
Joined 9 months ago
cake
Cake day: February 19th, 2025

help-circle










  • You’re going to want to follow the “campsite rule” everywhere you go, and also sneak in positive refactors into your feature changes (if business is not willing to commit time to improving the maintainability of the codebase).

    Read up on good software design principles. I don’t know you experience level, but for instance, everyone agrees that appropriate abstraction, and encapsulation make code easier and more enjoyable to work with, and will let you run tests on isolated sections of the code without having to do a full end-to-end testsuite run.

    Having tests that you trust, especially if they execute quickly, will increase your “developer velocity” and let you to code fearlessly–knowing that your changes are reasonably safe to deploy. (Bugs and escaped defects will happen, but you just fix them and continue on.)

    Good luck!


  • The fact that documentation and comments can’t “fail” if the underlying code changes is a real problem. I’ve even worked at places which dictated that comments had to go directly above or even beside (inline) with the code they were explaining, so they would show up in any patches changing the code.

    What do you think happened? Yup, people would change code and leave the outdated (and wrong) comment untouched, directly to the right of the code they just changed.

    Hell, I was one of those people, so I get how it can happen.