Live data from Hacker News

Brown M&Ms, or Why No One Reads the Manual

blog.nuclino.com

11–20 of 153 posts

Re: Brown M&Ms, or Why No One Reads the Manual

#11
post #6

> If any brown M&Ms were found backstage, the band could cancel the entire concert at the full expense of the promoter. I really don't think this would stand up in court. Does anyone know of any concerts cancelled due to minor issues with the rider?

The goal is not for it to stand in court.

It's only to act as a canary, kind of a checksum (and I suspect it's not the only one, only the most obvious/curious).

When the band arrives into the venue, they check for canaries: if they see something wrong, it's a good enough reason to trigger a full inspection for serious issues.

Re: Brown M&Ms, or Why No One Reads the Manual

#12
post #6

> If any brown M&Ms were found backstage, the band could cancel the entire concert at the full expense of the promoter. I really don't think this would stand up in court. Does anyone know of any concerts cancelled due to minor issues with the rider?

Tl;dr from my memory. Numbers are estimates.

Van Halen, at the time, were doing the largest stadium stage show ever. Most tours were 2 semi-trucks of speakers and lighting, VH were ~10+. Due to the never before done scale of the show rigging weight limits are critical. Not following it could lead to a stage collapse.

VH put the brown M&M’s in the middle of the weight requirement rider. This way the production crew could easily see if the local producer actually read the rider by seeing a bowl of brown M&M’s.

Re: Brown M&Ms, or Why No One Reads the Manual

#13
post #4

Another tip: when writing communication (like email), start with TL;DR. Explain quickly who should read it and why. Start with the important stuff first, follow up with details and less important stuff.

That's a common practice in the British military. Normally abbreviated to BLUF (Bottom Line Up Front.)

Start with the actions the reader needs to take (be at point x at time y wearing z) and then go in to specifics and reasoning.

Re: Brown M&Ms, or Why No One Reads the Manual

#14
post #9
post #6

> If any brown M&Ms were found backstage, the band could cancel the entire concert at the full expense of the promoter. I really don't think this would stand up in court. Does anyone know of any concerts cancelled due to minor issues with the rider?

The brown M&M's were supposedly a canary that prompted a line-by-line check of the technical specifications of the production for errors, which would then be the grounds to cancel the show. Snopes has a good article[0] on the Van Halen rider. [0]: https://www.snopes.com/fact-check/brown-out/

It is also explained in the article. The whole point of it mentioning brown M&Ms is because of this.

Re: Brown M&Ms, or Why No One Reads the Manual

#15

An often overlooked benefit of writing documentation (regardless of whether anyone will read it) is that it forces you to explain everything in a structured way and discover things that can be improved or simplified. Same principle as rubber duck debugging.

I totally agree.

When I write documentation. I'm often at a point where I ask myself: do I document this small inconsistency/inconvenience, or do I just remove/fix it?

Often enough it's easier to make things more consistent than both documenting the inconsistency and getting people to read the docs and stop asking about it.

Re: Brown M&Ms, or Why No One Reads the Manual

#16
No one reads the manual as a conclusion is belied by the use of brown M&Ms as a canary - if no one read the manual then it would not be useful to have a canary because no one would read it and then everyone would have to check stuff to make sure it worked before performing themselves and there be an extra charge to venues for this check.

The fact that some people do not read makes a canary useful. I guess the title making a rhetorical point just flips my logic sensor.

Re: Brown M&Ms, or Why No One Reads the Manual

#17
post #9
post #6

> If any brown M&Ms were found backstage, the band could cancel the entire concert at the full expense of the promoter. I really don't think this would stand up in court. Does anyone know of any concerts cancelled due to minor issues with the rider?

The brown M&M's were supposedly a canary that prompted a line-by-line check of the technical specifications of the production for errors, which would then be the grounds to cancel the show. Snopes has a good article[0] on the Van Halen rider. [0]: https://www.snopes.com/fact-check/brown-out/

I understand its purpose as a canary. I'm just questioning the idea of "cancelling the entire concert at the full expense of the promoter" which seems false.

Re: Brown M&Ms, or Why No One Reads the Manual

#18
post #3

An often overlooked benefit of writing documentation (regardless of whether anyone will read it) is that it forces you to explain everything in a structured way and discover things that can be improved or simplified. Same principle as rubber duck debugging.

Sounds similar to teaching a subject, or making a presentation about it. You will be forced to learn it very thoroughly yourself. "best way to learn something is to teach it to someone else".

I have found that the best way to create perfect software, is to teach it to someone.

Re: Brown M&Ms, or Why No One Reads the Manual

#19
post #4

Another tip: when writing communication (like email), start with TL;DR. Explain quickly who should read it and why. Start with the important stuff first, follow up with details and less important stuff.

Good writing avoids Internet memes and Reddit speak.

Re: Brown M&Ms, or Why No One Reads the Manual

#20
post #8

I miss good `man` pages.

Me, too.

What error codes does the program return? How about some non-trivial examples of use?

And does the man page actually document the software? All the switches, all the enumerated options and data range limits for each option?

In OpenBSD: all that is there. A documentation bug is a bug.

In Linux: "best wishes, and perhaps you'd like to write the man page for this utility you use once every two years?"

Disclosure: I use linux (through sheer inertia). I started on FreeBSD though, and got used to having adequate documentation.

Post reply on HN