Next post Previous post

Learning

January 19, 2012 at 1:17 PM by Dr. Drang

Many years ago when I was a new faculty member, the older guys in the department would tell us youngsters that the best way to learn a topic was to sign up to teach it. They were right. Over the years, I’ve learned some important corollaries to that rule of thumb.

Before I go any further, I want to forestall a couple of objections you may have:

Their point, of course, was that teaching a topic forces you to think more about it than you would have previously. When you’re preparing lecture notes, you have to consider how your students will react to what you’re saying, what questions they’ll have, and how they’ll be able to tie this subject in with what they’ve learned in previous classes. This brings you to a greater level of understanding than you have as a student or even as a practitioner.1

I’d run across a similar thing a few years earlier in grad school. I was doing a series of first-order, second moment (FOSM) reliability problems and wanted to write a program that could whip through all of them in short order. I’ll spare you the details, but the technique for doing these problems depended on the nature of the problem: Was the problem linear or nonlinear? Were the random variables Gaussian or non-Gaussian? Were the variables correlated or uncorrelated? I’d been solving these kinds of problems by hand successfully for some time, but when I had to sit down and write a program to solve them, I had to think more clearly than ever before about which techniques I used, the order in which I used them, and the minimum information required to arrive at a solution.

The FOSM program worked, but I didn’t use it nearly as much as I thought I would. An unexpected benefit of having written it, though, was that when I later had to teach FOSM, I had a nice set of algorithms and flow charts to pass along to my students. Programming is like teaching in that you’re giving instructions. The instructions usually have to be more explicit than those you give the average undergraduate, but the upside is that you only have to tell the computer once.

I once read about another programming/teaching experience that seems apropos. At some university’s computer lab, where teaching assistants had regular hours to help students with their programming homework, a teddy bear was given its own desk. If you went there for help, you were required to explain the problem you were having to the teddy bear before you went to a TA. They found that students who took this seriously and gave a clear explanation of their problem to the teddy bear usually recognized what they’d been doing wrong and didn’t need the TA. The system was both pedagogically superior and a time saver.

Today, I’m out of the teaching game but I still do a lot of writing, explaining the results of my consulting work in reports to my clients. I find that although I gather all the facts during equipment inspections, tests, and analyses, it’s the process of writing my report that brings all the facts together into a coherent whole—it’s when I really learn what I’ve done.

This isn’t to say I sit down at my keyboard to write a report without a thought in my head. I always know what I’m going to write, in general terms at least. But invariably there are details that I hadn’t thought through fully. Writing up an explanation forces me to think hard about those details and solidify the squishy ideas that form during the data gathering phase.

It’s easy to tell yourself that you’ve thought something through, but there’s nothing like explaining it to someone else to put that to the test, whether that someone is a person, a computer, or a sheet of paper.

  1. In my case, “practitioner” means “engineer,” but the principle is the same for physician, lawyers, accountants, programmers, etc. ↩

Next post Previous post