Live data from Hacker News

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

blog.nuclino.com

101–110 of 153 posts

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

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

Joe Rogan is very light listening though. I doubt people actually sit in their armchair listening intently for 3 hours without doing anything else. People also love to binge watch TV - does that mean there’s no attention span issues?

I am watching and listening intently the ones that I am interested in. Episodes with Guy Ritchie, Robert Downey jr. or Russel Brand, I watched in full in one sitting. I can also watch bunch of episodes cooking, checking other stuff.

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

#102
The article confirms a couple of principles that survived largely intact from my youth.

I'm most efficient when I'm 1) in service to someone and 2) prioritizing their needs.

This applies to pretty much any interaction with people - but especially to personal relationships like family and parenting.

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

#104

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.

I remember well one time long ago when I did that.

I had done the firmware for a piece of hardware that had some DIP switches to configure. I was having trouble doing the documentation for what each switch did and when you would want to configure it a particular way. Finally I realized it was because the switches weren't laid out logically, so I wrote the documentation the way I thought it should work then changed the code to match the documentation. Win-win, easier documentation and easier to use hardware.

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

#105

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…

I manage the "support" (mostly DMCA) tickets for some small website we run as a hobby project without monetization whatsoever (aka "for fun"). People are free to use it, e.g for chat and to share content (i.e. DMCA magnet). It's maybe like 5-20 such tickets per day, most of which are DMCA and can be handled really quick, so it isn't that much of a time drag.

Not actually getting paid/having an employer there can be quite liberating...

Since nobody who ever writes me is a customer, and I am not getting paid anyway, I am more or less free in what level of politeness I apply. I usually try to model my response after the initial requests I receive - taking into account other factors like people who might be genuinely upset; or confuse me with the person who actually uploaded a piece of content.

We have users from all over the world, and it's rather interesting to see particular patterns/attitudes with certain types of locales.

For example, Americans - by and large - are too lazy to read the few lines of text on our contact page detailing what information we need to address what kind of problem, and often are rather rude from the get-go, and really like to threaten with their lawyers (plural!) in the initial email when it comes to copyright or related issues. This then leads to me asking for the missing details, followed by a lot of them demanding to talk to my supervisor, to which I then point out that they are not our customers and that being rude or even outright insulting the only person who could potentially help them (for free) isn't maybe the best idea they ever had... And if the supervisor demand came up, I point out that I do not have a supervisor, I demand to talk to their supervisor instead.

It would be unfair to only unload on Americans, tho. We got a lot of Portuguese users, and tickets from the Portuguese are even more rude on average and of course nobody bothers to read the instructions, tho nobody ever demands to talk to my supervisor. The French are polite but like to make outrageous demands, but seem to read the instructions. Germans are "professional"-polite but tend to write LOOONG emails, and when it comes to copyrights usually cite a lot of completely unrelated laws, but again read the instructions. Middle/South Americans are usually polite but constantly think the Subject line is where all their text is supposed to go, and do not read the instructions. I'd say the most pleasant people are the East European (mostly Polish and Russian) people who write me... I don't remember anybody outright rude from East Europe ever, tho the language barrier - our website is English only incl the instructions - is often rather obvious (but I will not fault anybody for that, of course).

Point being: the level of RTFM in my limited experience differs quite a bit depending on locale.

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

#106
post #53

Earlier quoted context omitted.

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.

Even if they're being a bit unreasonable, the momentary satisfaction of telling them to F Off is probably not worth the risk of it coming back to bite you some day.

If you don't want to tell them to F Off for this reason, you can contact their line manager, HR or customer service department and ask them to do it for you.

The kind of person to lay into you like this is not going to give you a glowing reference whatever you do.

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

#107

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…

Very much this. New hires must always be tasked to improve onboarding documentation. At a previous place I worked, I went from expecting it to take a new hire several months to be productive to less than a couple weeks and a big reason was continuing to have newbies tweak docs and fill in details that might be easy to gloss over by soneone who already knows the tech.

As for containers, I’m not sure I follow. We ended up using vagrant and then test kitchen for our VMs, which really helped with on boarding. The team had too many people who couldn’t be expected to troubleshoot much of the backend anyways. We had stayed away from containerization because it added complexity without any clear benefits for our use cases. But test kitchen definitely papered over the need to get a local environment running with all the dependencies, which might change with different services, and that seemed like a good thing.

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

#108

Earlier quoted context omitted.

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.

Most people won't give a bad personal reference anymore because they are too afraid of being sued. We just say yes, the person worked here from this time to that time.

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

#110
post #78

Earlier quoted context omitted.

What would I bingle for if I was looking for a template for such an agreement/contract? It seems like the kind of thing you would want to have prepared in advance (in case of emergency, break glass).

I use a statement of work template.

Yes! In my experience a well-crafted SOW is key to the practical understanding between client and contractor. Good SOW language is clearer and, IMO, psychologically less daunting to negotiate than contract language. The SOW provides a roadmap not just for the project but for the writing of the actual contract.
Post reply on HN