I'm in Poland right now, and I just got back to my apartment after a long day of teaching. I never thought I'd enjoy teaching as much as I do; I've always been a bit of a loner, so standing in front of a group of people was something that I had to work at. But, one thing that I've noticed over the years is that the best way to get interesting insights into an area of design or practice is to teach it. Often when you're in front of a group of people, reaching for an explanation, you find it.
It's not all fun, though. One of the things that I battle constantly is something that I call androgogical challenge. Andragogy is an interesting word. Many people don't realize it, but the root of the word pedagogy is ped, which means children. Andragogy is the corresponding word for the study of adult teaching. Adults learn differently, and some of our quirks, as adults, trip me up.
What are the quirks? Well, one of them is the need to relate to experience. When you're attempting to help people learn something in programming, choice of examples is critical. Unfortunately, it is very hard. If you pick something too easy or too stylized, some people will see it as a "toy example" and "turn off." They can't imagine how it relates to the work that they do. If, on the other hand, you choose something which is very realistic, you can end up with overload. It is hard to highlight the important points in a sea of detail.
So far, I haven't found any set way to tackle this problem, but I know that I constantly have to be aware of it when I teach and when I write. Examples have to be detailed and realistic enough to engage, but also fertile with interesting decision points. But, if you supply too much detail you can end up derailed, dealing with points that don't really have as much bang for the buck. It's a hard balance.
I've found that examples can't be fabricated, and that they have to be harvested from actual projects.
I recently was trying to explain some design patterns (Decorator, I think) using a toy example and it was turning into a mess. So I stopped, thought of the last time I actually used it to solve an actual problem, and it was much better.
Posted by: Martin Cron | July 17, 2007 at 10:36 AM
Martin, yes, the only problem is, as a consultant I have to deal with confidentiality issues. It is true, though, some of the best examples I've come across are rooted in real situations.. but I often have to change the domain to protect the innocent (or guilty) as the case may be.
Posted by: Michael Feathers | July 17, 2007 at 12:46 PM
Bizzare. I have a half finished blog post on this very subject :-)
ages ago I got the book "Telling ain't Training" and I keep revisiting it.
The other aspect to adult training that makes it difficult is that adults want to have input into their learning process. So having a couple of canned problems / examples can be problematic.
I think the rescuing idea is that if you can sell people on the problem you want to solve.
I recently watched http://www.dnrtv.com/default.aspx?showNum=63
where jean-paul boodhoo does a pretty good job of showing some design patterns in a context that a lot of .net developers would probablly relate to.
In the book Telling aint Training there's a nice story of a trainer making up a "meta" story about why a bunch of financial guys should be interested in a pretty boring form.
so I think you can either find relevant stuff or sell the relevance of "toy"s. I dont know which ones harder as I struggle with both
Posted by: Keith Nicholas | July 17, 2007 at 03:39 PM
Keith, thanks. I'll take a look at those references.
Posted by: Michael Feathers | July 18, 2007 at 03:10 PM
when and how. I even don't know why this change.
Posted by: iPhone contacts backup | February 09, 2012 at 11:20 PM