Tuesday, December 30, 2008

Learning How?

I wrote yesterday about lists - how I keep 'em, where I keep 'em, where I wish I could keep 'em. And immediately I got a couple of comments suggesting mind maps. Glenn in particular mentioned that he used mind maps both for a "to do" list of sorts and also to help him assimilate new information.

Which got me to thinking.... there's a lot of new information out there. So how do I learn? And how do I help my team members learn?

This can be a flow diagram, a state diagram, a deployment diagram, whatever. It's a picture, and it's a picture of how the system works. I learn best if a diagram is constructed in front of me - that way I can follow along as it evolves. In my head, I can actually see the bits move through the system like I'm watching a movie (literally, in my head an HL7 message comes in a cute little envelope in kind of an off-white stationary).

One guy on my team uses diagrams, too. He goes about it differently, though. He likes the whole diagram at once, and then he just... assimilates it. I have no idea what's going through his head.

Okay, this one my team laughs at me for. I love using analogies, particularly when I'm dealing with people who aren't deep in the system. For example, if I have to explain a technical concept (say, why a system turns a node off when it detects multiple correctable memory errors) to a sales guy, I'll use an analogy. I could explain what a correctable memory error is, and then cite the research showing that correctable memory errors are followed by uncorrectable memory errors X% of the time, and then mention that an uncorrectable memory error may indicate data loss.... (watch the eyes glaze over). Or I could simply say that the uncorrectable memory error is like the check engine light in your car. Your engine hasn't failed, but that check engine light is an indicator that something's failing, and it's better to get it checked out than to simply keep going and wind up broken down at the side of the road. The correctable memory error is our check engine light, and turning the node off is our system's way of getting it to our mechanic - the support team.

I don't know if analogies actually help other people as much as they do me, but I find it a useful way to relate what's going on in a system to something that people already understand. It misses some details but can give a good idea of the basics of what's going on.

Verbal Explanation
Okay, I'll say straight up that this just doesn't do it for me. But some people on my team really get stuff when we talk through it. For this to work, though, feedback and repetition throughout are important. Don't go into a 10 minute spiel. Go through 2 minutes of explanation, then get confirmation from whoever you're talking to that it sunk in. Get that person to repeat the information back in his own words.

Written Explanation
This style works better for me than talking through something. I like it list-like, though. Here's idea A. We get here from B or from E, and from here we could go to C or D or F, or we could repeat A. This written explanation also has a major advantage - it can be passed along indefinitely without having to have the one-on-one contact of teacher and learner.

Do It With Tutor
This is what pairing really promises to provide. Let's not talk about it, let's do it. The gotcha with this one is that I've only ever seen it work if the person doing the learning is the person driving the keyboard (or doing the action). Otherwise it's way too easy to gloss over a step.

Hands down, this is the best tool for learning to do things that I know. It obviously works less well for abstract concepts, but it's great for the "how do I replace a hard drive?" or "how do I create an SSH tunnel?" problems.

In the end, how you learn and how you teach are two things that are going to be driven by whoever's doing the learning. Having lots of different ways to approach a problem, though, and being able to switch between methods only increases your chance of success.

No comments:

Post a Comment