My experience too. I guess most people are just not wired to read documentation.
I love learning by reading, but most people just want to sit in a classroom and be spoonfed like you say.
I think it's also company culture, and most companies have a "let's meet and present slides" mentality. So as long as there is no meeting, there probably is no need for you to know.
> I love learning by reading, but most people just want to sit in a classroom and be spoonfed like you say.
To build on this, it's more than just being spoon-fed, it's being told exactly what to do, step by step.
I think this may have several causes, but one I can see is being afraid to take responsibility. "I've just followed the procedure! It's not my fault if it didn't work / brought the site down!". And this comes down to the local company culture.
Presenting a nice documentation, which is more general, although more complete, means that the reader must actually understand what the doc says. Now, of course, they may have been trained by shoddy docs that it's oftentimes an arduous, uphill battle, so they have a knee-jerk reaction to it.
But they also have to take responsibility for their actions, which, in a culture of cover-your-ass above all else, is a tough sell.
Lots of documentation is written by and for people writing it and not for someone who just arrived at the company.
And then you expect some junior dev to just understand everything without asking.
A culture where people are afraid of asking questions is worse than having the best possible documentation on everything
> A culture where people are afraid of asking questions is worse than having the best possible documentation on everything.
No doubt.
However, my answer was to someone talking about people expecting to be spoon-fed in meetings, not just asking questions about some points they don't understand / can't find specifics for / etc.
The dynamic is very different. Asking questions is active. You read, try to understand, realize you don't. You then form a question and ask it. Contrast this with someone who just expects a laundry list of actions. "Just tell me what to do [step by step]".
My answer was also from experience in companies where even people with seniority and who had been there for quite a while will expect a checklist-like procedure to do things, and hardly attempt to actually understand their tools.
I get that the mental model of some tooling is not always self-evident, to say the least. But it's clear to me when someone tries to understand it and fails, and when someone doesn't even try. And I'm talking about tools they use day in, day out. They just learn to click that button and to expect that result. When something goes wrong, they have no idea what may have happened. I suspect this may also be somewhat related with the discussion on HN the other day about error codes [0], as in they get so used to cryptic, vague or downright wrong error messages that they just don't pay attention to them anymore – because 9 times out of 10 it's a waste of time.
> A culture where people are afraid of asking questions is worse than having the best possible documentation on everything
Yes, true, but a culture of asking too easy or even dumb questions that the docs clearly cover is also worse than having the best possible documentation on everything.
One company I worked for got it right, IMO, and it stuck with me. My mentor told me the first day: “You must spend at least five minutes trying to answer your own question by reading the docs before you ask someone else. And you must go ask someone if it takes you more than ten minutes to find the answer. Do not ask someone without having tried to find the answer yourself, and do not get stuck on something alone.”
Well there are lots of cases where I would be wasting 2 hours searching through docs to maybe find something meaningful while my coworker has all the required knowledge.
I always ask. Isn't it stupid to waste time reading unnecessary info. (finding needle in a haystack)
I definitely understand this, but there are limits. A guy I worked with (super nice, hard working and a great engineer) would always slack me with questions that he had previously slacked me. In his defence, these questions were in my wheel house and were tricky things that he only have to do maybe once every couple of months. But when he was slacking me he'd literally say "hey man, I know I keep having to ask this but..." I eventually started responding: "Scroll. The. Fuck. Up.". The answer would typically be a few pages up. I even tried using the slack search for his question, and would find the previous time he asked. And yes, this shit was also documented in the git repo in a README.md that was alongside the code (so there was no "searching for the docs")
I spend lots of time reading and reviewing docs and I must say it's a daily reminder on how much empathy is missing in this world. Not a lot of people try to make the thing readable in any other sense than just spouting things on paper.
I often draw a parrallel with code, where once the unit tests pass, let's ship. Dear colleague, would you mind just editing yourself for your future reader or maintainer or future self. You're not that good that your first draft is enough. Edit until it's fairly understandable. Remove the hacks, reorder the text, remove all the TBD/TBC/TODO...
I love learning by reading, but most people just want to sit in a classroom and be spoonfed like you say.
I think it's also company culture, and most companies have a "let's meet and present slides" mentality. So as long as there is no meeting, there probably is no need for you to know.