

Ask HN: Implementing stuff, learning new things.Depth first or breadth first? - znpy

Hi HN!<p>I am implementing a toy project, and experimenting with Go, XML, web services and other stuff.<p>I reached a point where I need to do XPath stuff, and looked around the internet for documentation (XML itself, XPath&#x2F;XQuery&#x2F;X&lt;things&gt;, and Go libraries).<p>I have downloaded &quot;documents&quot;, some of which are quite extensive and detailed.<p>So here is the dilemma: is it better to just skim the documentation on things I don&#x27;t know and get things working (``get shit done&#x27;&#x27;) or is it better to sit down and read most or all of the documentation?<p>The advantage of reading most or all of the documentation would be mastery of the topic, but the threat is to delay the implementation of my project by a lot, possibly losing interest in the project (possibly finding something else interesting).<p>While this may sound as a situation-specific question, I think it may be way more general, and I&#x27;d like your opinion on the topic.<p>Thanks in advance,
-- 
znpy
======
dibbo
I personally prefer looking at the relevant parts of the documentation and
getting shit done.

Advantages:

1\. shit gets done 2\. concepts that you learn get applied immediately, so the
concepts stick in the brain better 3\. harder to lose motivation since shit is
getting done 4\. it is harder to understand certain concepts abstractly, after
all we are talking about programming, not theoretical physics; most
programming concepts are better understood in practice esp. web based stuff.
So reading and applying immediately is most often the right way to go.

Disadvantages:

1\. there might be advanced functionality that you might miss if you skim
through and apply, however most advanced functionality are optimizations and
as we all know 'premature optimization is the root of all evil'. Donno who
said that but it was someone famous. So this isn't a real disadvantage at all.

In summary, I would recommend a depth first approach, with the caveat that you
go really deep into the things that you do need in the project and ignore the
things that you don't need at the moment.

