Skip to content

Instantly share code, notes, and snippets.

@dgcoffman

dgcoffman/Moving Quickly, Safely.md

Last active June 1, 2023 05:43
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dgcoffman/74c2d417626898c301c02f5a4a94c4c6 to your computer and use it in GitHub Desktop.
Save dgcoffman/74c2d417626898c301c02f5a4a94c4c6 to your computer and use it in GitHub Desktop.
Download ZIP
Moving Quickly, Safely
Raw
Moving Quickly, Safely.md

Don't run in place

  • Don't upgrade a dep unless you can articulate how the new version is better.
  • Don't switch tools unless you have a good reason. Because you heard the new thing was good, or because you think the current tool is bad is not a good reason. How is the old tool failing? List the ways. Steelman the argument that you should not switch.
  • Don't re-write anything unless you have a good reason. You not personally having written the old thing isn't a good reason.
  • Some framework fads are more worthy of adoption than others.
    • React.createClass -> classes -> function components -> containers -> HoCs -> render props -> hooks. Rewriting the same code through all of these changes is the full time job of a useless engineer.
    • Be judicious, wait a while and see how things work out for other people. Ideally, wait until you see the backlash after the initial hype. If you haven't seen any backlash, you might not have waited long enough to adopt.

Don't externalize your internals

  • Own your build configuration, co-locate it with your application code.
  • Don't publish your lint config as a separate package.
  • Don't share code across repos by publishing and installing packages unless you absolutely must. It's really inconvenient. Copy-paste should be your first solution.
  • The more you can take all the code relevant to your app and put it in the same place, the better.

Bury your dead

  • All dead code must be removed.
  • Code for variants of resolved experiments must be removed when the experiment is resolved.
  • Code that is permanently feature flagged out must be removed.
  • When in doubt, err on the side of removal. You can always revert your commit and bring it back.
  • Don't ever let anyone convince you keep dead code in the codebase because "we might need it"!

Keep your house tidy

  • Fix all console errors and warnings. Production first, but also dev. Every console.log is a bug.
  • If your test runs output anything other than PASS or FAIL and the test names, make that stop.
  • You must have zero lint warnings.
  • You must have no tests that flake fail. If you have some, disable them and assign fixing them as P1 bugs.
  • Your error log must be high-signal. Go now and ignore non-actionable errors.

Protect yourself at all times

  • If your test automation give you sufficient confidence to ship code without manual testing, stop everything and build test automation.
  • When you fix a prod bug, write the test that would have caught it.
  • If your production monitoring can't alert you when something critical breaks, stop everything that build production monitoring.
  • When something breaks in production and your monitoring didn't alert you, create the monitor that would have alerted you.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment