Unironically my advice to people asking how to get started programming (at a c++ shop) included going through everything on cppreference.com and using every function in a playground at least once.
If it wasn’t clear, I meant to do something with each function in some test code and understand it… Not just type it in…
bestboyfriendintheworld@sh.itjust.works
on 20 Aug 05:52
nextcollapse
When learning a new human language, it’s good practice to also learn sentences and practice speaking and writing, not just rote vocabulary memorization.
bestboyfriendintheworld@sh.itjust.works
on 20 Aug 05:52
collapse
When learning a new human language, it’s good practice to also learn sentences and practice speaking and writing, not just rote vocabulary memorization.
Melvin_Ferd@lemmy.world
on 19 Aug 22:43
nextcollapse
Not to take away how important reading these things are but I hate how people with a functional memory have no idea what life is like for people with poor memory. I would forget everything I read the minute button mashed the keyboard to quit the manual. It’s like when trying to imagine what is like living as one of those people without an inner voice. It’s such a foreign idea that its a shock when you realize some people don’t have one
No memory is me being hyperbolic but it’s severely limited. So I feel like reading a manual line by line means I get much less out of it but it’s a large amount of time invested. So I have to factor in that my retention vs time on task is pretty skewed. It’s frustrating. I need to do something a few times to learn. Learning by reading is not great for me. But tech is a very document heavy industry
Most people don't memorize things just by reading them. If you chose to construct some simple exercises/examples for yourself to learn by doing, this is very normal and in fact a good idea!
dylanmorgan@slrpnk.net
on 20 Aug 00:24
nextcollapse
So: read the man page, find the switches and options you need and hand write that bitch on a notepad, close the man page and execute the command. It’s tedious but it will help your not-great memory work a lot better.
GreenMartian@lemmy.dbzer0.com
on 20 Aug 03:10
nextcollapse
Or easier, just fire up multiple tty’s. The poor person’s tabs.
IncogCyberspaceUser@lemmy.world
on 20 Aug 12:31
collapse
I don’t know if you mean you don’t remember the gist even, but it’s more about learning about what’s possible with what so you can look up specifics when you need them than remembering the contents wholesale
GreenMartian@lemmy.dbzer0.com
on 20 Aug 03:15
nextcollapse
This is exactly it. Do I have to read a reference for regex every damn time? Yes. But I also have an idea of what it can do; and knowing that, I have a vague idea when a problem presents itself that I could use regex to solve it.
This is great perspective and advice. It’s how I learn too. I always felt like a poor performer because in my life I haven’t been able to recall specifics after learning something when I compared to others. I’ve got a complex. But general what you describe is how I recall. Almost in chunks but not specifics.
Reading the manual of a refrigerator? To know how to open the door or what? Sorry but that is laughable and in no way helps anyone understand anything, manuals are utter trash today. You do need to be curious etc. but advocating reading manuals of such appliances makes me question the whole story, that is how absurd that is.
i_stole_ur_taco@lemmy.ca
on 19 Aug 23:00
nextcollapse
Does the refrigerator have air or water filters that need to be replaced? How do you do that and how often?
Is there a maintenance schedule for pulling it out and cleaning dust from any heat dissipating elements?
How often should the water hose for the ice maker be checked and replaced?
Is there a trick to removing shelves for cleaning?
How would you even know when to take it in for an oil change??
dylanmorgan@slrpnk.net
on 20 Aug 00:25
nextcollapse
And set the temperature. And learn how often to clean what parts. And how to take out the shelves and drawers without breaking them. And. And. And.
Does the freezer need to be defrosted at a regular interval? Does it have filters? Does placing items in certain places which block the vent affect performance?
Why is my warranty void?
dylanmorgan@slrpnk.net
on 20 Aug 00:22
nextcollapse
I got started programming by reading the manual of my TI calculator during a boring history class. It really does work.
Zachariah@lemmy.world
on 20 Aug 01:21
nextcollapse
RTFM FTW
dis_honestfamiliar@lemmy.sdf.org
on 20 Aug 01:36
nextcollapse
I mean sure. This usually works okay. But some manuals are terrible. Specially those written by Google and Microsoft. Well mostly Microsoft. Google was probably good, I was just major verions behind.
baltakatei@sopuli.xyz
on 20 Aug 03:55
nextcollapse
Because their programmers are too busy to RTFM themselves to properly write a decent FM.
Lemminary@lemmy.world
on 20 Aug 05:16
nextcollapse
Google docs are written like they assume you already know the docs. 🙃
The only google docs I’ve used are for Google Analytics and they are TERRIBLE
syklemil@discuss.tchncs.de
on 20 Aug 09:10
nextcollapse
IME I’ll rather find some openapi docs for Google than their actual product docs. As in, I’ll start out trying to read their kubernetes docs, then shortly after it’s “fuck it, I’m going to docs.rs/k8s-openapi”.
My actual worst case are Elastic’s docs, though. Somehow they have plenty of stuff in there, just never the stuff I’m trying to figure out.
LeFantome@programming.dev
on 20 Aug 20:43
collapse
Cool. I used to but mostly Chimera Linux these days.
That said, I probably have more instances of Debian running than anything else if you count VMs and containers.
The distro matters less than it used to now that we have Flatpak and Distrobox.
Lemminary@lemmy.world
on 20 Aug 05:14
nextcollapse
Yes, I of course read the docs. Yes, I didn’t fuck it up first and then went back to do double work because I was being lazy and wanted the quick dopamine hit of seeing something on the screen. That wouldn’t be me!
Lemminary@lemmy.world
on 20 Aug 05:20
nextcollapse
The latest manuals I’ve read were from shitty Chinese manufacturers who didn’t even proofread what they wrote. They were asked to put foreign letters on a page and that’s what they did.
This is the next level of learning. Not only do you read how it is, you have to deduct, to assess and explore. Writing your own documentation is the best way to learn after all.
Unfortunately, the manual on goods these days is roughly the size of a post-it note. And even if they have proper ones, none of them have the full technical readouts, blueprints and repair guides that they used to back in the day.
ExLisper@lemmy.curiana.net
on 20 Aug 06:45
nextcollapse
Man pages in Linux are commonly meant for people already familiar with command structures, specific terms etc.
They are often borderline useless for an inexperienced user.
Buckshot@programming.dev
on 20 Aug 07:16
nextcollapse
At work people think I’m some kind of wizard with git.
I tell them I’ve been using it every day for 15 years and I read the freely available book on the website, link them to it, and mention the first 3 chapters probably covers 90% of their normal usage so they should just read that.
They won’t do it. I don’t get it. Something about written words is scary to them.
iglou@programming.dev
on 20 Aug 08:57
nextcollapse
Same here. I obviously don’t remember everything because I rarely if ever have to use them, but at least when the time finally comes that I need “git bisect”, I’ll know that “git bisect” exists and I’ll be able to go straight to the manual page that documents it.
No one expects anyone to read the manual and remember it all… But you will naturally remember the big lines and be able to refer to the right place when you need something.
This is my exact experience with a lot of things. I just skimmed through the first party documentation for $thing and it pays huge dividends over time when compared to trying to learn from the relatively context-sparse stack overflow or chatbot
FizzyOrange@programming.dev
on 20 Aug 07:41
nextcollapse
This goes against what we know about good design. Where possible you shouldn’t need to use a manual. Telling people to always read the manual is a cop out.
Also he apparently read his furnace’s manual and months/years later remembered what a flashing light meant, despite never having had to refer to it again? Either this guy has freakishly good memory (possible but unlikely) or he’s bullshitting. Given the overall tone I’d go with the latter.
And what is even the advantage of knowing in advance? Does he think people would not read the manual after seeing a flashing error light? You can look up most issues when they happen you don’t have to memorise error codes in advance.
I agree with you, but reading beforehand has the advantage of knowing what to look out for to keep your device from getting to the “flashing light” stage.
syklemil@discuss.tchncs.de
on 20 Aug 09:04
nextcollapse
For those who want to give it a go:
#!/bin/bash
set -euo pipefail
while read -rd ":" path
do
for bin in "$path"/*
do
# don't error out if there's no manpage
set +e
man "$(basename "$bin")"
set -e
done
done < <(printf '%s%s' "$PATH" ":")
when you get sick of it, hit ^Z (ctrl-z) and go kill %1. Then you get to start all over from the start next time!
Bonus points for starting a tracker so you can count how long it takes to go from “eugh, what’s with that overwrought and excessively defensive bash script” to “fuck, now I’m doing it too”
LeFantome@programming.dev
on 20 Aug 16:10
collapse
I am not much of a bash guy so it took me a moment to understand what this was doing.
Too bad I have to read so many man pages before I get to bash or sh.
syklemil@discuss.tchncs.de
on 21 Aug 10:11
collapse
Well, bash should show up quickly enough. But yeah.
I’m also no longer much of a bash guy. Back when I was my scripts were a lot simpler, and broke in weird ways a lot more. And every time I picked up a new defensive habit, my bash became a little bit uglier, and I thought to myself “maybe I should just do this in Python”.
But this script would be a lot longer in Python.
chaosmarine92@reddthat.com
on 20 Aug 09:52
nextcollapse
He skips over the extremely important points of first knowing that a manual exists and knowIng how to access it. Then knowing what all the jargon means and what the manual doesn’t say because its written assuming a high level of knowledge already.
technocrit@lemmy.dbzer0.com
on 20 Aug 15:31
nextcollapse
Yeah very true. I was floundering with an issue recently. I couldn’t find any help until I added “docs” to my search. RTFM.
LeFantome@programming.dev
on 20 Aug 16:20
nextcollapse
Einstein reportedly said “Never memorize something you can look up in a book”. When asked the speed of sound he said , “I do not know but that number is commonly found in textbooks”.
I am not going to spend my life reading manuals. Reading my furnace manual years before a problem arises is unlikely to help me.
However, I completely agree that RTFM is a great thing to do with confronted with a gap in knowledge or problem to be solved. Not the whole manual probably, just the relevant parts.
I think it is much more important to store ideas in your head than information. That said, those ideas do not come from nothing.
I might not read the man pages of every command on a Linux system. At least, not all of them. But I should know high-level what commands are available and what they generally do. That allows me to think of them when they would be useful. But I probably have no idea what the proper syntax is for any of them when I go to use them.
And “the manual” is not always the best place to get ideas, even if it is the authoritative source for specific knowledge.
Time spent reading the manual is time not spent doing something else. Spend your time learning. Spend most of it learning what is possible. In my view, that is the best strategy.
brygphilomena@lemmy.dbzer0.com
on 20 Aug 18:56
collapse
I think reading the manual gives you the concept of what something is capable of doing. No one is saying memorize all the commands and their flags.
But if you read all of them, maybe some day you’ll have a problem and realize, wait… I’ve seen something like this before. And you can then look up the specifics.
LeFantome@programming.dev
on 20 Aug 20:45
collapse
We may not be disagreeing. I guess it depends what you mean by read.
hornywarthogfart@sh.itjust.works
on 28 Aug 17:13
collapse
The main point I took away from your comment, and the thing that I think is missing in most of the other comments, is application of this concept to the real world. You nailed it. Always read the manual is a nice sound bite and something that can be flippantly thrown around to feel superior but that is terrible advice without any context.
What it should say is: Always refer to the manual.
Part of being a human is prioritizing tasks based on need and/or want. Another part is understanding your personal needs to accomplish a task. Reading a manual may provide value. Spending the 2 hours with family also provides value. If I choose the latter I can still refer to the manual when needed.
It drives me crazy when people double-down on some distinct thing (always read the manual) and then preach that it should always be the case or apply to all situations. There is a concept of diminishing returns and people should teach how to figure that out rather than blast out a good sound bite. Let people identify what works for them and be respectful of that. I’m not sure why that is such a hard concept for people.
Modern_medicine_isnt@lemmy.world
on 20 Aug 18:38
nextcollapse
Have you seen the manuals today? 90% of the content for a product manual is CYA.
In the next year or so they will all be written by AI.
Also, different people have different learning styles. A manual is just one. Many of us learn better by having something real to do, and learning by doing.
varyingExpertise@feddit.org
on 20 Aug 19:06
nextcollapse
Actually, several hours of cursing and trying are an excellent substitute for up to three minutes of manpage reading.
Hahaha. Most here making excuses why they don’t read manuals.
Kabutor@lemmy.dbzer0.com
on 21 Aug 07:53
nextcollapse
I had a problem with sendmail about 20 years ago, for several days I tried ro fix it, the only way I fixed it was reading the manual, not the whole manual because about half I read what was i doing wrong.
Read the manual and touch every button! The most important lesson my father ever taught me was that you can’t break software permanently. We can always fix it, worst case we just install it again. Computers are toys and I played without fear
threaded - newest
Linux version of a cold plunge.
Unironically my advice to people asking how to get started programming (at a c++ shop) included going through everything on cppreference.com and using every function in a playground at least once.
Isn’t that like telling someone to write every word down? And as such does not really help understand things? It trains how to type the syntax.
If it wasn’t clear, I meant to do something with each function in some test code and understand it… Not just type it in…
When learning a new human language, it’s good practice to also learn sentences and practice speaking and writing, not just rote vocabulary memorization.
When learning a new human language, it’s good practice to also learn sentences and practice speaking and writing, not just rote vocabulary memorization.
Not to take away how important reading these things are but I hate how people with a functional memory have no idea what life is like for people with poor memory. I would forget everything I read the minute button mashed the keyboard to quit the manual. It’s like when trying to imagine what is like living as one of those people without an inner voice. It’s such a foreign idea that its a shock when you realize some people don’t have one
Bro’s not saying you have to memorize the manual, just like … read it. Even a bit of familiarity goes a long way.
If you have literally no memory then command line is 100% unusable but otherwise every little bit helps.
No memory is me being hyperbolic but it’s severely limited. So I feel like reading a manual line by line means I get much less out of it but it’s a large amount of time invested. So I have to factor in that my retention vs time on task is pretty skewed. It’s frustrating. I need to do something a few times to learn. Learning by reading is not great for me. But tech is a very document heavy industry
Most people don't memorize things just by reading them. If you chose to construct some simple exercises/examples for yourself to learn by doing, this is very normal and in fact a good idea!
Thanks I’ll give that a try.
So: read the man page, find the switches and options you need and hand write that bitch on a notepad, close the man page and execute the command. It’s tedious but it will help your not-great memory work a lot better.
Or easier, just fire up multiple tty’s. The poor person’s tabs.
What does tty mean in this context?
In this context it is multiple command line instances, like multiple terminals.
Thank you for the advice. I’ll try that
tldr.sh
cheat.sh
I don’t know if you mean you don’t remember the gist even, but it’s more about learning about what’s possible with what so you can look up specifics when you need them than remembering the contents wholesale
This is exactly it. Do I have to read a reference for regex every damn time? Yes. But I also have an idea of what it can do; and knowing that, I have a vague idea when a problem presents itself that I could use regex to solve it.
Edit: Hello Zalgo my old friend.
This is great perspective and advice. It’s how I learn too. I always felt like a poor performer because in my life I haven’t been able to recall specifics after learning something when I compared to others. I’ve got a complex. But general what you describe is how I recall. Almost in chunks but not specifics.
How did they know to do “ls /usr/bin” in the first place?
That bit’s just genetic.
.
"For weeks I typed random letters into the command line, and when I entered
ls /usr/binandmanfinally something happened!How did they know how to get to the command line?
Isn’t that what your computer boots into? Mine sure does!
Reading the manual of a refrigerator? To know how to open the door or what? Sorry but that is laughable and in no way helps anyone understand anything, manuals are utter trash today. You do need to be curious etc. but advocating reading manuals of such appliances makes me question the whole story, that is how absurd that is.
Does the refrigerator have air or water filters that need to be replaced? How do you do that and how often?
Is there a maintenance schedule for pulling it out and cleaning dust from any heat dissipating elements?
How often should the water hose for the ice maker be checked and replaced?
Is there a trick to removing shelves for cleaning?
How would you even know when to take it in for an oil change??
And set the temperature. And learn how often to clean what parts. And how to take out the shelves and drawers without breaking them. And. And. And.
Does the freezer need to be defrosted at a regular interval? Does it have filters? Does placing items in certain places which block the vent affect performance?
Why is my warranty void?
“Read The Fabulous Manual”
I got started programming by reading the manual of my TI calculator during a boring history class. It really does work.
RTFM FTW
I mean sure. This usually works okay. But some manuals are terrible. Specially those written by Google and Microsoft. Well mostly Microsoft. Google was probably good, I was just major verions behind.
Because their programmers are too busy to RTFM themselves to properly write a decent FM.
Google docs are written like they assume you already know the docs. 🙃
The only google docs I’ve used are for Google Analytics and they are TERRIBLE
IME I’ll rather find some openapi docs for Google than their actual product docs. As in, I’ll start out trying to read their kubernetes docs, then shortly after it’s “fuck it, I’m going to docs.rs/k8s-openapi”.
My actual worst case are Elastic’s docs, though. Somehow they have plenty of stuff in there, just never the stuff I’m trying to figure out.
Many man pages are also terrible
ls /usr/sbin/ if you’re hardcore.
If you are hardcore, your distro puts /bin, /usr/bin, and /usr/sbin in all in the same directory.
I don’t use Arch, BTW.
Cool. I used to but mostly Chimera Linux these days.
That said, I probably have more instances of Debian running than anything else if you count VMs and containers.
The distro matters less than it used to now that we have Flatpak and Distrobox.
Yes, I of course read the docs. Yes, I didn’t fuck it up first and then went back to do double work because I was being lazy and wanted the quick dopamine hit of seeing something on the screen. That wouldn’t be me!
The latest manuals I’ve read were from shitty Chinese manufacturers who didn’t even proofread what they wrote. They were asked to put foreign letters on a page and that’s what they did.
This is the next level of learning. Not only do you read how it is, you have to deduct, to assess and explore. Writing your own documentation is the best way to learn after all.
Unfortunately, the manual on goods these days is roughly the size of a post-it note. And even if they have proper ones, none of them have the full technical readouts, blueprints and repair guides that they used to back in the day.
Déjà vu.
Man pages in Linux are commonly meant for people already familiar with command structures, specific terms etc.
They are often borderline useless for an inexperienced user.
At work people think I’m some kind of wizard with git.
I tell them I’ve been using it every day for 15 years and I read the freely available book on the website, link them to it, and mention the first 3 chapters probably covers 90% of their normal usage so they should just read that.
They won’t do it. I don’t get it. Something about written words is scary to them.
Same here. I obviously don’t remember everything because I rarely if ever have to use them, but at least when the time finally comes that I need “git bisect”, I’ll know that “git bisect” exists and I’ll be able to go straight to the manual page that documents it.
No one expects anyone to read the manual and remember it all… But you will naturally remember the big lines and be able to refer to the right place when you need something.
This is my exact experience with a lot of things. I just skimmed through the first party documentation for $thing and it pays huge dividends over time when compared to trying to learn from the relatively context-sparse stack overflow or chatbot
This goes against what we know about good design. Where possible you shouldn’t need to use a manual. Telling people to always read the manual is a cop out.
Also he apparently read his furnace’s manual and months/years later remembered what a flashing light meant, despite never having had to refer to it again? Either this guy has freakishly good memory (possible but unlikely) or he’s bullshitting. Given the overall tone I’d go with the latter.
And what is even the advantage of knowing in advance? Does he think people would not read the manual after seeing a flashing error light? You can look up most issues when they happen you don’t have to memorise error codes in advance.
This is just a dumb “I’m so great” post.
I agree with you, but reading beforehand has the advantage of knowing what to look out for to keep your device from getting to the “flashing light” stage.
For those who want to give it a go:
#!/bin/bash set -euo pipefail while read -rd ":" path do for bin in "$path"/* do # don't error out if there's no manpage set +e man "$(basename "$bin")" set -e done done < <(printf '%s%s' "$PATH" ":")when you get sick of it, hit
^Z(ctrl-z) and gokill %1. Then you get to start all over from the start next time!Bonus points for starting a tracker so you can count how long it takes to go from “eugh, what’s with that overwrought and excessively defensive bash script” to “fuck, now I’m doing it too”
I am not much of a bash guy so it took me a moment to understand what this was doing.
Too bad I have to read so many man pages before I get to bash or sh.
Well,
bash should show up quickly enough. But yeah.I’m also no longer much of a bash guy. Back when I was my scripts were a lot simpler, and broke in weird ways a lot more. And every time I picked up a new defensive habit, my bash became a little bit uglier, and I thought to myself “maybe I should just do this in Python”.
But this script would be a lot longer in Python.
He skips over the extremely important points of first knowing that a manual exists and knowIng how to access it. Then knowing what all the jargon means and what the manual doesn’t say because its written assuming a high level of knowledge already.
You mean using Google do learn the words you don’t know?
That’s not it, no. There’s a lot more to it.
You can even learn a new language if you first read the version in a language you know and then do a language you don’t know yet.
Does someone have the tldr?
/s
RTFM
Yeah very true. I was floundering with an issue recently. I couldn’t find any help until I added “docs” to my search. RTFM.
Einstein reportedly said “Never memorize something you can look up in a book”. When asked the speed of sound he said , “I do not know but that number is commonly found in textbooks”.
I am not going to spend my life reading manuals. Reading my furnace manual years before a problem arises is unlikely to help me.
However, I completely agree that RTFM is a great thing to do with confronted with a gap in knowledge or problem to be solved. Not the whole manual probably, just the relevant parts.
I think it is much more important to store ideas in your head than information. That said, those ideas do not come from nothing.
I might not read the man pages of every command on a Linux system. At least, not all of them. But I should know high-level what commands are available and what they generally do. That allows me to think of them when they would be useful. But I probably have no idea what the proper syntax is for any of them when I go to use them.
And “the manual” is not always the best place to get ideas, even if it is the authoritative source for specific knowledge.
Time spent reading the manual is time not spent doing something else. Spend your time learning. Spend most of it learning what is possible. In my view, that is the best strategy.
I think reading the manual gives you the concept of what something is capable of doing. No one is saying memorize all the commands and their flags.
But if you read all of them, maybe some day you’ll have a problem and realize, wait… I’ve seen something like this before. And you can then look up the specifics.
We may not be disagreeing. I guess it depends what you mean by read.
The main point I took away from your comment, and the thing that I think is missing in most of the other comments, is application of this concept to the real world. You nailed it. Always read the manual is a nice sound bite and something that can be flippantly thrown around to feel superior but that is terrible advice without any context.
What it should say is: Always refer to the manual.
Part of being a human is prioritizing tasks based on need and/or want. Another part is understanding your personal needs to accomplish a task. Reading a manual may provide value. Spending the 2 hours with family also provides value. If I choose the latter I can still refer to the manual when needed.
It drives me crazy when people double-down on some distinct thing (always read the manual) and then preach that it should always be the case or apply to all situations. There is a concept of diminishing returns and people should teach how to figure that out rather than blast out a good sound bite. Let people identify what works for them and be respectful of that. I’m not sure why that is such a hard concept for people.
Yeah, but where is the manual to read the fucking manual ?
you talking about school?
Yeah, that shit that bore you to death. Who needs it anyway? Ignorance is strength.
right?
/s
Manuel had it last.
Have you seen the manuals today? 90% of the content for a product manual is CYA. In the next year or so they will all be written by AI.
Also, different people have different learning styles. A manual is just one. Many of us learn better by having something real to do, and learning by doing.
Actually, several hours of cursing and trying are an excellent substitute for up to three minutes of manpage reading.
Hahaha. Most here making excuses why they don’t read manuals.
I had a problem with sendmail about 20 years ago, for several days I tried ro fix it, the only way I fixed it was reading the manual, not the whole manual because about half I read what was i doing wrong.
If everything else fails, read the manual
Read the manual and touch every button! The most important lesson my father ever taught me was that you can’t break software permanently. We can always fix it, worst case we just install it again. Computers are toys and I played without fear