These likely bear no semblance to Official Computer Science categorization, but these are the categories of logs in my head:

• Ad Hoc Logs
  • The echo, console.log, fmt.Println, and puts of the world. 👕
  • “I need to look at some values at this exact step, while I’m actively working” with a dash of “I really should learn proper step-and-breakpoint debugging but hey, I’ve made it this far.”
  • These are typically removed from code before committing because they add noise for everyone else who are ~~debugging their own problems~~ working.
• Automatic Logging
  • When you spin up your slurry of development tooling, your terminal is spittin’ stuff out that those tools (+ your configuration) have decided should go to “standard out”.
  • Just doin’ stuff on your website is also likely generating lots of other logs that are probably going to literal log files on disk or some other kind of log storage. This is an ancient best practice that ensures that if an alien race were to gain access to mankinds entire digital archives, they would assume that 69.699.123.420 - - [17/Feb/2023:00:01:36 +0000] "GET /feed/ HTTP/1.1" 200 121434 "" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36" chriscoyier.net HIT is our formal planetary greeting.
  • Often used for analytics reasons and rooting out problems via output that may be suppressed in other contexts.
• Error/Event Logging
  • Something happened, so I’m intentionally logging it.
  • Sentry! Data is missing!
  • Appcues! A user did something interesting!
  • Mixpanel! Someone in London bought something!
  • These tend to stay in place.

I suspect a decent amount of computer work is tending to logs of one sort or another. I’m thinking about this because it’s come up at work a decent amount lately in the form of:

• Pull Request comments to make sure to remove logging statements. (Ad Hoc Logging)
• Ensuring that logs are being sent to our main logging service, Amazon Cloudwatch, for a new service. (Automatic Logging)
• Setting up logging for a strange problem that keeps coming up with hard-to-replicate data. (Error Logging)

I also recently read Logging practices I follow from Eliran Turgeman which also mentions the concept of logging levels:

Whenever you write a log, it’s important you choose the correct log level. I personally mostly use ERROR, WARNING, INFO, or DEBUG

I imagine this is most important in Automatic Logging. So, for instance, you could completely turn off certain logs in staging and production to avoid noise there. In Ad Hoc logging, I don’t find myself using levels all that much. I know JavaScript has console.warn and console.error and such, but I don’t find them all that useful, client-side at least. We have a pretty lovely homegrown Go logger that supports levels too, but I tend to only use the default for Ad Hoc logging.

🧠 Galaxy Brain thought: I wish I could leave my own personal logging in place, and have it not bother anybody else. A console.chris(), as it were. Maybe it’s stripped in CI, but somehow my machine remembers them. Then I’d never accidentally leave logs in PRs, and could log locally with reckless abandon.