Make debugging easier

There’s so many little tricks I’ve acquired over the years on making software easier to debug. If you don’t make any effort to make debugging easy, you’re going to spend unacceptable amounts of time debugging each issue, as your software gets more and more complex. You’ll be terrified to make changes because even a couple new bugs might take you a week to figure out.

Here’s some examples of what I mean:

For the backend of Chessbook
- I have a command to copy all of a user’s data down to local, so I can reproduce issues easily with only a username
- I trace every local request with OpenTelemetry, making it very easy to see how a request spends its time
- I have a scratch file that acts as a pseudo-REPL, which re-executes on every change. This makes it easy to pull out bits of code and play around with it to get a better idea what’s going on
- In the staging environment, I limit parallelism to 1, so that it’s easier to visually parse logs

For the frontend
- I have a debugRequests setting which prevents optimistic loading of data, to make it easier to debug requests
- I have a debugState setting that will print out the entire state of the program after every update, along with a pretty diff of what changed
- I have a file full of little functions that get the UI into specific states, so that as I’m trying to fix bugs, I don’t have to keep clicking in the UI to get to that state.

Stay vigilant about how much of your debugging time is spent on setup, reproduction, and cleanup afterwards. If it’s over 50%, you should figure out how to make it easier, even if that will take slightly longer this time. Bugs should get easier to fix over time, all else being equal.

from Marcus' Blog by Marcus

Console | Slack for Communities