Live data from Hacker News

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

blog.nuclino.com

91–100 of 153 posts

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

#91

This is quite strange, having organized a large music festival this kind of document were split among different teams. Meaning that people in charge of the backstage are managing their part (getting food, M&Ms, specific brand of beer, and other non nonsensical request, etc) and the people in charge of the stage and technical stuff are taking care of technical requirements (and aligning them between different bands sh…

> 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 sometime several pages of different requests, like that hotel room must contains this kind of pillow etc.). As you say you have to delegate, and if one of the guys of the backstage team forget to sort the M&Ms, it will be a problem for the guy in charge of the backstage, but that's it. Like in any large organization, you cannot imply that because the customer support guy messed up that all the engineering team is bad. So here, if they wanted to make sure that technical guideline where followed it would be better to put something like: please mark all this kind of cable with pink and yellow tape.

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

#92
post #64
post #35

Earlier quoted context omitted.

I would help. The people who are suffering the most are your former coworkers. Presumably friends. Definitely people you may work with in the future. I'd rather be known as the guy who helps than the guy who is rude about consulting rates.

You missed this bit: > after a bit of an ear bashing If someone from my old employer calls and asks me politely for a bit of help with something I know well, I'd help. If they call to yell at me about how I left behind a fragile system or how I left them in the lurch by quitting, the correct response is to tell them to get fucked, if they then ask for help after that, the correct response is to tell them to go fuck t…

Better compromise:

“This is exactly the sort of behavior that made me leave. Do not contact me again. If you need something from me, have Steve call me instead.”

Let the people who actually gave a shit about you be your point of contact, not baby Napoleon.

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

#93
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…

And don’t forget, streaming service Quibi, with its focus on ten minute shows, failed to pull viewers away from the series and movies on HBO and Netflix that require much bigger time and attention investments.

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

#94

> 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 short-term it looks like slacking off.

- Of course my conclusion after reading about MongoDB queries was to decide that I wanted as little as possible to do with MongoDB queries and am going to avoid them at all costs.

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

#95

A few years ago I left the company I was was working for. We had an internal doc wiki that hardly anyone used. I was one of the ones who did and I would document code changes and things like how to setup a dev environment and to list known gotchas. During my final week when I was doing code handover I sent an email around the company pointing out that the wiki would answer most of the questions they might have about…

> Then they started calling my wife as she was listed as my next of kin.

Minor tangent, but that got me to wonder: would that be legal under the GDPR, which only allows you to use data for the (legitimate) purpose it was collected for?

In this case, they gathered next-of-kin info for (I assume) disbursal of benefits when the employee is dead or incapacitated. “To find the employee after he quits” would be out of that scope, then, right?

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

#96

A few years ago I left the company I was was working for. We had an internal doc wiki that hardly anyone used. I was one of the ones who did and I would document code changes and things like how to setup a dev environment and to list known gotchas. During my final week when I was doing code handover I sent an email around the company pointing out that the wiki would answer most of the questions they might have about…

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 clear understanding of how all the garments are stitched together.

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

#97

A few years ago I left the company I was was working for. We had an internal doc wiki that hardly anyone used. I was one of the ones who did and I would document code changes and things like how to setup a dev environment and to list known gotchas. During my final week when I was doing code handover I sent an email around the company pointing out that the wiki would answer most of the questions they might have about…

> after a bit of an ear bashing you actually helped them? Hang up, charge your emergency hour consultant rates, and tell them you're available once they sign the agreement.

Exactly.

When people treat you that way, you politely say "If you want my help, change your tone."

If they don't, hang up.

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

#98
post #64
post #35

Earlier quoted context omitted.

I would help. The people who are suffering the most are your former coworkers. Presumably friends. Definitely people you may work with in the future. I'd rather be known as the guy who helps than the guy who is rude about consulting rates.

You missed this bit: > after a bit of an ear bashing If someone from my old employer calls and asks me politely for a bit of help with something I know well, I'd help. If they call to yell at me about how I left behind a fragile system or how I left them in the lurch by quitting, the correct response is to tell them to get fucked, if they then ask for help after that, the correct response is to tell them to go fuck t…

My ex-manager was the reason I left. He was.... odd.

You could warn him in advance about an impending negative issue. You could use lights, fireworks and even shout in his ears, but he would ignore you.

The the issue would occur and cause problems, big problems.

He would then ask "Why didn't you warn me?"

I would pull out my paper trail of emails, meeting notes etc.

To which he would reply "You didn't try hard enough to get my attention."

And that is why you don't put a career salesman in charge of your IT department.

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

#99
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?

I don't know how the contracts were actually written, but I suspect it would legally classify as a "breach of condition." This kind of breach entitles the innocent party (i.e., Van Halen) to terminate the contract. Of course, the contract itself can override this interpretation as it sees fit.

However, as noted by others, this is rather moot: someone who didn't notice this line in the contract probably didn't notice all the other (more serious!) issues.

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

#100
post #35

Earlier quoted context omitted.

I would help. The people who are suffering the most are your former coworkers. Presumably friends. Definitely people you may work with in the future. I'd rather be known as the guy who helps than the guy who is rude about consulting rates.

That would cross my mind. Most potential employers I've encountered have usually asked for references from my last two jobs. On another occasion I had to undergo a background check which involved contacting my last 15 years worth of employers. So no matter how much I may have disliked an employer I would be unwilling to burn bridges until I knew I would never need to rely on them again.

If you run into one of those where you don't have a choice, the best phrasing I've found to explain why I left was "hostile work environment."

I had one of those for about a year and leaving after just over a year was a question I got used to answering.

Post reply on HN