[dead]
Log messages are mostly for the people operating your software
11–20 of 83 posts
Re: Log messages are mostly for the people operating your software
#12While I see the point the author is trying to make, I'm not really sure I agree. Most users don't even read error messages, never mind logs. At best, logs are something they need for compliance, for most, the concept doesn't exist at all. I do agree that the logs should help you understand what went wrong and why, but in that regard the principle is the same for both sysadmins and developers and I don't really see th…
In my sysadmin work I curse every developer who makes me fire up strace, tcpdump, procmon, Wireshark, etc, because they couldn't be bothered to actually say what file couldn't be found, what TCP connection failed to be established. etc.
Re: Log messages are mostly for the people operating your software
#13While I see the point the author is trying to make, I'm not really sure I agree. Most users don't even read error messages, never mind logs. At best, logs are something they need for compliance, for most, the concept doesn't exist at all. I do agree that the logs should help you understand what went wrong and why, but in that regard the principle is the same for both sysadmins and developers and I don't really see th…
In my sysadmin work I curse every developer who makes me fire up strace, tcpdump, procmon, Wireshark, etc, because they couldn't be bothered to actually say what file couldn't be found, what TCP connection failed to be established. etc.
I get the impression that often it isn't laziness but the concept that error details leak information to an attacker and are therefore a vulnerability.
I disagree with this view, but it definitely exists.
Re: Log messages are mostly for the people operating your software
#14Depends a lot on the context and type of software.
For server side software where there is a sysadmin in charge of keeping it running I generally agree.
But for end user software (desktop, mobile, embedded) no one wil read the logs and there the logs can, and probably should, be aimed at the developers. Of course you can and should still provide usable and informative end user oriented error messages but they're not the same thing as logs
Re: Log messages are mostly for the people operating your software
#15Any group of people is target of specific log level. INFO for random folks, DEBUG for programmers etc.
Re: Log messages are mostly for the people operating your software
#16Depends a lot on the context and type of software. For server side software where there is a sysadmin in charge of keeping it running I generally agree. But for end user software (desktop, mobile, embedded) no one wil read the logs and there the logs can, and probably should, be aimed at the developers. Of course you can and should still provide usable and informative end user oriented error messages but they're not…
It doesn't. The detailed log might be nonsense to the user but so is generic error, and the difference is that the specific log message makes it far easier to find solution than generic one.
I.e. SEO-optimized
Re: Log messages are mostly for the people operating your software
#17While I see the point the author is trying to make, I'm not really sure I agree. Most users don't even read error messages, never mind logs. At best, logs are something they need for compliance, for most, the concept doesn't exist at all. I do agree that the logs should help you understand what went wrong and why, but in that regard the principle is the same for both sysadmins and developers and I don't really see th…
> Most users don't even read error messages, never mind logs.
They don't need to. The log message is so helpdesk have something actionable, or so it can be copy pasted into google to find people with similar problem maybe having solution.
Re: Log messages are mostly for the people operating your software
#18Earlier quoted context omitted.
In my sysadmin work I curse every developer who makes me fire up strace, tcpdump, procmon, Wireshark, etc, because they couldn't be bothered to actually say what file couldn't be found, what TCP connection failed to be established. etc.
I get the impression that often it isn't laziness but the concept that error details leak information to an attacker and are therefore a vulnerability. I disagree with this view, but it definitely exists.
In a message returned by a server to a client I suppose it's defensible. For writing to syslog, event log, a log file, etc, it's not.
Re: Log messages are mostly for the people operating your software
#19Of possible interest:
* https://dave.autonoma.ca/blog/2022/01/08/logging-code-smell/
* https://dave.autonoma.ca/blog/2026/02/03/lloopy-loops/
Both of these posts discuss using event-based frameworks to eliminate duplicative (cross-cutting) logging statements throughout a code base.
My desktop Markdown editor[1], uses this approach to output log messages to a dialog box, a status bar, and standard error, effectively "for free".
[1]: https://repo.autonoma.ca/repo/keenwrite/tree/HEAD/src/main/j...
Re: Log messages are mostly for the people operating your software
#20I feel like this is an outdated point of view now. Logs are clearly going to be read primarily by agents very soon, if they're not already now.
For example, we're experimenting with having Claude Desktop read log files for remote users. It's often able to troubleshoot and solve issues for our users faster than we can, especially after you give it access to your codebase through GH MCP or something like that. It's wild.