On Sun, 2008-04-27 at 13:22 -0500, Ryan Neufeld wrote:
> I was going to email this exclusively to my mentor, xdotx, but I
> figured there may be others who have a say.
>
> I am about to hop into some heavy documentation reading this week, and
> frankly, I have never done anything like this before. What advice do
> you more experienced programmers have on getting to know a piece of
> software through documentation? Is it, say, like reading a book?
> Studying for an exam? Memorization? Trial and error? Playing with code
> while reading? or a mix of all of the above?
>
> My initial idea, and please critique this, is to give the
> documentation a relatively quick read-over, not necessarily consulting
> with the code itself, just the docs. Then, having gotten a taste for
> it, I want to start going over sections of the documentation with
> actual source code on my other monitor, seeing how things are used,
> etc. From there, I don't know, perhaps creating "play" rulesets to toy
> with, etc. What do you think?
This seems like a good approach. Generally speaking a large body of
documentation is pretty boring. If you aren't interested in reading it
you are probably wasting you time. So read the documentation to answer
questions and you'll get more out of it.
So play rulesets would be my main target for you, then go to the
documentation to answer the questions that will immediately pop up.
100 pages of API are a waste of time reading.
Regards,
nash
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
