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. 

8 Responses to “Learning”

  1. Josh says:

    I couldn’t agree more. I also find that a lot of my best research ideas come during writing up results for conferences or journals. The clarity required to concisely explain past work makes the next steps clearer too.

  2. Ben says:

    Interesting observations. In the Pragmatic Programmer, they talk about something analogous to your teddy bear example, except they recommend a rubber duck. :)

    I do feel somewhat torn over automating methods, though. This is a simplistic example, but suppose in an undergraduate reinforced concrete or steel design course, you wrote scripts that automate all the design checks for a given member type. You have to go deep in the spec to capture all the gotchas, and will presumably rely on that script from that point forward. On the one hand, I learned a lot taking the time to automate it, but on the other, I only went deep into the ideas once, when I programmed it. Perhaps I don’t actually understand it as well as I would if I practiced it by hand more? But perhaps I understand it better by writing the logic in a general, executable way? I lean toward the latter (i.e. I agree with your point).

  3. Carl says:

    I’ve heard in medicine the slogan is “see one, do one, teach one.” I’d agree that you can’t claim to know it until you can teach it.

  4. Dr. Drang says:

    Ben, just so you’re not aghast at my teaching methods, I only brought out the FOSM flowchart after I’d taught all the techniques (and the reasons for them) individually.

    Also, this was before every student had a PC. My program ran on a CDC Cyber 175 mainframe. The students never saw it.

  5. Ben says:

    I’m not aghast at anything above; it just got me thinking about some things I’m already pondering regarding our undergrads and how much we should encourage them to write scripts. I’ve been arguing that our engineering undergrads should hit the job with a directory of their own, home-baked design/analysis scripts and wonder if that’s a good thing from a pedagogical point of view. Different discussion, though—-my bad.

  6. Clark says:

    This is a great truth that applies to students too. The classes I did best in were those where we found the student struggling most in the class and brought them into our study group. If we could teach the subject so that they could understand then we would fully understand it. The greatest self-deception is thinking you know something when you don’t really comprehend it. Yet that’s a natural mistake to make. It’s easy to feel like you intuitively understand something only to find when it’s in a different form you don’t. When teaching someone struggling it you have to understand it so well that you understand all the nuances. It’s the same teaching things.

    Even Feynman learned tons doing simple undergrad stuff. He had a ‘writer’s’ block and was burnt out. While he’s probably exaggerating (as he tended to do) he says that he broke out of it and regained his love of physics by just figuring out the mechanics of falling plates from the lunch room and understanding how they moved. He attributes his break through in QED to this (although honestly I still haven’t quite figured the mathematical relation between the two out except in really broad strokes)

    I suspect that making sure people teach in different areas often allows them to think through old problems in new ways. It’s constantly amazing to me how many profs hate teaching. (Not that I’m a professor so I probably shouldn’t be saying much, but most of my friends are and my dad was so I’m not exactly cut off from it all)

  7. Allen MacKenzie says:

    Nice post.

    My advisor always said the thing about “the best way to learn a topic was to sign up to teach it.” Strangely, perhaps, I’ve never heard it from any of my colleagues.

    And while I agree about the programming, the bit about writing at the end of the post is also critical. I tell my graduate students this all the time, to the point that they are tired of hearing it. You can give me an oral status report on what you are doing every week for the next three and a half years. But you won’t really know what you’ve done (and, in many cases, I won’t really be able to critique it properly) until you write it up.

  8. Tracy McKibben (RealSQLGuy) says:

    This is one of the reasons that I’m going to start conducting trainings for our in-house developers, first one is next week. SQL Server is my bread-and-butter, and I’ve become too “comfortable” with what I know. Teaching it to somebody else will help reveal the gaps in my own knowledge. In turn, this will push me to go deeper into the product. Those developers win by becoming better SQL developers, and I win by becoming a better DBA, a better writer, a better speaker, a better mentor.