[ephemeralgomi]

Probably most of their logging _is_ meaningful, but deciding how to professionally phrase each and every log message will eventually get you to decision fatigue.

The point that he was making with this was that over-logging is a good thing - this probably wasn't something the initial author thought was going to be terribly informative, hence the random string. And yet it ended up diagnosing a real world problem.

In a perfect world, by all means properly write out your messages - but if you're stalling on a log message because you're not sure how to phrase it, you may get concrete benefit from just dropping a FUUUCCKKKKKasdjkfnff and moving on.

[christoph]

So, so true.

When the problem occurs, it's pretty quick for the guy who needs to fix it at 2am, to find where it exploded in the code base, while the original developer is (maybe) passed out in a bar somewhere.

Not much else matters. He could of just done :( x 10 and had the same result. The main thing is, it's easily traceable!

[akent]

Sure, for fatal errors, random (greppable) strings aren't so bad, but the OP made it sound like his FFFFFFFFFFFUUUUUU message was expected all the time rather than an exception. If you're going to print something all the time in normal operation, make it meaningful.

[aboodman]

That isn't how I took it. I read it as: there was an error scenario that was clearly happening, which should have resulted in a particular log message. Except it wasn't, which meant that something was racing.

[vosper]

I don't know how many new logging statements you commit to production code every day, but I can't imagine it averages out to more than one or two. If you can't take the time to phrase them both professionally and meaningfully then you're doing yourself and your team a disservice.

[flatline3]

Moreover, you have, in your head, the log message that should be written.

At the time of writing the code, you're hopefully thinking through "how could this fail?"

There's your log message.

[crazygringo]

I dunno. Sometimes there's just a scenario that isn't really easy to fit into a meaningful phrase, and that shouldn't happen too often.

"FUUUCK" is awfully good at conveying the seriousness of the error, and "aslfkhsdf37" ensures that the string is unique, so you can pinpoint it instantly in your gigantic codebase.

The fact is, it kind of works. Something like "missing record (line 38)" doesn't indicate the severity, there might be 10 different "missing record" error strings in your codebase, and somehow in real life, line numbers and filenames never seem to quite match up like they should (transcompilation, async callbacks, and so on.)

[batista]

I think Dropbox did well enough financially and technically, so that the team doesnt need pedantic advice on professionalism...