I once read the first 3 chapters of the Git book and my coworkers think I’m some kind of Git wizard
Literally same 💀
One of the first things I did at my first full time job (while my very under prepared boss was looking for “junior-dev-friendly” tasks for me to work) was go to git-scm.com and just read through all the man pages I could. I spent a few days doing that, then my boss asked me to create a PowerPoint and present what I learned to the team. It was instantly apparent that I was the only one who knew anything beyond
git commit -aon the team at that point, and I was promptly appointed the “title” of “source control SME”. I’ve been heading up version control best practices for every team I’ve been on since (which is scary because the git cli has changed quite a bit since I read all those man pages but I haven’t had a chance to go back and refresh my knowledge).These days I just ask llm to fork me a branch and whatever else I need :p
Do you have a blog or something? Do you write about your experiences regarding this?
Lol no, the most writing I do is comments on Lemmy
I work in IT. I’ve read so many manuals that I don’t need to read manuals almost ever.
As soon as you learn the design language for stuff, it usually just makes sense where to find stuff and how to fix it. It’s rare that I have a problem that I can’t solve just by looking at it.
If I ever get stuck, guess what? I RTFM. That’s basically my job. I RTFM because end users can’t be arsed to do it themselves. If everyone read the manual, I’d be out of a job.
Many linux CLI tools also tend to have similar names for arguments with similar effects.
That also reduces the re-reading.quick everyone, stop RTFM ! save this man’s job !
Lol. I think it’s more likely that I’ll win the lottery than users RTFM enough for me to worry about my job.
It’s just a funny thought that any of them would try.
In many cases you get hired for having the knowledge and experience instead of just having skills.
I dread the day the users read the manual
I doubt that day will ever come
Sorry, I have a chronic medical condition that prevents me from reading the manual until I encounter a problem that requires me to read it, at which point I will have likely discarded it. And if I haven’t, I will only read through the part that contains the information I need to know to solve the problem and then immediately forget it after.
I did not expect genuinely invaluable advice – not just for Linux – but for life in general on here LOL
My entire job is basically reading manuals 🙃
I read the manual for every appliance I have. I do man and help even before using the command. I look for multiple articlse explaining the how and why before doing something new with my computer and yet when I look for help many tech people are condescendingly telling me to read the doc. Well, I did. But I don’t understand, because I coudn’t grasp the concept, because english isn’t my mother tongue, because many doc are written by great technician with poor writing skills that are bad pedagogues, and I would like someone to answer my question.
English is my mother tongue and I still have issues with reading some manuals because they’re written by bad pedagogues using jargon phrases that mean nothing, or worse, mean something completely different from a basic English reading of those words in that order.
Let’s not forget there is a lot of documentation written english by people who are not as fluent as they wish they be.
Not everyone learns the same way. I’ve mostly found man pages to be pretty opaque. Finding examples online that are relevant to my specific use case have been much more useful to me.
Can’t find the manual for my girlfriend or her kids.
RTFM is an obnoxious retort for people, arguably in community, not to engage with a member of the community. I don’t mind reading the manual, but perhaps you can point me to where in the manual I could get further insight.
Reading a manual is also a skill. Being able to compartmentalize manual info into buckets of “obvious and I don’t need to read on”, “could be helpful”, “interesting, but it gets there I ain’t touching it” takes either training or just getting lucky after a certain number of reps.
RTFM is an obnoxious retort for people, arguably in community, not to engage with a member of the community.
I think there’s a low level of “How do I figure this out?” [generic] in which its good advice to ask “Does it say anything about this in the manual?” before you try and tear into a system as a third party giving advice.
I also think “I read the manual on my refrigerator” is some “I dare you to prove me wrong” horseshit. On the one hand, people don’t do this for a reason. Refrigerators simply aren’t that complicated to use. And the manual is rarely a smooth read, even for professionals. So its good advice, but not practical advice, better than half the time.
Reading a manual is also a skill. Being able to compartmentalize manual info into buckets of “obvious and I don’t need to read on”, “could be helpful”, “interesting, but it gets there I ain’t touching it” takes either training or just getting lucky after a certain number of reps.
Also, just a matter of free time and mental calories to burn. And hey, maybe if you’re a hobbyist who is hip deep in your Linux kernel because you eat this shit up, its the place you should have started. But also, Jesus Christ, maybe I just want a Mint instance to run a Jellyfin server. I’m not trying to get my master’s degree in this shit.
- It’s not impossible to learn if you read the manual. That’s how I learned.
- If you need my help cos you can’t figure it out, pay me. I don’t work for free.
- If you’re not paying me, I don’t owe you anything.
If you need my help cos you can’t figure it out, pay me
It’s so funny to see this on a sub dedicated to FOSS. Trying to imagine how many Pull Requests come with a bill attached.
There’s a difference between helping out people who are interested in, and capable of learning, improving, contributing to something…
… and people who just want thing work, and are also almost always unwilling to put literally any thought into this process.
‘User Support’ and ‘Collaborative Development’ are not the same thing.
There’s also ‘the computer guy’ syndrome, where a group of people just expect a seemingly infinite amount of uncomoensated time and mental effort from ‘the computer guy’ to solve all their problems, who then take this for granted, and become hostile and offended when you tell them ‘sorry, don’t have the time’, when ‘the computer guy’ has the audacity to… want to do something else at that moment.
So much this
FOSS doesn’t mean “we think people that make software should work for free because we like free shit”. It means:
-
When you want to modify something someone else made to your benefit you should recognize the work they did for you and pay it back in the form of contributing those changes back to the project. Beyond that, it also benefits you directly because someone else might build on your improvements (well, that, but also its easier to stop your changes from breaking in new versions of the software if other people are aware of them). Like the other commenter said, its communal development, sure lots of people do it at least partly because they want to make the world a better place, but the primary reason it works is because the various parties mutually benefit from mutual cooperation.
-
The belief that you should have complete control over your own computer, which you can’t do in practice without being able to view the source code of the software you run.
FOSS doesn’t mean “we think people that make software should work for free because we like free shit”.
What ingrained, unexamined immersion in capitalism does to a mofo.
-
This is the only comment I’ve seen in here that I’ve seen address this. The whole concept of RTFM is reactionary and ridiculous. That kind of thinking and behavior kept me at arm’s length from the Linux/tech community for many years. Still kinda does.
Fortunately this kind of thinking slowly but surely gets defeated, although we still have to fight for every inch of user-friendliness (and even modern security concepts) against elitists.
Unfortunately right now most documentation is still crap for average users, and people who keep repeating bullshit like “it’s better to provide CLI commands because they’re universal” (actual nonsense people keep saying) don’t make it better. The situation is so phenomenally bad that I’d outright assume Mistral AI with “Reflection” on to be more useful to newcomers when looking for solutions (on case a friendly professional or enthusiast isn’t available), because that thing is less likely to provide an outdated command for the wrong distro than a google search. Which is an absolutely abysmal place to be in for Linux as a whole if we want to keep the rising adoption train going.
I’m glad to hear it’s changing for the better but I lost my patience with these techie dumbfucks a long time ago. If people respond with anger or impatience at technical questions, I tell them they deserve to be publicly executed.
Writing a manual is also a skill so starting with good ones help a lot.
Your second point is pretty much the most important skill learned in a humanities PhD, how to make your own learning path and learn what you need to know and what you should avoid.
I once wrote documentation for a fairly complicated bit of control and analysis software for use with test equipment I built for PhD students to use in my department. Towards the end of the docs I added a message that basically said “if you read this, come and see me and I’ll buy you some nice food”. Needless to say I never had to buy anyone anything.
You drive a vehicle with a manual transmission.
You steer a vehicle with an automatic.
WTFM is job one. Honestly WTFMs and RTFMs should just be a requirement to any computer science degree.
CS101: RTFM - Someone has already helped you.
CS102: WTFM - You also need to help others.
CS103: FTFM - What to do when help isn’t provided.
CS104: GDFL - What to do when there is no more help.
Edit: Other courses I teach include
CS201: WTFPM - Code Quality
CS202: UTC - The only time that makes sense
CS203: 1 - Counting for machines
Technical writing was a required class in my CS program. Is that not the norm?
I’ve acquired a reputation as the go-to frontend wizard by reading the MaterialUI documentation. Now half my job is randomly getting called on Teams, listening to someone ramble about what crazy ideas they have for their frontend, and pointing them to the MUI implementation that already exists (because there are no new ideas). It’s stupid, those docs are modern and well-structured, people just refuse to read them.
I mean in general, “read things -> learn” is a good approach to life imo.
Too long and difficult. I’ll let chat gpt tell me instead and read that between adverts on Love Island
Grok, is this true?
I’ll be honest, I’m guilty of using Chat GPT at times for stuff I know barely anything about and know I probably won’t be able to find through research as quickly as I’d like to. I always try the old-fashioned way of using a search engine first, go through reddit and forums and stuff, but sometimes I just need to use AI for a good first pointer
It’s not a terrible idea. ChatGPT is great at summarizing info, especially stuff you’d use manuals for. I make sure to ask it where certain info came from (so I can try to verify) OR having it explain its approach so I get it in the future.
we’re cooked
Meanwhile I’m sitting here with my ADHD brain that is unable to read the first two sentences of a manual without losing focus and thinking about 15 other things and marveling at those can actually get through something like that and have it stick in their brain longer than 5 minutes.
The trick with my ADHD brain is to refer to documentation when I’m hyperfocused on how the thing works for some reason. It doesn’t have to be because it’s broken, but it could be, lol.
For me, it’s only when it’s broken.
To be fair, that is a great point in time to be RTFM.
Oh, reading a manual is a very involved process for me. First, I’ll put the task in my bullet journal, then I’ll postpone it to the next week, then to the month, then to the next month. And then, if I feel lucky, I’ll bring it back into my daily log, and postpone it a few more days before getting annoyed with writing it down so many times that it could fill a full page, and finally reading it.











