I hate logs; when something is broken, logs are the last place I want to look when they ought to be the first. The end troubleshooter suffers from the same prob

I hate logs; when something is broken, logs are the last place I want to look when they ought to be the first. The end troubleshooter suffers from the same problem as Electron, i.e. making developer lives easier by logging everything, and if that makes other people's lives harder who cares. It's like someone going to a hospital emergency room and the triage asks what's wrong hoping to get "slipped on ice, possible broken hip" but instead gets a five hundred thousand line report of "blood oxygen level nominal" "Ow! bumped shoulder into doorframe" "Counting body arms still 2 present" "PANIC: hasn't got a card for that birthday tomorrow" "HELP! heard on TV show earlier" "Counting body arms: still 2 present" "NOT FOUND error when looking in drawer for spoon used one from dishwasher instead" "Counting body arms still 2 present" "Result 0xDEADBEEF from procedure defined in D:\dev\2016\src\folder\inside_joke.h" "Counting body arms: arms not found. Retrying in 10uS" "Counting body arms: arms not found. Retrying in 10uS" "Counting body arms: arms not found. Retrying in 10uS" "Counting body arms: arms not found. Retrying in 10uS" "Counting body arms still 2 present". Oh well, you say, that would help the developers divine the internal state of the system. ... but they're asleep right now because they're too good for on-call work. Isn't it kind of them to provide you with log messages which is easier for them than carefully making things which work well? Oh and they won't divine the internal state of the system until after you've determined if it's a bug, reported it, and their PM has prioritised it. Until then, hopefully the tech support department knows that counting body arms stops working properly when balance is lost. I suggest that logs are mostly useful when they indicate some general flaw like "can't contact server" and less so in other situations, similar to survivorship bias: planes returning from missions with bulletholes need reinforcing in the places with no bulletholes, those are the ones which stop the plane flying when hit. Or similar to the principle that robust systems have weirder problems, because the easy problems have been designed away. Similarly, the places you've carefully built with logging are the ones which you've spend enough time on that they'll probably work. The places where faults will come from are the unloved unlogged rotting parts, or the unexpected interactions between systems. [davnicwil's "make writing more fun" article yesterday said not to head off a bunch of tedious nitpicking, so I won't, just assume trivial dismissals have been headed off as necessary].