Training
Updated Guide and Exercises
Students in my classes get my "guide"--a combination tutorial/reference text on practical Plone. It's essentially the entire content of my developer bootcamp, along with some advanced material, and lots of explanatory information. People often comment on how helpful and extensive it is. However, they also often comment on how long it is--about 450 pages. (What can I say? Plone is a powerful program with many good features!)
That said, though, several students have suggested that I cull the best-of reference stuff into a "Quick Reference guide". This is the kind of print-and-keep-under-your-pillow guide. It has all the slides and notes on tal:, CSS classes, Zope properties, etc.--all that stuff that would appear in "Plone in a Nutshell", if such a beast existed. (And a million thanks to the former bootcamp student who did hours of work helping me choose the right stuff, but who wishes to be anonymous. You know who you are, and you rock!)
I've also really beefed up my exercises, provided complete answers, and split them consistently into easier- and advanced-exercises (following my goal described about exercises). I've also pulled these into a separate file, so it's easier to read them during class without fussing with a big PDF (also a smart suggestion from a former student).
Anyway, I'm proud of the improvements. I've found a few new typos in the classes over the past two weeks, but have been busily squashing those.
If you've been a student of my developer classes (either directly, or when I've subcontracted as a trainer for other companies), and you'd like a copy of my new materials, I'd be happy to send you them. Just let me know.
Portland
I'm in Portland teaching the first-ever Portland Plone Developer Bootcamp. We're in the Portland Buillding, a modernist building designed by Michael Graves (you may know him from his funky design stuff at Target stores). It's a nice space, with great coffee and good catering.
The most fun thing about the space is that in back of the auditorium we're in, there's a to-scale wooden reproduction of downtown Portland, about 15-feet by 20-feet across. It shows all the buildings, from storefronts to skyscrapers, and it's entirely done in machined wood blocks, so, as new buildings get planned, they can "test them out" here first easily, to see how it affects the city. It's very compelling--I think practically every student has spent some of the break time just looking and touching these wooden block buildings.
The sense of community among the Portland Plone people is palpable. Look out, San Francisco--we've got some serious competition up north!
I'm staying with Jon B. from ONE/NW, Plonemeisters extraordinaire, and hosts for the October Plone Conference (Thanks, Jon, for the great place to stay!) Last night, Jon S. and Andrew from ONE/NW came down to meet the class members, and the local Plone users group. Also there were prominent Plonistas like Richard Amerman (fifer in #plone), Aaron Vanderlip (aaronvanderlip, a generous and very cool developer!), and many others.
So, thanks to everyone who came out to Portland, and everyone who's made this possible. It's really been a great week so far.
On Pricing
I've taught a quality, 5-day Plone developer class from anywhere from $150 (heavily subsidized) to $2499 (offered by another company, using me as the trainer). What's the right price?
Of course, many students would answer "the least expensive!", of course. But, consider: if the class is that inexpensive, you'll have fellow students who may not be well-prepared. They don't have much incentive to get serious for class. At the lowest end, companies may send lots of students who want to learn to use Plone rather than build a Plone site--and having many people who aren't web designers or scripters in a developer class isn't fun for those people who are.
There's also the reasonable chance that if you go to free or ultra-low-priced training, the trainer is hoping to make their money elsewhere--usually, from consulting from students. While it's nice to get work from training, if that is a signficant income stream, it can put the trainer in a quandry: do I teach them everything? Do I leave the good stuff out so they hire me later?
On the other hand, the trainer may say the right class cost is "the most expensive--I want to make money!". Sure, I do earn a living partially from teaching. But making the classes on the expensive end also means smaller classes and students who may also not be as prepared as possible--after all, if they're paying you hundreds of dollars a day for your class, they may expect you to do all the installation and trouble-shooting for them. Which, in the end, is less fun for me, and less learning for them.
Very expensive training also reduces the diversity of the students: at $2500, you get mostly larger corporations. Smart people, to be sure, and often great developers. But Plone has a rich ecosystem of users, from tiny startups to established but small nonprofits to large companies to huge governments. I really think they have a lot to teach each other and, from my experience being in the room when it happens, I want to encourage them to meet each other.
So, I've been offering the bootcamps for about $400-500. A great deal, I think, for a week of quality training from an expert (and value is frequently mentioned by my students).
The challenge is that at these prices, my 5-day build-a-site-oriented classes are still less expensive (less than half) of most learn-to-use-Plone classes. And, as such, people who'd gain more from that class often end up in the developer classes.
I'd been thinking of raising my prices, mostly just to discourage these students from buying the wrong class. I worried, though, that higher prices might mean smaller classes which might mean fewer people get to learn, and fewer courses in fewer cities, and the whole magical card building falls down.
Instead, I've decided to start offering a 2-day, how-to-use-Plone class, the "Content Manager Workshop". It covers everything I think you need to know about Plone: adding content, where to put it, understanding metadata, installing products, and how to get help. I developed this class concept initially about 2 years ago, taught it publically at CIGNEX on a contract basis for a year, and still think it's a very valuable offering. I'm offering this first in San Francisco (my home city) and pricing it at $350. Still a great value for 2 days of quality training, half of the competition, and, I hope, priced right, so that everyone can find themselves in the class that makes them happiest.
Let's see how it works.
80% Success Rate?
In the courses I teach, I have exercises after many of the sections. Over the past few weeks, I've been adding more exercises, and evaluating them for appropriateness.
Overall, I try to make sure that the exercises provide:
- practice: they should repeat the things learned in that section, rather than introducing new ideas or testing students' cleverness
- confidence: student should feel more confident at the end of a section, rather than being more impressed with how much there is they could still learn
The latter point is the one I'm re-evaluating things for now.
There's a notion that exercises should "teach" you things and be "challenging". The first time I wrote exercises for courses, years ago, my exercises were about this. Few students completed them. I realized that I had fallen into the trap of assuming that people always want to be challenged.
In fact, spending an hour or two learning new concepts itself is challenging--the exercises should be a chance to repeat what they've learned, to try out their shaky legs on these new skills, and to feel good about what they've learned.
When I was younger, I was a semi-serious chess student. While some people assume that kids and adults should learn chess by studying Grandmaster games and by playing people who will totally tromp all over them, the best chess teacher I ever met had a very different perspective: students learn more when they win about 80% of their games.
A few years ago, my friend's son, Lucien, began to play chess, and I would play with him. Being a young kid against an experienced adult, I could have beaten him every time. I didn't want to do that. I could have played badly, and made bad mistakes. I didn't want to do that, either--he might have assumed these were good moves. So, instead, we invented a new protocol: I would play, seriously, against him. But at any given point, he could opt to switch sides with me. He could learn good skills. He could still have the (important!) effect of feeling like a winner. It worked well.
So, I've been adding lots of hints to the existing exercises, and aiming as my goal that 80% of the students complete the exercises for a section, and that 80% get them right. (Of course, I still keep advanced exercises on the next page, for those students who come, having already learned Plone and Python well, and who want something more challenging to sink their teeth into.)
We'll see how it goes.
Importance of Breaks
I admit: I'm a feedback junkie when it comes to training.
I also happily work as a consultant, but, when I teach, I love getting the immediate feedback in everyone's eyes. I can see who is actively learning, who is connecting the dots between new ideas, and who is quietly puzzling on "how would I use this feature in my site?"
Offering class breaks, then, can be a challenge for me.
Of course, we break so that people can get coffee and use the restroom and ask me questions. I usually time these to be about 7-8 minutes.
After the DC class, I received three different pieces of feedback that all suggested longer breaks.
Longer breaks? But everyone always says that they love learning this stuff, that they want to cover even more, that they wished they could come back for another day, etc.
Plus, in my heart-of-hearts, I know that I sometimes worry that people wanting a long break might mean that they're not engaged or as interested as others are. I expect I'm not the first trainer or teacher to think this.
In a twist of interesting timing, I've been spending most of this week in a hospital: my girlfriend had a bad bike accident, had a head injury, and has been recuperating, slowly, in a trauma unit. While she's expecting a full recovery, one of the possibilities is that she'll have a harder time for a few weeks making short-term memories; her brain may have to "re-learn" the process to do so.
So, I've been reading about memory, and how we make them. It turns out that our brains need several things to make good memories:
- connection: Understanding how this relates to other things. I usually try to address this when I teach by first showing people where they'd use a technology, and then introducing what it is.
- repetition: I often perform the same process several times, with variations, knowing that repetition is a key part of learning.
- quiet: We need frequent periods of rest so that our brain can decide what is useful, try to assimilate it, and move it into our longer-term memories.
The first two are things I'd already learned to do as a trainer; the third is the new one.
So, I need to adjust my thinking: rather than worrying, even semi-consciously, that a long break might mean that people don't want to learn more, or that they might find their GMail checking more interesting than my teaching, I'm resolving to give them frequent, thoughtful breaks to rest and assimiliate.
I teach my next long class at the end of this month, in San Francisco. I'm going to schedule breaks of 15 minutes--almost twice a long as usual.
We'll see how it goes.
In the meantime, here's to making memory.
What Makes a Class Successful?
I've been teaching adults computer skills, in one form or another, for about a decade. I've taught half-day, simple classes on straightforward technologies like Microsoft Word, and I've taught three-week, advanced courses on advanced software development for powerful platforms like Zope and Plone.
One thing that has been constant, though, is that, some classes really "click" for some students, and some classes don't.
What makes a hands-on, adult-student, technology class successful?
I'm going to discuss this in this blog. I teach about twice a month, and get feedback from those courses, but I'd also value any feedback from readers.
