[aequitas]

And that developer gets fatigued by constantly having to tell others to RTFM, because the documentation is up to date and comprehensive, he took his damn well time to make it so, if they just also took their time to read it, but instead they always ask him anyways or he has to point everything out and at a certain point they just don't care anymore.

[ryangittins]

It's very true. I think in reality it tends to be a mix—sometimes documentation goes stale, and sometimes people don't even bother reading it regardless of whether or not it's stale.

Another large problem is developers not knowing what they're looking for. Documentation tends to solve the "how I do use this" question and not the "do we already have a solution for this" question.

I'm still not sure how to solve the problem of discovery outside of telling people, "read the docs and hope that someday you'll remember the relevant bits when you need to."

[thu2111]

Poor reading speeds and skills are a huge problem. I've wirken with even supposedly senior developers who will not read the user guide for some complex piece of software before trying to use it or even worse, mouthing off about how it doesn't have feature X so task Y will be too difficult so we should switch to an alternative! The user guide in this case was comprehensive and fresh.

The reality is, this sort of behaviour isn't penalised or shamed. Said developer got called out in a meeting with many others present and didn't even appear to feel embarrassment or apologise. Makes it tough to get people to write and take pride in documentation when that sort of thing happens.

[ryangittins]

I don't disagree that someone not reading the user guide is annoying, but I vehemently disagree than penalizing or shaming is appropriate in any professional workplace.

I would not want to work with anyone who thinks public shaming is right or even effective. It kills morale, makes people fear asking questions, creates a low-trust environment, and frankly is just plain rude.

[giardini]

He said "Said developer got called out in a meeting with many others present and didn't even appear to feel embarrassment or apologise."

In the noted case there was no overt penalizing (at least that we heard about) nor was there shaming (the person was apparently "unshameable"). Therefore your post falls short of it's target.

That said, in general, I agree with every word you said. I especially like the "frankly [it] is just plain rude." - good manners (etiquette) can make a world of difference in a workplace but have largely fallen by the wayside in our culture.

[ryangittins]

The "got called out in a meeting with many others present" part is something which I don't think should have happened at all—regardless of whether or not the developer in question felt shame. No good can come from publicly calling someone out in a meeting like that. It's childish and unprofessional.

I feel the best courses of action are to remind the developer privately and/or to make a general "remember to read the docs" statement to the whole team in the meeting.

[giardini]

ryangittins says "The "got called out in a meeting with many others present" part is something which I don't think should have happened at all—regardless of whether or not the developer in question felt shame."

Yes, but we don't know what the OP meant by "called out": it could have been as simple as one person asking "Did you read the documentation?" and a long following uneasy silence, or it could have been quite vicious, e.g., the documentation's author ranting at the developer for not reading the docs, a manager dressing him down for his failure to do so, or even worse.

But we don't know, so while your point is well-made it is tangential to the discussion. Nonetheless you reveal a well-developed attitude about people and groups that would be very useful in management.

As an aside, the OP's description of the developer in question paints an individual who is most likely not as self-aware as you are: indeed he/she sounds like someone who is quite hardened and aggressive in his ways. Sometimes you must unfortunately pop such people on the nose to get their attention.

Compare yourself with the aforementioned developer - which of the two is more likely to be/become a manager? Such an opportunity is not likely for him but is something that probably lies in your future, waiting, if you haven't already gone there.

[ledauphin]

both of these things happen all the time at my job.

new folks will show up and start complaining that "stuff doesn't work", at which point I will ask them to read the many READMEs that been sitting right in front of them.

Later, they will say "this documentation is wrong", where inevitably someone else changed some code but didn't change the documentation that is colocated with it.

Because the docs were wrong, nobody will read them next time. And the cycle continues.