This is pretty much how my "programming class" goes (it is an junior college intro to microcontrollers course). We usually start with a fresh OS install, Linux, VirtualBox, Windows VM, a bunch of other stuff, lots of hand-holding, step-by-step list. It is sometimes a very annoying disaster. There are always a few do-overs, sometimes from the clever ones, usually though it is the ones who are marking time.<p>Show them what a file is (look at it with a hex editor). Then work through the first couple chapters of K&R. Some scripted tasks. Try to get them to notice a little bit about what's really going on. Try to get them to understand the work flow (write, compile, test, etc). Show them some common pitfalls with data types, integer division, etc. Then on to "blink" with an Arduino, (working out the bugs of introducing hardware as we go). Work through a few examples, of increasing complexity. Start working on examples with external hardware. Then they propose an individual mini-project. We keep working on Arduino stuff, eventually involving serial comms with the device via Python, or Java (Processing) while coaching them through their mini-project. Also do some, data logging, plotting their data, pushing data out to the web (Pachube/Cosm/Xively).<p>Several times during the semester, students will be given a task, but not given any direction (at least not at first) on how it is to be done. Some students do exceptionally well. Some "A" students wind up with their first "B" or "C" because the format/structure is completely foreign to them. Others fight tooth and nail against the format, and probably against some of the other things I do that they were not prepared for.