I'm forever telling junior devs to read the docs. All they seem to want to do is take other code and modify it slightly. I don't understand why reading is so difficult. Especially when the docs are great like Click and the others listed here.
I had sort of a horrifying revelatory experience at a Java User's Group a few years ago (back when I erroneously thought that attending Java User's Groups was worthwhile). This was when Hadoop was fairly new, and the speaker was talking about some of the challenges that his group ran into getting it up and running. At some point, a woman interrupted him and said "but when you had an error, why didn't you just google the error message and find the solution?" He was admirably patient with her when he explained that in most cases, there was no error _message_, but actual incorrect behavior (or just nothing at all), but she kept arguing with him as though he was missing something obvious and important. Here was somebody with enough software experience to be attending a Java User's Group who had never encountered (or more likely had just ignored) a problem that a google message search couldn't fix.
Because they're in the mode of getting things done. They're out to prove themselves, they don't want to report to their manager that they haven't finished that feature because they're reading the docs.
Counter-argument: an hypothetical manager simply won't (and very often can't) get involved to a point where they can fix this situation.
Worker A: Pushed the feature in 2 hours.
Worker B: Pushed the feature in 4 hours says he read the documentation.
This can be be a signal that Worker B is more mature/senior and takes the time to do it well, but it can also just be that Worker A is better (and also read the documentation), was familiar with framework X already or another reason that has nothing to do with "not reading documentation".
In that context the optimal manager behaviour is to do nothing, if Worker A was doing lower quality work it might show up at some point or Worker B might get more accustomed to framework X and do the tasks in 2 hours too.
Which is all to say, you can't as a manager have that level of insight without personally looking at the work output and being familiar with framework X, which I'd argue might be within reach of a team lead for a somewhat reasonably scoped product, but will rarely be the case in practice.
Plus, reading manuals is a skillset all of its own. It might seem easy to you, but so is reading novels - but you couldn't do that right at birth. Some junior devs just haven't developed that skillset.
Reading, however, is a skill taught to all schoolchildren, and taken further in college.
The idea that someone is able to read yet can not read technical manuals while being in the CS space is just shy of unthinkable to me. Reading them slowly, I completely understand. Everyone reads technical writing slowly, since it requires a lot of thinking.
But that thinking is related directly to our day jobs. That thinking shouldn't be so foreign that it prevents people from reading technical docs, well written or poorly written.
Personal bias, perhaps, but still a very foreign concept.
Within our profession, which is almost entirely text based, yes. Outside of our profession, I'm happy to concede that literacy levels are demonstrably lower.
Junior developers are junior. There are many skills they don't have. Being able to parse writing in a certain style is one of those skills. Should they find another profession if they don't instantly know how to rebase things in git, or how to track down a bug?
It is not actually normal to use SO several times every single day to find code you can use, and it is not actually faster than knowing what you are doing.
