DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for Do you actually read the documentation before you start to work on something?
Hannu-Daniel Goiss
Hannu-Daniel Goiss

Posted on

Do you actually read the documentation before you start to work on something?

Depending on the source, there are 3-10 types of learners.
But I would think to start to work on something (doesn't matter if it's coding or anything else), there are two ways to approach it:

  1. You read the documentation, watch some tutorials, or do anything else to get to know the subject. And then you try to apply whatever you have learned.
  2. You just start doing something. It doesn't work. You change something and try again. And try that over and over until it works.

I would consider myself to be part of the second group.
Which group do you belong to? How do you start to learn something new?

Top comments (29)

Collapse
iakovosvo profile image
iakovosvo

:D

Collapse
dvddpl profile image
Davide de Paolis

Golden

Collapse
hannudaniel profile image
Hannu-Daniel Goiss Author

this is so true!!!

Collapse
rubyrubenstahl profile image
Ruby Rubenstahl

I find that I tend to drift between both. Generally, when I come across a new library or whatever, I'll skim through the intro docs and examples, play with it a bit and get a feel for it, then if it's fairly intuitive, I'll pretty much just reference the docs as needed. If it feels more complex, I'll dive into the docs or find a tutorial to get a more thorough introduciton.

There is a third option, which I find myself turning to more and more: going to the source code when the docs don't answer your question. I have ADHD and often find docs hard to process where seeing the implementation often gives me better insight.

Collapse
hannudaniel profile image
Hannu-Daniel Goiss Author

I can totally relate to the third option. It's really hard for me to process docs. Especially the parts, which are not related to the thing I just want to solve right at that moment. I don't have the patience for it. I rather just try it.

Collapse
abbasc52 profile image
Abbas Cyclewala

I prefer understanding/learning the core concept of the thing i am planning to try. Documentation just show you some of the usecases, but if you understand the concept, it is easy learn or even predict the functionality the new thing has to offer. And often the core concept behind things are simple and relatable with other things.

I avoid trial and error unless there is no information anywhere. Coz alot of times the final result has many failed attempts and unnecessary things which we forget to clean up. Making whole thing "a working pile of mess"

Collapse
hannudaniel profile image
Hannu-Daniel Goiss Author

i admire that you can stick to the "correct" approach. probably your approach is less messy, as you mention there will be a lot of things to clean up at the end. and those, who do not have the patience to read the documentation first, will probably also not clean up in the end.

Collapse
jackmcbride98 profile image
Jack McBride

I read the documentation, then build something and play around with it, whilst referencing the docs. Then I'm usually familiar with it and start building things with it, if I run into problems or need some other functionality I google it, or look at the relevant part of the docs when I'm in a particularly functioning mode XD

Collapse
sherrydays profile image
Sherry Day

I usually discover things through posts on DEV, etc. If that post gives enough context that I understand why I want to try something, but not enough to really understand how to do it, perhaps I'll read the docs.

If that post gives me enough of the why and the how, maybe I just jump right in and play around β€” then find the docs when I need them.

Collapse
wordpressure profile image
TricaExMachina

I like to read the basics then find a tutorial and do it until I get it right, I find it helps me realize what I don't know so that when I go back to docs or search for tutorials I know what I need to focus on.

Collapse
fjones profile image
FJones

I usually set out with a specific problem to solve (either one I come across organically, or some project I build around the technology in question).

For a first feel of the tech, I tend to skim over the basics in the documentation - quick start, maybe a few tutorials for the relevant use case, figure out roughly how it works. From there on, I tend to experiment - usually aided by stub or code inspection, rather than direct documentation references. See what's available, work with that, try and see if I'm missing any QoL features, but in essence just make it work, and build the wrappers around it that my problem needs.

Collapse
hannudaniel profile image
Hannu-Daniel Goiss Author

i can relate to this as well. if i have a very specific problem, and it's mentioned in the docs, i'll skim through it. but usually i actually just try and see.

Collapse
dgloriaweb profile image
dgloriaweb

In most cases yes, but in Smarty Php's case it was much more efficient to google, test and note down results. Not all documentations are useful.

Collapse
hannudaniel profile image
Hannu-Daniel Goiss Author

how do you know if documentation is useful before you read it?

Collapse
dgloriaweb profile image
dgloriaweb

That the last entry is dated 2014.

Thread Thread
hannudaniel profile image
Hannu-Daniel Goiss Author

that makes sense!

Collapse
marissab profile image
Marissa B

I lean towards option 1 in most cases. A tutorial can get me up to take-off speed, but the wheels won't truly get off the ground until I try to do something for myself.

Collapse
ben profile image
Ben Halpern

It sort of depends. I find my process to generally follow different paths, sometimes super linear, sometimes much more all over the place.

Collapse
mopano profile image
Mopano

I watch quick tutorials and coding simple Project . So i'm both of them πŸ˜…πŸ€£

Collapse
uzair004 profile image
Muhammad Uzair

I generally go through docs & short crash course before I start working on new tech

Collapse
tik9 profile image
Timo KΓΆrner

Neither one nor two, BUT: reading documentation AND doing something. So I read docu first point, then do first point, then second and so on

Collapse
wasiqahmdzai profile image
Mohammad Wasiq

I read the docs for intro, setup and configuration, and then reference it whenever I need it.

Collapse
happping_min profile image
Min

222!!
Somehow I read documnet after the project is done.
I don't know why... Maybe I hate myself subconsciously

Collapse
hannudaniel profile image
Hannu-Daniel Goiss Author

some of us are like that :-D

Collapse
eljayadobe profile image
Eljay-Adobe

I like a tutorial, reference manual, and some example code to futz around with.

Collapse
lamvuhoang profile image
Lam Vu Hoang

I had a problem in my project and started learning about how to solve it. I'll probably have to read the documentation along the way, but I've only read the part that I need. Anyone like me?

Collapse
apollolabsbin profile image
Omar.unwrap();

It depends on the subject and how much background I have, but I feel in certain areas I'm in the first group, and in others I am in the second.

Collapse
tommy1099 profile image
tommy

I remember one day i wanted to learn something about Arch linux and there was a guy who referred me to a long long wiki page, i was like no way i would read this man, so i simply switch to manjaro :D

Collapse
hannudaniel profile image
Hannu-Daniel Goiss Author

wise decision πŸ˜†

🌚 Browsing with dark mode makes you a better developer by a factor of exactly 40.

It's a scientific fact.