Addressable Errors
@QiWenWang1|February 4, 2016 (over 10 years ago)|2 min read
One of the biggest problems with debugging is that error and warning messages are static. The only way for errors to become more useful and evolve is for authors to tweak them and launch a new version of their software.
Unfortunately, some errors are rare and hard to reproduce. You might stumble upon them in a log-file with little context. Deploying new code is costly and time-consuming, and the error is not guaranteed to disappear or become more debuggable.
There’s also a limit to how useful error messages can be by themselves (although it’s a very good idea to constantly improve them (opens in a new tab).
The usual way to find out more about an error is to Google it to learn from others. But even then, user feedback tends to be scattered in many different places, some of which the project’s authors hardly ever visit.
The solution is simple: attach URLs
[1] to all your errors and make them collaborative [2]. GitHub wikis, gists or issues are good candidates for hosting these. Bonus points: shorten them to make live debugging (opens in a new tab) easier.
References
Related writing
Release With Evidence, Not Optimism
A release is complete only when the public system provides evidence that the intended change is live and healthy.
Developer Experience
Develop, Preview, Test
In this essay I want to make the case that prioritizing end-to-end (E2E) testing for the critical parts of your app will reduce risk and give you the best return. Further, I'll show how you can adopt this methodology in mere minutes.
Developer Experience
An ode to code golf
Reflecting on the joy and lessons of code golf competitions and hacking challenges.
Developer Experience