[python-advocacy] vaporclass: a bring-your-own-project Python workshop
"Catherine Devlin" <[email protected]> Fri, 14 Jul 2006 22:25:57 -0400
| Newsgroups | gmane.comp.python.marketing.general |
|---|---|
| Message-ID | <[email protected]> |
--===============0594501928== Content-Type: multipart/alternative; boundary="----=_Part_56157_9688270.1152930357782" ------=_Part_56157_9688270.1152930357782 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Pythonistas! I've thunked up a vaporware structure for an ev angelical Python class/workshop to put on. It's based on the way I tend to want to learn, hoping that I'm not that unusual. I'd like to get peoples' comments/ideas, especially if you've ever experienced a class like this. Here's how it would go. Before the workshop, attendees decide on a program they'd like to create, something they'd genuinely appreciate for their own use. They e-mail this to the instructor, who confirms that the scope isn't overly (or underly) ambitious for the workshop. Sample ideas will be available for those who don't have their own. (Project suggestions are an easy way to contribute to this concept!) But students are very strongly encouraged to create their own; project ownership is a big part of the workshop concept. Students bring wireless-enabled laptops. Of course, if the class can be held someplace that has networked computers already installed, then we can leave the laptops out - so much the better! When they arrive, everybody brings up a class webpage. This has a good index to material about Python and topical material, a springboard for their research or reading-ahead. The instructor starts to lecture... but not for long. Snippets of lecture/demo, perhaps 5 minutes each, are interspersed with chunks of time for students to experiment, to read, and to work on their projects. During that time, the instructor (and assisting coaches, if available) circulate among the students, helping them over roadblocks. And, of course, students are encouraged to do the same for each other. When the instructor is covering material the students already know, they are -encouraged- to zone out and zoom on ahead. Each slide has a little course outline with the current topic highlighted, to help the students figure out at a glance when they need to zone back in. The workshop may have multiple starting times, i.e., "9:00 for first-time programmers, 10:00 for programmers new to object-orientation, 10:30 for experienced OO programmers". By the end of the workshop, each student should be finished with, or well underway with, their project. They'll have basic Python skills, and will really understand what we mean when we sing about Python's productivity and practicality. I like the workshop format because, to me, learning seems to happen best at the interfaces between class instruction, interpersonal discussion, personal reading, and hands-on experimenting. The switching-points between the four modes seem to be the most productive ones, when I take an idea from one mode and apply it in another. Unbroken hours of any one mode just don't do as much. Hands-on workshops maximize those learning-rich switching-points. The big difference with regular workshops is the bring-your-own-project aspect. My hope is that this would help show people that Python will be useful -to them-, in the work they care about. It's really hard to move patiently through a demo while thinking "I'll never actually need to use this", and demo projects that somebody has pre-decided (and pre-solved) lack that excitement of ownership and creation. It makes the whole thing a lot less deterministic, not knowing which directions the students will be going in, but I think that's an acceptable price - maybe even a good thing. Sure, the instructor will be stumped sometimes, but "how to research for solutions" will be part of the class, too! (That's definitely an important topic usually neglected by texts, anyway.) And maybe students will be even more excited if the students around them aren't just competitors to race against toward the single finish line, but examples of flowering and diverse creativity. Thoughts? Personally, I'd like to do one of these in my area as soon as I can muster the time (ha!) and the courage (ha!) - maybe in time for the Ohio LinuxFest on Sep. 30 (ha!). If anybody would like to drive out to Columbus to help with that, I'll take you to Ben & Jerry's. :) The concept also needs a clever name. Everything in open-source needs a clever name. And an animal mascot. Thoughts, anyone? -- - Catherine http://catherinedevlin.blogspot.com/ ------=_Part_56157_9688270.1152930357782 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, Pythonistas!<br><br>I've thunked up a vaporware structure for an ev ang= elical Python class/workshop to put on. It's based on the way I tend = to want to learn, hoping that I'm not that unusual. I'd like to get p= eoples' comments/ideas, especially if you've ever experienced a class like = this. <br><br>Here's how it would go.<br><br>Before the workshop, attendees decid= e on a program they'd like to create, something they'd genuinely appreciate= for their own use. They e-mail this to the instructor, who confirms = that the scope isn't overly (or underly) ambitious for the workshop. = Sample ideas will be available for those who don't have their own. (P= roject suggestions are an easy way to contribute to this concept!) Bu= t students are very strongly encouraged to create their own; project owners= hip is a big part of the workshop concept. <br><br>Students bring wireless-enabled laptops. Of course, if the cl= ass can be held someplace that has networked computers already installed, t= hen we can leave the laptops out - so much the better!<br><br>When they arr= ive, everybody brings up a class webpage. This has a good index to ma= terial about Python and topical material, a springboard for their research = or reading-ahead. =20 <br><br>The instructor starts to lecture... but not for long. Snippet= s of lecture/demo, perhaps 5 minutes each, are interspersed with chunks of = time for students to experiment, to read, and to work on their projects.&nb= sp; During that time, the instructor (and assisting coaches, if available) = circulate among the students, helping them over roadblocks. And, of c= ourse, students are encouraged to do the same for each other. <br><br>When the instructor is covering material the students already know,= they are -encouraged- to zone out and zoom on ahead. Each slide has = a little course outline with the current topic highlighted, to help the stu= dents figure out at a glance when they need to zone back in. <br><br>The workshop may have multiple starting times, i.e., "9:00 for= first-time programmers, 10:00 for programmers new to object-orientation, 1= 0:30 for experienced OO programmers".<br><br>By the end of the worksho= p, each student should be finished with, or well underway with, their proje= ct. They'll have basic Python skills, and will really understand what= we mean when we sing about Python's productivity and practicality. <br><br>I like the workshop format because, to me, learning seems to happen= best at the interfaces between class instruction, interpersonal discussion= , personal reading, and hands-on experimenting. The switching-points = between the four modes seem to be the most productive ones, when I take an = idea from one mode and apply it in another. Unbroken hours of any one= mode just don't do as much. Hands-on workshops maximize those learni= ng-rich switching-points. <br><br>The big difference with regular workshops is the bring-your-own-pro= ject aspect. My hope is that this would help show people that Python = will be useful -to them-, in the work they care about. It's really ha= rd to move patiently through a demo while thinking "I'll never actuall= y need to use this", and demo projects that somebody has pre-decided (= and pre-solved) lack that excitement of ownership and creation. It ma= kes the whole thing a lot less deterministic, not knowing which directions = the students will be going in, but I think that's an acceptable price - may= be even a good thing. Sure, the instructor will be stumped sometimes,= but "how to research for solutions" will be part of the class, t= oo! (That's definitely an important topic usually neglected by texts,= anyway.) And maybe students will be even more excited if the student= s around them aren't just competitors to race against toward the single fin= ish line, but examples of flowering and diverse creativity. <br><br>Thoughts? Personally, I'd like to do one of these in my area = as soon as I can muster the time (ha!) and the courage (ha!) - maybe in tim= e for the Ohio LinuxFest on Sep. 30 (ha!). If anybody would like to d= rive out to Columbus to help with that, I'll take you to Ben & Jerry's.= :) <br><br>The concept also needs a clever name. Everything in open-sour= ce needs a clever name. And an animal mascot.<br><br>Thoughts, anyone= ?<br><br>-- <br>- Catherine<br><a href=3D"http://catherinedevlin.blogspot.c= om/">http://catherinedevlin.blogspot.com/ </a> ------=_Part_56157_9688270.1152930357782-- --===============0594501928== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline