Sort of Invented Here
My work with Lullabot involves a lot of teaching and training. We've invested a lot f time and resources in becoming experts, but there's more demand than we can fill: as such, "teaching people to fish" has been part of the company's mission since it was formed.
We've been really fortunate, in that all of the Lullabots have been passionate, eager folks who love sharing their knowledge. We've all had a lot of opportunities to collaborate on how to best train others to use Drupal, and we've gotten a lot of experience under our belts over the years. This year, we've been working on taking things up a notch by hiring more dedicated trainers, building more curriculum to cover additional topics, and making it easier to customize the kinds of courses we're able to give. Being a huge fan of systems -- I couldn't resist the opportunity to jump in and work on it!
It's been a really fascinating opportunity both to improve the work that we do, and to learn about the existing science of curriculum design and education. @emmajanedotnet's recommendation of Developing Technical Training: Third Edition was worth its weight in gold, for example. That book perfectly captures a lot of key ideas that we've iterated our way into, but gives them context and supporting structure. Is it Chomsky who says we can't really understand a concept until we have some way of expressing it in language? This book gets me over the language hurdle, offering an existing conceptual framework for describing and building curriculum so I don't have to hash my way through that process. Instead, I can focus on the curriculum itself: the real meat of what we're great at. Yum!
The whole process has me thinking about times in my life where I've missed out on opportunities to learn from others' experience. I like to think that I'm a creative person, and like most software developers I enjoy building new stuff from scratch. That can easily lead to a sort of de facto "Not Invented Here" syndrome, where existing solutions aren't rejected so much as they're never even noticed.
I'm reminded of Robert Prisig's classic (and often-snarked-at) book Zen and the Art of Motorcycle Maintenance. Some of my favorite parts of the book are about the difficulties of teaching complex and nuanced subjects -- explaining the idea of Quality to writing students started Pirsig on an epic philosophical quest. He agonized, sacrificed, even alienated his loved ones in an attempt to figure out some really complex and difficult questions. In the book, he looks back on certain parts of that process ruefully: he spent a lot of time thinking that he was charting new ground, and years later discovered that he was only rehashing what other philosophers had done far earlier.
He viewed it (if I remember correctly) as a sort of "freshman error," a mild narcissism that can blind us to the fact that there are many other very smart people trying to figure things out -- that we're probably not the first ones to grapple with a particular problem. That resonated deeply with me: I've gone through the same epiphany/forehead-slapping cycle myself. "Aha! I'm a genius! Oh, wait... someone else figured that out a hundred years ago, and wrote a book about it." The flip side, of course, is that the process of grappling with a complex problem is its own kind of learning. Jogging, by analogy, isn't just about moving from one place to the next: a car would be more efficient, but wouldn't build muscle.
I'm trying to explore a middle ground in my life these days. When faced with interesting and complicated problems, I enjoy diving in and trying to figure things out myself. But I need to pull in outside knowledge as well, and do it early rather than late in the process. That doesn't mean I can't do the work myself, but at the very least it keeps the ego in check. There are smart people out there, it reminds me, and they always have insights to offer.
An exercise in learning, and humility
There's an interesting discussion going on at MetaFilter about confused Internet users and the mistakes they make. It's full of laughs and full of arguments about iPads and Google and UX work, but one comment stood out to me:
"...How hard is it to understand what a browser is and what a URL is and how to use a search engine?"
The answer, in my opinion, is "Really, really really hard." The problem isn't that those individual things are tough to tell apart, or that a "menu" is inherently confusing or that it takes too many steps to copy a folder from one disk to another or anything like that.
The problem, at the end of the day, is that learning to use a computer is something like learning a complex new language. There there are thousands of little things to learn that are both subtle and irrelevant. Irrelevant, that is, until the moment they're important. And at just that moment, the fact that think a "Bookmark" and a "URL" are the same thing will cause you a world of pain.
The longer we spend with computers, the more difficult it is to capture that "beginner's mind" when communicating with others. One exercise that I've found useful is the simple act of writing out an explanation of a computer-related concept. That sounds easy, but there's a twist: if your explanation refers to other computer-related concepts, you have to explain them, as well. In addition, if your explanation glosses over important distinctions that could confuse the listener later, you have to note it.
"A web browser is a program that lets you look at information on other computers around the world."
What kind of information? ("Well, technically HTML files...") Can a web browser look at movies? ("Sure, as long as you have a plugin--") Wait, what's a "plugin?" ("It's another program that plays movies inside the browser.") My nephew told me Youtube doesn't need that. ("Only if you're in the HTML5 beta!") I don't think I am. Can other people look at information on my computer with a browser? ("No.") My nephew said I could look at his computer with it. ("Oh, well, he might have a server on his.") What's a server? ("Do you mean a computer that's a server, or a program that's a server?")
You can see where that's headed. The closest most computer experts get to this kind of disorientation is when they learn a new language, framework, or toolset. All of their old mental models turn to baggage, and they have to carefully feel out every answer for hidden assumptions.
The idea behind the exercise isn't to follow an infinitely deep rabbit hole while writing a simple explanation. Often, quick summaries are useful because they give people some important mental anchors. The important part is to remember just how immense the cloud of supporting ideas is -- and to have patience when talking to people who haven't yet absorbed enough to know what they need to know.
CMS Expo 2010: It's like a clown car full of Drupal!
Last year I had the privilege of speaking at the Chicago CMS Expo, a yearly event that brings together experts from a variety of open source communities for learning and collaboration. In 2009, Joomla!, Drupal, and Plone folks had some great training and education tracks as well as interesting business sessions for the suits.
This year, WordPress has been added to the mix and the Drupal track features quite a few community luminaries. I'll be there in May along with Larry Garfield and Colleen Carrol of Palantir; Emma Jane Hobgin, co-author of Front End Drupal; Doug Vann and Matthew Lechleider; and Volacci's Ben Finklea. I've also heard a few rumors that a big name in the Drupal universe will be talking about the future direction of the platform... The list is pretty impressive and I'm looking forward to connecting, teaching, and hanging out with folks from various CMS communities.
If you're in the area and are interested in kicking various platforms' tires, it's one of the few events where you can hear experts from several CMS communities, rather than a few token visitors at an event dominated by one product. In addition, CMS Expo's banners are a pleasant, soothing shade of aqua. Check it out!
