Live data from Hacker News

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

blog.nuclino.com

121–130 of 153 posts

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

#121
post #116

Earlier quoted context omitted.

This was in 2013, pre-GDPR but in 1998 DPA territory. Yes, I do feel it was probably a DPA violation even back then. In Ireland next of kin is purely for cases where the person has been incapacitated/hurt and someone needs to be told. Nothing to do with dispersal of benefits etc. There's a separate process for all that.

Sorry, yes, I forgot to include informing them of a workplace injury. And I assume GDPR wasn't in force there and then, just thinking of it as a hypothetical.

The 1998 DPA was still pretty strict. I have no doubt the DPA was violated when they called my wife.

I blame the manager who came from a sales background. His response to every problem was to "call someone", rather than have the team work out what was wrong.

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

#122

Earlier quoted context omitted.

A good story, and I find myself in a similar position (the one who writes the docs). I think a lot about this topic, because as our company grows it becomes more and more important, and more and more difficult to impart all of the scattered knowledge on new hires. I really enjoyed this read. I think it contains actionable suggestions that I will incorporate into my job. Consultable documentation, all in a single loca…

I agree with both (1) and (2). We require all devs, as a part of the onboarding process to read, improve and correct the docs for onboarding for each new hire. A PR is required. This forces all developers to understand what happens when something actually breaks and also how to locate the information, should the need arise. This is also why we've never Dockerized. It masks too many issues and no one seems to have a c…

When I'm asked a question I often respond it is on the wiki. If it isn't on the wiki it is your job to put it there. If it is wrong and you know why fix it. If it is wrong and you fail to figure out why, then talk to me, but I won't respond except to say I fixed the wiki.

That way the wiki stays up to date. Most corporate documents/wikis are worthless after a few years because things change but the wiki didn't. You need to constantly update it.

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

#123
post #58

> We are impatient and have a shorter attention span than a goldfish. To be properly absorbed, information needs to be organized in a way that accommodates that. Common myth, but actually not true. Joe Rogan has 3 hour long talks with people and is one of the most popular media figures. The real truth is, most information sucks (it's both useless and boring), so people tune out. Improve information, get more attentio…

Agreed. I got excited about podcasts really early on because there are so many interesting deep dives on so many topics. There are exceptions but most traditional radio shows cover topics briefly, terribly, or both. The fact that podcasts have exploded in popularity is strong evidence that many people enjoy more detailed discussions on many subjects, they just didn't much access to them in traditional media.

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

#124
post #57

I haven't read manuals ever, but last month I bought bluetooth headphones so to pair them I first tried without reading, and failed. I opened the manual to find it was many pages of legal text and just one phrase of instructions: "hold button for 5 seconds until light is blue" and that failed too. I mailed support and the instructions then came back as "hold for 20 seconds, until light first becomes white, then blue"…

This has also been my experience writing documentation. You write "hold button for 5 seconds until light is blue", and someone will hold the button for 3 seconds until it turns white and ask why it's not working.

I'm color blind so don't blame me. If it turns white then blue I can probably see that, but if it turns white and there is no warning it goes through white before blue I'll assume you just got a different led on the line.

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

#125

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've only posted about 1/3 of the Stack Overflow questions I've written. Forcing myself to break the problem down into a clearly explained question often brings a solution to mind or at least gives me a few new paths to go down, which often leads to an answer.

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

#126
post #9

Earlier quoted context omitted.

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.

Legally they can as it is a violation. They probably never did just based on that, but it would be in the list of reasons.

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

#127
post #69
post #49

Earlier quoted context omitted.

First thing you do is email them a contract with a _reasonable_ consultant hourly rate. You literally handed them documentation in advance and they didn't bother to read or test it. Don't feel bad, don't get angry, get paid.

I agree with all of that, except for making it a reasonable rate. Go up to the edge of reasonable, then bump it up by $15/h.

Or just set a day rate, and limit scope to helping with the specific problem. "It's $1200/day, and scope is limited to helping you understand how to recover from the described problem. All of the work recovery work will be done by you, and my role will be limited to advising."

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

#128

Earlier quoted context omitted.

> So if someone from the backstage team messed up the M&Ms, it will bring absolutely no information about how the situation was handled by the guys in charge of the stage... Sounds like there was little to no organization then. I showed this to my co-worker who managed the technical aspects of a large college theater that also served the town. They hosted multiple large events including bands who had fleets of semi t…

This may be possible for a theater hosting a unique event, but never for a music festival, where you have like 30-50 different artists/bands on one night. There you have people responsible for each aspect. Of course you have a stage manager responsible for the overall operation of each stage, but there is no way that a guy can make sure that everything is ok in all details for all artists (the riders sheets can somet…

In my experience doing video work for some of these type events, its possible for a music festival to negotiate riders that work for the festival an implement them properly, it might take a few more people and decent planning ahead of time.

The problem is that it requires a fair bit of documentation, coordination and processes to make it work, which some festivals do fine and I guess some just don't.

The key is that your head QA person knows who is in charge of what and has a process for holding them accountable, one such way would be to create a checklist of all the items that need to be checked, based on the riders, production requirements, regulations, expected amenities, plussing, etc.

Its also needed for each stage of the process, planning with stuff like speaker modeling, truss engineering, power load calculations, network and communication requirements, etc... on to checking the event area after load in and setup is complete and continuous checks on key items for safety and a reliable performance.

So, its certainly possible to reach an optimized state where you have a negotiated list of requirements and implement them correctly.

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

#129

> Properly reading the docs can take hours, and most don't have that much time to spare. And, reading the docs looks to an external observer exactly like playing video games or browsing facebook all day. Modern "agile" organizations dedicate two or three watchers to each actually productive employee to "make sure" that the productive people are actually being productive. This means that the only time spent on tasks i…

I just faced this - I was trying to write a somewhat complex MongoDB query and I decided it was finally time to read a book rather than just cutting-and-pasting from stack overflow until I stumbled across something that seemed to work. So of course in our status meeting yesterday I had to say I hadn't accomplished anything. In the long-term it's good to have someone on the team who really understand MongoDB. In the s…

You read the book; you're now the expert.

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

#130

Earlier quoted context omitted.

> So if someone from the backstage team messed up the M&Ms, it will bring absolutely no information about how the situation was handled by the guys in charge of the stage... Sounds like there was little to no organization then. I showed this to my co-worker who managed the technical aspects of a large college theater that also served the town. They hosted multiple large events including bands who had fleets of semi t…

This may be possible for a theater hosting a unique event, but never for a music festival, where you have like 30-50 different artists/bands on one night. There you have people responsible for each aspect. Of course you have a stage manager responsible for the overall operation of each stage, but there is no way that a guy can make sure that everything is ok in all details for all artists (the riders sheets can somet…

[deleted]
Post reply on HN