Hey there!ð Good to be back. I was off working on a project with a team of seasoned product designers and software engineers. You know what they say about surrounding yourself with people ahead of you in your field. You level up! It works like magic. âĻ
One of the things I learned was how to research. Before now, when faced with a challenge, I run off to google and pick any answer I find on StackOverflow or any other top-ranking solution and try it out. Doing that is not entirely a bad idea, but most tools we use as developers come with their official documentation.
A prime indicator that developers are struggling is that solutions from StackOverflow and other sources rank higher than some official docs on Google. ð
Check this out:
âĶ
Now, here comes the proffered solution:
She goes on! Akasha, the gift that keeps on giving! ðđ
Note this:
I should've gone through the docs
Well, that's it. Read the documentation!
The documentation contains everything you need to know. Study it patiently. It will save you a lot of time and damage.
See professional advice below: ðĪŠ
One can argue that documentation is boring to read, especially for code newbies, because they are not visually attractive. Also, in my case, there is just this urge to get into action without wasting time. ðĪ·ð―ââïļ
However, it is the mark of an experienced developer to find the official documentation and study it before writing code, especially when trying to use a new language, framework or tool.
Some Things to Note
Think of documentation like a recipe. To get the desired outcome, you should follow it step by step and carefully.
People write documentation. There are tools like swagger that help with documentation. Nevertheless, they are concise. You need to focus.
Understand that information is a priority in the documentation. Hence, it will be very detailed.
The official documentation is the most reliable, updated source of information regarding any product (language, framework)we intend to use, especially if the product is newly developed.
Read the overview to know what is required to allow optimal use.
You should ensure the versions are up to date or at least the same as the one in the documentation you are referring to.
Be sure about what you are looking for in the documentation. The 80-20 Pareto principle posits that you will use only about 20% of the features 80% of the time. Most of the contents will only come in handy once in a while.
Check the tutorials provided in the documentation and use the playground to try things out if it is available.
Search the documentation with keywords when faced with a particular problem.
Even if you prefer to bounce ideas off of people, you will benefit more if you at least glance through the documentation.
REFERENCES
- https://javascript.plainenglish.io/why-is-reading-the-documentation-so-important-5cf50bab0c9f
- https://www.sqlskills.com/blogs/paul/rtfm-no-seriously-r-t-f-m-then-ask-your-question/
- https://www.freecodecamp.org/news/how-to-read-your-way-to-becoming-a-better-developer-b6432fa5bc0c/
- https://phoebephuongnguyen.medium.com/how-to-find-and-read-api-technical-docs-bedac0b4b0e8
- https://medium.com/@laymanExplained/layman-explained-reading-documentation-36c450e77e6b
- https://blog.techtalentsouth.com/8-tips-to-reading-documentation-a-newbies-guide
- http://cassandrawilcox.me/beginners-guide-developer-documentation/
Top comments (7)
Nice ð I always read F***** in this context as Friendly!
It must be said however that a lot of software in use doesn't always have readable or comprehensive documentation - something that can also be discovered by the ranking of search results, if you don't find links to online official docs early on, it's likely they aren't useful. If you are familiar with such a piece of software, do the world a favour and document it better (even if you didn't write it - this often leads to better consumer-focused docs too!)
Friendly is good too!
I usually go with Fascinating. Or Fabulous.
Oh well ðĪ·ð―ââïļ
ð Friendly it is then! Noted! Thank you, Phil ð
ð... Read the docs
ð ð
Amen! :-)