READ THE FUCKING MANUAL!
read the FRIENDLY manual.
Sorry for swearing, I'm not the one who came up with that. But it rings true.
Instead of fighting your code and assuming you already know how to code something based off previous experience, go read the docs (manuals).
Here is why. You may have already studied up on something and might even be using it daily! But sometimes you learn something with an assumption that was incorrect, yet due to how you were using it, it just worked.
Then you come to an issue and you waste hours trying to make it work, since last time you got it to work! Banging your head against the keyboard. You google everything you can... but why not just go to the source of truth?
I am sooooooooo guilty of this, it's why I'm writing this post. It's more of me calling myself out so I stop doing it!
Take Jest for an example. We use it for our unit test in every project. But for what ever reason, I struggle mocking classes every time. I think I remember how to do it, just to spend hours fiddling with the right solution.
Part of the issue is the time in between projects, but mostly due to me going off my assumption that I know what I'm doing based off that I got it working last time.
Well this time, I decided not to fight it. I read the docs. And sure enough I was wrong on what I thought it was doing.
So do yourself a favor. Before going off aimlessly for hours, go to the source of truth and confirm you know exactly what you need to do and how it works.
I hope this saves you hours of your life!
- DeChamp
Top comments (11)
Hours of trial-and-error can save you minutes of reading documentation ;)
i see what you did there. lol
I do agree that reading the docs is a good practice. However, IMHO, the best thing you can do is to learn and practice what you are doing! You don't want to be the copy and paste doc reader, totally opposite, you must be a read and learn kind. Also, keep in mind that manuals are guides, not solutions.
Yes, I agree and I think this goes without saying. It's always best to get hands on and create/break/fix. I do not encourage copy and pasting but that isn't really a docs thing, that is more of a overstack thing. This is aimed more for those who have a habit of assuming them know how it works, and it's just a solution to avoid wasting countless hours.
Docs are great. I was intimidated by them for years but after finally reading them - they are so enlightening.
They can definitely be overwhelming for sure. for example, I don't know what is about mysql official docs but i cannot understand them for the life of me. I use other docs for it.
I don't agree with telling beginners to read the fucking manuals.
Whenever a beginner try to Read The Fucking Manual, he will waste a lot of time, get frustrated that he cannot do anything with it, feel stupid, thinks he is an imposter, ...
What they should do instead is to Read the Friendly Manuals.
But they may not have learned yet to know which manuals are friendly and which are fucking.
So I feel it's our responsabilities as more experienced developers to not just tell them to read the fucking manuals but instead guide them towards the friendly sort.
It's ok not to agree with me. I feel like you didn't read the whole post and maybe just glanced at the title. Perhaps you made an assumption that I said new people should leave us other devs alone and read the manual. Which i did not say. I said simple that that term can be handy, because instead of assuming you know something, why not just reference the guides?
This was in reference to a person of a certain type, who spends hours assuming their code should work, just to find out they were remembering it wrong and a quick read up on the actual official docs could help them.
I do like the "friendly" part, so I'll change my title!
Hello I did like your post, I disagreed with the title only. And now both are good :)
and this is why I write the docs. And why it used to make me sad when people ignored my docs. Hard-learned lessons people! You don't have to learn it the hard way because I went and talked to the feature designer/implementer and got the skinny on the intent and best way! (Once upon a time. It's not quite so clear cut these days, but it was a great 5 years in the 90s.)
From the little experience I have, documentation has saved me more time.