I'm sure everyone has their own approaches for this kind of thing, but mine is basically this:
Try to remember what was difficult about this material.
Use that to guide yourself down to the core pieces. What is the kernel at the center of this mass of knowledge? "This would have been easy to learn if only... [what?]"
Often if you view the particular ecosystem as a dependency graph, the places to start are the root dependencies. If you go back far enough, there tends to be a single root.
Make sure that core foundation is well-covered and answers all those questions that made the material difficult when you learned it.
Then add some more use cases on top of it just to give the reader ideas of what they could go on to build. This won't be comprehensive, but should be tempting.
The very act of _learning to program_ should be exciting and fun. I recall when I was 12--every page of a programming book was unlocking something else in the world. "Wait--it can do _that_?" I try model this more as a path to follow at first and less of an open field going off in all directions. And I try to _hint_ that it _is_ actually an open field going off in all directions, but the reader can explore that later.
Don't worry about being wrong. Make an effort to be right (pride in quality) of course; just remember that everyone who produces a laundry list of reasons why your guide is crap and you shouldn't be allowed near a keyboard has just given you some free editing. :) If the points aren't valid, you can ignore them. If they are valid, you learn something (win), the guide gets better (win), everyone who reads it after the fixes gets better-quality info (win), and the complainer can no longer complain about those things (win). And ask Brian Kernighan or Rob Pike if they've ever published something wrong, and I guarantee they'll laugh knowingly. :)
My tone--I imagine I'm being a goofball discussing this with one of my best friends. I like that tone, I have an easy time writing in that tone, and it seems to be pretty popular. But I've also definitely had people complain about it being too casual. I don't know what to say, other than...
We're knights of the round table
We dance whene'er we're able
We do routines and chorus scenes
With footwork impeccable
We dine well here in Camelot
We eat ham and jam and spam a lot
Dah dah dah da da dah dah... [dude clapping in the dungeon]
Also, don't forget to reread and rewrite everything. There's always room for improvement.
Try to remember what was difficult about this material.
Use that to guide yourself down to the core pieces. What is the kernel at the center of this mass of knowledge? "This would have been easy to learn if only... [what?]"
Often if you view the particular ecosystem as a dependency graph, the places to start are the root dependencies. If you go back far enough, there tends to be a single root.
Make sure that core foundation is well-covered and answers all those questions that made the material difficult when you learned it.
Then add some more use cases on top of it just to give the reader ideas of what they could go on to build. This won't be comprehensive, but should be tempting.
The very act of _learning to program_ should be exciting and fun. I recall when I was 12--every page of a programming book was unlocking something else in the world. "Wait--it can do _that_?" I try model this more as a path to follow at first and less of an open field going off in all directions. And I try to _hint_ that it _is_ actually an open field going off in all directions, but the reader can explore that later.
Don't worry about being wrong. Make an effort to be right (pride in quality) of course; just remember that everyone who produces a laundry list of reasons why your guide is crap and you shouldn't be allowed near a keyboard has just given you some free editing. :) If the points aren't valid, you can ignore them. If they are valid, you learn something (win), the guide gets better (win), everyone who reads it after the fixes gets better-quality info (win), and the complainer can no longer complain about those things (win). And ask Brian Kernighan or Rob Pike if they've ever published something wrong, and I guarantee they'll laugh knowingly. :)
My tone--I imagine I'm being a goofball discussing this with one of my best friends. I like that tone, I have an easy time writing in that tone, and it seems to be pretty popular. But I've also definitely had people complain about it being too casual. I don't know what to say, other than...
We're knights of the round table
We dance whene'er we're able
We do routines and chorus scenes
With footwork impeccable
We dine well here in Camelot
We eat ham and jam and spam a lot
Dah dah dah da da dah dah... [dude clapping in the dungeon]
Also, don't forget to reread and rewrite everything. There's always room for improvement.