When something breaks in production — often at an inconvenient hour — logs are frequently your only window into what happened. Yet logging is treated as an afterthought, and the result is either near-silence, leaving you blind, or a deluge of noise that buries the one line that mattered. Good logging is a genuine design skill.
The goal is notes that your future, tired, debugging self will thank you for.
The two failure modes
Too little logging leaves you unable to reconstruct what went wrong, guessing in the dark. Too much logging — recording everything indiscriminately — is arguably worse, because the important signal is drowned in noise, and searching through it becomes its own ordeal. Both extremes fail you at the moment you need the logs most.
Effective logging lives in the middle: enough to reconstruct events, structured enough to search, and free of pointless chatter.
What makes a log useful
Useful log entries carry context: what was happening, relevant identifiers, and enough detail to understand the situation without exposing sensitive data. Using appropriate severity levels lets you separate routine information from genuine problems, so you can focus on what matters. Consistency and structure make logs searchable rather than a wall of freeform text.
A good log entry answers "what was the program doing, and what happened?" for someone who was not there when it ran.
Logging with care
A serious caution: logs must never become a security hole. Passwords, keys, personal data and other sensitive information should be kept out of logs, since logs are often widely accessible and long-lived. Think about who can read them and for how long.
Approached deliberately — meaningful context, sensible levels, no sensitive data, neither famine nor flood — logging turns a production mystery into a readable story. It is worth designing rather than sprinkling in as an afterthought.