The hidden underbelly of software development is translating what you write into something that someone understands.
Someone that has no idea what you have written.
And they can’t read your code.
And even if they could read your code, they don’t want to because they don’t code.
Enter logs and stacktraces which has given rise to one of my most favourite and longest-running memes ever. It is crystal clear, in all it’s glory.
A developer cannot resolve a problem without knowing what happened – we need those logs.
But what happens when the logs aren’t there?
Or they are so incoherent that no one can understand what is being said?
Well then they are useless.
If I’m working on a new app that has some degree of complexity assigned to it, that is going to have errors shown to a user that they will have to make some kind of a decision on, take a second to think about what they want to do next.
It can be something as simple as creating a standard for how to log issues.
Give it a name – if you wrote it, chances are you know what is going to happen. If you’re doing the work to catch all these different exceptions, than let the user know.
Give it an error code – something that means something to the application, you might even be able to group them.
Link it to a Wiki – it doesn’t have to be some crazy implementation, a webpage with an extension of some additional information about the error is all that is needed.
StackTrace – and last but not least, when necessary, have a route to get to the raw logs. Maybe you don’t show these to the user, but you, the developer, you are going to want these. A simple link to the log file is all that is needed.
Here’s how all this help;
- Your users will have a common language to talk to you with.
- You’ll have a better idea of what is broken.
- You’ll have what you need to fix the problem.
When new errors crop up, add them to the package – make your life and the lives of those supporting and using your software that much simpler.
