Selfelected

Readable logs

In production we usually rely on logs to track down an error.
Even worse; in production we have more data and more logging to sift through than in development. The trees can be lost in the woods. If we are more unlucky we also have a time restraint.

To learn how to read a log file we must train. This means reading log files. And to read the we must first write to them; in a readable way.

So I write log files and read them to find my errors already in development. Training for production.

Learn to write

Too little information is bad. This is the usual case. Too much information is bad too as we cannot see the flow of the program due to uninteresting information. Writing the exact amount of information for every time is probably not doable but by training I learn and get better at it.

Readable code

If we develop the application through setting breakpoints and inspecting variables we are in a bad spot when production error happens as we seldom can do that.
All we have is a log with a stack and possibly a rough idea of the input.

If I instead learn to read the code and trace the execution path manually, already in the development phase, I am in a much better position when production hits the proverbial fan.

Startup time

Connecting the debugger takes time. Just starting the program is faster.

I only connect the debugger when I have to.

Tags: logging