> So in general I actually make an attempt *not* to worry about doing things > wrong, or > about the API, or frankly anything else, because any of those concerns > would > be a barrier to actually doing the work.
You could argue that once you're familiar with the paradigm, learning a new language is just syntax and libraries. What you need to know before you can put a curriculum together is: a) What does your target audience already know? If the potential students already understand control structures, loops, data structures, and algorithms, then skip to syntax and go adventuring through the built in or popular libraries. Otherwise spend a little time on each of those points. b) What specific tasks will they want to accomplish when they're done with your curriculum? A lot of programming work, for example, consists of modifying existing code without changing the underlying architecture. If these are the jobs you're after, it's probably not worth spending a lot of time on architecture skills. I'm a big fan of top-down learning, and I'm sure at least one of you has had to listen to my amazement that more people don't teach that way. From that perspective, putting together a set of projects where you can quickly see something working (even if that's only because 90% of the work was done when you got there) is the way to go. I would also recommend growing into some architectural skill eventually, since that is an excellent differentiator at just about every level of development. /thor
_______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) Vassar College Jan 4 - Getting Involved in Open Source Feb 1 - Home Networking Made Simple with Amahi Home Server
