Knowing Things vs. Figuring Out

When I was younger, I told S. that I wanted to be “The guy who knows things.” It sort of became a joke between us: “You know things.” Later, I liked to say that I started out wanting to be someone who knows things, but I ended up someone who can figure things out.

But maybe knowing things is underrated. Sometimes, I can spend more time building up my fixed knowledge. Last night at SF Toastmasters (what my sister calls “speech club”), I gave my second meeting intro as the Sergeant at Arms. From a presentation standpoint, I did a good job. I banged the gavel, and I spoke with enthusiasm. But I forgot a few important pieces of information.

• The meeting will be recorded, but only the Toastmaster’s intro, prepared speeches, and evaluations will be posted on YouTube.

• There will be a five-minute break midway through the meeting.

I have excuses: I arrived at the meeting in a rush, almost late; I didn’t pull up the script because I wanted to get the meeting going. My goal now is to have the SAA script fully memorized so I can do it with an enthusiastic, impromptu demeanor and remember everything. Because the script is short, it is an easy memorization process. From memorizing my humorous speech contest speech, I know it takes 20-30 repetitions to fully memorize a script, so that would take less than an hour.

The fun thing about memorizing a script is that once you’ve done so, you can play with it and make it sound natural. In some ways, a fully memorized script sounds more natural than a truly impromptu speech. Of course, the goal of Toastmasters, or public speaking training in general, is to sound good in both situations.

Memorizing a speech is more like “knowing things,” and improvising a speech is more like “figuring things out.” Although both skills are useful, practicing a skill benefits the practitioner in both improvisational and fully memorized uses of that skill. Nevertheless, different kinds of practice have greater and lesser benefits. Imagine a programmer who spends many years working on a single, particular kind of software, say Ruby on Rails apps’ REST API backends. If the apps are very similar year in and year out, the skills gained through that practice don’t generalize as well as those from doing a bunch of different activities. I’d advise someone like that to branch out and try different roles: frontend, mobile, databases, and different frameworks and languages.

There are so many options that it’s hard to know where to diversify or how to find the greatest growth.

One might say that we have a few different failure modes:

1. Just improvising speeches all the time adds diversity, but I might repeat myself, and what I learn is kind of scattershot.

2. Memorizing one speech helps, but it might limit me because you’re kind of just getting good at that one speech and the areas you’re practicing there. It doesn’t help me if I’m, say, a podcast guest.

3. Working on something like “just Rails REST APIs” limits the learner to getting good at that one area, not programming in general.

4. Having a designed curriculum gives you a balance between all these areas. The learner spends enough time on each thing and doesn’t just study random things, but works towards a defined goal.

Human teachers are helpful for creating this structure, but we need guides with a bigger picture: an education-sized view. That’s what I imagine when I think about learning tech. I imagine a learning assistant that can help the student design the larger curriculum and figure out what to work on day to day. In the study systems I dream of, the student learns things by figuring things out, following a curriculum that promotes intellectual growth.