Here's what I'll say, management taught a generation of devs to ask instead of researching, aka rtfm. If I had a quarter for the number of times I was told to ask for help sooner by a non tech manager I could have retired by now and had a farm.

[–] boonhet@sopuli.xyz 33 points 17 hours ago

It's because for every dev who asks too soon there's another dev somewhere that doesn't ask at all, bills 300 hours their first month without being asked to, delivers nothing because they refused to ask for help and couldn't figure it out either. That dev is why people hate off-shoring to India. They did not work a second month.

[–] firelizzard@programming.dev 11 points 11 hours ago (1 children)

That’s preferable to people who don’t ask for help until everything is hopelessly fucked because they kept trying to solve their problem different git commands, none of which they understood.

[–] expr@programming.dev 2 points 7 hours ago (1 children)

Eh, git is never really that fucked. If you understand how it works, it's generally not hard to get back to a state you want (assuming everything has been committed at some point, ofc).

I would much rather people try to spend some time trying to understand and solve a problem first. I had a "senior" engineer who would message me literally every morning about whatever issue he was facing and it drove me absolutely nuts. Couldn't do anything for himself. Unsurprisingly, he was recently laid off.

My time should be respected.

[–] firelizzard@programming.dev 1 points 1 hour ago

Seniors should know their shit. If a junior doesn’t need help they’re either not doing their job or not a junior.

I think you haven’t met “problem solvers” as creative as the ones I’ve met. My first job out of college I built an inventory system for a small engineering firm. One of the engineers tried to solve his problem instead of asking for help. Once he gave up and called us, it took us an entire day just to figure out how he had managed to screw things up as badly as he did.

[–] luciferofastora@feddit.org 7 points 7 hours ago (1 children)

From personal experience:

One part is manuals / docs being hard to use. Some seem to assume a measure familiarity with the subject, creating a certain entry barrier. They're perfectly usable as reference for people who know the gist but look up details, but for younger devs, it's disheartening to get the sense that you don't understand anything. That's a common issue with FOSS tools, in my experience, where the devs naturally prioritise developing the actual tool. Asking and getting an answer for a specific example can help get a foothold and start climbing that, but it's no guarantee.

A second part is that manuals don't always cover things you can't do (because obviously it's hard to predict what people would come up with wanting to do), but it's hard to tell whether that's just incomplete unless you ask and get an explicit, hard "nope". Bonus points for commercial products documenting what you can do, but not with your current license: You'll diligently read the page for what you want to do, attempt to implement it, then be hit with "please upgrade to Premium for this feature".

A third part is terminology. Just like the non-features, it's impossible to predict all the ways someone might describe what they want to do if they don't know any better way to phrase it. I'd count language barriers into this as well, which is an issue that a smaller, US-heavy software development world wouldn't have had to the same degree as we do today.

And finally, of course, there's convenience, which is where I think the managers have the greatest impact: The less time you have to spend learning how to RTFM or digging through the docs, the less time is "wasted" on things that aren't immediately productive. Particular non-IT-background managers may not appreciate the value of such skills, so they'd rather have you spend someone else's time taking a shortcut than invest your own.

So I think this is an issue arising naturally from several independent factors, which makes it hard to tackle effectively. Managers should plan for and encourage taking time to understand the manual, but I don't see a universal solution to the documentation quality and language barriers.

Also, retiring to have a farm is a mood.

[–] Appoxo@lemmy.dbzer0.com 5 points 7 hours ago* (last edited 4 hours ago) (1 children)

For the first part:
That's why you need and have to be aware of a target group.

[–] luciferofastora@feddit.org 3 points 6 hours ago (1 children)

Your target group and the effective user base might not strictly overlap. You can't always anticipate that. Even if your target group is junior devs, it may be hard to accurately imagine their perspective on something you're necessarily more familiar with. And even if you do, investing the time to explain and document may detract from the fun you have actually achieving "milestones" in terms of features. Particularly for many open source projects, the devs' fun is ultimately the driving factor.

It's a start, but not a full solution.

[–] Appoxo@lemmy.dbzer0.com 2 points 4 hours ago

To the last sentence: Never said so. But yes, it's a start.