Just going to attache this at the end, of the post but this is in response to many if not all the feedback I've got so far:
On the point of "Look just dive in and do a project you will learn as you go, ya you will make mistakes but you will learn from them, then after your hard work you will know what you need to know" Let me use an analogy ( to explain my frustration and others to that logic ): Student: "Teacher how can I learn French? So I can function in France for my two year job assignment." Professor: "Just go to France and start talking French, don't worry you will make mistakes at first but if you try really hard you will talk French" Student: "I don't think you understand what I am asking, let me put it another way...." Professor: "STOP... I know what your going to say, and that will not work, you just need to talk French, your just lazy" I think that all would are interested in learning are willing to put in the work. The question still stands what structure does one need to learn to be able to use the language to be able to create? Thus I am talking about "foundation" studying, granted it will be hands on real programming projects, but like learning a new spoken language how to lead the student so they can "think" in the new language. My last thought is that I feel that even code fixes need to be analysed with overall architectural impacts or need for change in future or upstream versions. I know that I do that in my day job, when we define a "bug" we have a fix/patch but we always review the impact and half the time re-work the next version to allow the fix to cover more "cases". Hope the clears things up. Need a solid foundation to build upon. On Tue, Dec 20, 2011 at 3:36 PM, Sean Swehla <[email protected]> wrote: > > 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 > > -- /** ** Joe Apuzzo ** Call Sign: KD2AKU ** PGP/GPG: pub key ID BB5C7 **/
_______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) MHVLS Auditorium Jan 4 - Getting Involved in Open Source Feb 1 - Home Networking Made Simple with Amahi Home Server
