Knowing and Doing

In a conversation with Tyler Cowen, economist Garett Jones said:

... my job in the classroom is not to teach the details of any theory. My job is to give students a reason to feel passionate enough about the topic so that they'll go home for two or three hours and study it on their own.

Perhaps this is a matter of context, but I don't think this assetion is entirely accurate. It might give the wrong impression to the uninitiated by leaving an essential complementary task implicit.

One could read this as saying that the instructor's job is purely one of motivation. Closures! Rah-rah! Get students excited enough to go learn everything about them on the own, and the instructor has succeeded.

If you think that's true, then I can introduce you to many students who have struggled or failed to learn something new despite being excited to learn and putting in a lot of time. They were missing some prerequisite knowledge or didn't have the experience they needed to navigate the complexities of a new area of study. In principle, if they plugged away at it long enough, they would eventually get there, but then why bother having an instructor at all?

So I think that, as instructor, I have two jobs. I do need to motivate students to put in the time and effort they need to study. Learning happens inside the student, and that requires personal study. I also, though, have to help create the conditions under which they can succeed. This involves all sorts of things: giving them essential background, pointing them toward useful resources, helping them practice the skills they'll need to learn effectively, and so on.

Motivation is in some ways a necessary part of the instructor's job. If students don't want to invest time in study and practice, then they will not learn much. But motivation is not sufficient. The instructor must also put the student in position to succeed to learn effectively.

In the middle of an old post about computing an "impossible" integral, John Cook says:

In the artificial world of the calculus classroom, everything works out nicely. And this is a shame.

When I was a student, I probably took comfort in the fact that everything was supposed to work out nicely on the homework we did. There *was* a solution; I just had to find the pattern, or the key that turned the lock. I suspect that I was a good student largely because I was good at finding the patterns, the keys.

It wasn't until I got to grad school that things really changed, and even then course work was typically organized pretty neatly. Research in the lab was very different, of course, and that's where my old skills no longer served me so well.

In university programs in computer science, where many people first learn how to develop software, things tend to work out nicely. That is a shame, too. But it's a tough problem to solve.

In most courses, in particular introductory courses, we create assignments with that have "closed form" solutions, because we want students to practice a specific skill or learn a particular concept. Having a fixed target can be useful in achieving the desired outcomes, especially if we want to help students build confidence in their abilities.

It's important, though, that we eventually take off the training wheels and expose students to messier problems. That's where they have an opportunity to build other important skills they need for solving problems outside the classroom, which aren't designed by a benevolent instructor to have follow a pattern. As Cook says, neat problems can create a false impression that every problem has a simple solution.

Students who go on to use calculus for anything more than artificial homework problems may incorrectly assume they've done something wrong when they encounter an integral in the wild.

CS students need experience writing programs that solve messy problems. In more advanced courses, my colleagues and I all try to extend students' ability to solve less neatly-designed problems, with mixed results.

It's possible to design a coherent curriculum that exposes students to an increasingly messy set of problems, but I don't think many universities do this. One big problem is that doing so requires coordination across many courses, each of which has its own specific content outcomes. There's never enough time, it seems, to teach everything about, say, AI or databases, in the fifteen weeks available. It's easier to be sure that we cover another concept than it is to be sure students take a reliable step along the path from being able to solve elementary problems to being able to solve to the problems they'll find in the wild.

I face this set of competing forces every semester and do my best to strike a balance. It's never easy.

Courses that involve large systems projects are one place where students in my program have a chance to work on a real problem: writing a compiler, an embedded real-time system, or an AI-based system. These courses have closed form solutions of sorts, but the scale and complexity of the problems require students to do more than just apply formulas or find simple patterns.

Many students thrive in these settings. "Finally," they say, "this is a problem worth working on." These students will be fine when they graduate. Other students struggle when they have to do battle for the first time with an unruly language grammar or a set of fussy physical sensors. One of my challenges in my project course is to help this group of students move further along the path from "student doing homework" to "professional solving problems".

That would be a lot easier to do if we more reliably helped students take small steps along that path in their preceding courses. But that, as I've said, is difficult.

This post describes a problem in curriculum design without offering any solutions. I will think more about how I try to balance the forces between neat and messy in my courses, and then share some concrete ideas. If you have any approaches that have worked for you, or suggestions based on your experiences as a student, please email me or send me a message on Twitter. I'd love to learn how to do this better.

I've written a number of posts over the years that circle around this problem in curriculum and instruction. Here are three:

• Problems Are The Thing
• Problem-Based Universities and Other Radical Changes
• The Tension Among Motivation, Real Problems, and Hard Work

I'm re-reading these to see if past me has any ideas for present-day me. Perhaps you will find them interesting, too.

(This is an almost entirely personal entry. If that's not your thing, feel free to move on.)

Last Monday morning, I sat down and wrote a blog entry. It was no big deal, just an observation from some reading I've been doing. A personal note, a throwaway. I'm doing the same this morning.

I'd forgotten how good that can feel, which tells you something about my summer and fall.

Last spring, I wrote that I would be teaching a new course in the fall. I was pretty excited for the change of pace, even if it meant not teaching my compiler course this year, and was already thinking ahead to course content, possible modes of delivery in the face of Covid-19, and textbooks.

Then came summer.

Some of my usual department head tasks, like handling orientation sessions for incoming first-year students, were on the calendar, but the need to conduct them remotely expanded what used to be a few hours of work each week to a few hours each day. (It must have been even worse for the university staff who organize and run orientation!) Uncertainty due to the pandemic and the indecisiveness of upper administration created new work, such as a seemingly endless discussion of fall schedule, class sizes, and room re-allocation.

One of the effects of all this work was that, when August rolled around, I was not much better prepared to teach my class than I had been in May when I solicited everyone's advice.

Once fall semester started, my common refrain in conversations with friends was, "It feels like I'm on a treadmill." As soon as I finished preparing a week's in-class session, I had to prepare the week's online activity. Then there were homework assignments to write, and grade. Or I had to write an exam, or meet with student's to discuss questions or difficulties, made all the more difficult but the stress the pandemic placed on them. I never felt like I could take a day or hour off, and when I did, class was still there in my mind, reminding of all I had to do before another week began and the cycle began again.

That went on for fourteen weeks. I didn't feel out of sorts so much as simply always busy. It would be over soon enough, my rational mind told me.

When the semester ended at Thanksgiving, the treadmill of new work disappeared and all that was left was the grading. I did not rush that work, letting it spread over most of the week and a half I had before grades were due. I figured that it was time to decompress a bit.

After grades were in and I had time to get back to normal, I noticed some odd things happening. First of all I was sleeping a lot: generous naps most days, and a couple of Fridays where I was in bed for ten hours of rest (followed, predictably, by a nap later in the day). I'm no insomniac by nature, but this was much more sleep than I usually take, or need.

My workout data told a tale of change, too. My elliptical and bike performances had been steadily showing the small improvements of increased capability through May or so. They leveled off into the summer months, when I was able to ride outside more with my wife. Then fall started, and my performance levels declined steadily into November. The numbers started to bounce back in December, and I feel as strong as I've felt in a long while.

I guess fall semester hit me harder than I realized.

In most ways, I feel like I'm back to normal now. I guess we will find out next week, when my attention turns to spring semester, both as department head and instructor. At least I get to teach programming languages, where I have a deep collection of session materials in hand and years of thinking and practice to buoy me up. Even with continued uncertainty due to the pandemic, I'm in pretty good shape.

Another effect of the summer and fall was that my already too-infrequent blogging slowed to a trickle. The fate of most blogs is a lack of drama. For me, blogging tends to flag when I am not reading or doing interesting work. The gradual expansion of administrative duties over the last few years has certainly taken its toll. But teaching a new course usually energizes me and leads to more regularly writing here. That didn't happen this fall.

With the semester now over, I have a better sense of the stress I must have been feeling. It affected my sleep, my workouts, and my teaching. It's no surprise that it affected my writing, too.

One of my goals for the coming year is to seek the sort of conscious, intentional awakening of the senses that Gide alludes to the passage quoted by that blog post. I'm also going to pay better attention to the signs that the treadmill is moving too fast. Running faster isn't always the solution.

From Sixty-Four Reasons to Celebrate Paul McCartney, this bit of wisdom that will sound familiar to programmers:

On one of the tapes of studio chatter at Abbey Road you can hear McCartney saying, of something they're working on, "It's complicated now. If we can get it simpler, and then complicate it where it needs to be complicated..."

People talk a lot about making software as simple as possible. The truth is, software sometimes has to be complicated. Some programs perform complex tasks. More importantly, programs these days often interact in complex environments with a lot of dissimilar, distributed components. We cannot avoid complexity.

As McCartney knows about music, the key is to make things as simple as can be and introduce complexity only where it is essential. Programmers face three challenges in this regard:

• learning how to simplify code,
• learning how to add complexity in a minimal, contained fashion, and
• learning how to recognize the subtle boundary between essential simplicity and essential complexity.

I almost said that new programmers face those challenges, but after many years of programming, I feel like I'm still learning how to do all three of these things. I suspect other experienced programmers are still learning, too.

On an unrelated note, another passage in this article spoke to me personally as a programmer. While discussing McCartney's propensity to try new things and to release everything, good and bad, it refers to some of the songs on his most recent album (at that time) as enthusiastically executed misjudgments. I empathize with McCartney. My hard drive is littered with enthusiastically executed misjudgments. And I've never written the software equivalent of "Hey Jude".

McCartney just released a new album this month at the age of 78. The third album in a trilogy conceived and begun in 1970, it has already gone to #1 in three countries. He continues to write, record, and release, and collaborates frequently with today's artists. I can only hope to be enthusiastically producing software, and in tune with the modern tech world, when I am his age.

I make it a point never to believe anything
just because it's widely known to be so.
-- Bill James

A few years ago, a friend was downsizing and sent me his collection of The Bill James Abstract from the 1980s. Every so often I'll pick one up and start reading. This week, I picked up the 1984 issue.

It's baseball, so I enjoy it a lot. My #1 team, the Cincinnati Reds, were in the summer doldrums for most of the 1980s but on their way to a surprising 1990 World Series win. My #2 team, the Detroit Tigers, won it all in 1984, with a performance so dominating that it seemed almost preordained. It's fun to reminisce about those days.

It's even more fascinating to watch the development of the scientific method in a new discipline.

Somewhere near the beginning of the 1984 abstract, James announces the stance that underlies all his work: never believe anything just because everyone else says it's true. Scattered through the book are elaborations of this philosophy. He recognizes that understanding the world of baseball will require time, patience, and revision:

In many cases, I have no clear evidence on the issue, no way of answering the question. ... I guess what I'm saying is that if we start trying to answer these questions now, we'll be able to answer them in a few years. An unfortunate side effect is that I'm probably going to get some of the answers wrong now; not only some of the answers but some of the questions.

Being wrong is par for the course for scientists; perhaps James felt some consolation in that this made him like Charles Darwin. The goal isn't to be right today. It is to be less wrong than yesterday. I love that James tells us that, early in his exploration, even some of the questions he is asking are likely the wrong questions. He will know better after he has collected some data.

James applies his skepticism and meticulous analysis to everything in the game: which players contribute the most offense or defense to the team, and how; how pitching styles affect win probabilities; how managers approach the game. Some things are learned quickly but are rejected by the mainstream. By 1984, for example, James and people like him knew that, on average, sacrifice bunts and most attempts to steal a base reduced the number of runs a team scores, which means that most of them hurt the team more than they help. But many baseball people continued to use them too often tactically and even to build teams around them strategically.

At the time of this issue, James had already developed models for several phenomena in the game, refined them as evidence from new seasons came in, and expanded his analysis into new areas. At each step, he channels his inner scientist: look at some part of the world, think about why it might work the way it does, develop a theory and a mathematical model, test the theory with further observations, and revise. James also loves to share his theories and results with the rest of us.

There is nothing new here, of course. Sabermetrics is everywhere in baseball now, and data analytics have spread to most sports. By now, many people have seen Moneyball (a good movie) or read the Michael Lewis book on which it was based (even better). Even so, it really is cool to read what are in effect diaries recording what James is thinking as he learns how to apply the scientific method to baseball. His work helped move an entire industry into the modern world. The writing reflects the curiosity, careful thinking, and humility that so often lead to the goal of the scientific mind:

... was described perfectly by André Gide on August 8, 1891, long before the digital computer:

More than a month of blanks. Talking of myself bores me. A diary is useful during conscious, intentional, and painful spiritual evolutions. Then you want to know where you stand. But anything I should say now would be harpings on myself. An intimate diary is interesting especially when it records the awakening of ideas; or the awakening of the senses at puberty; or else when you feel yourself to be dying.

There is no longer any drama taking place in me; there is now nothing but a lot of ideas stirred up. There is no need to write myself down on paper.

Of course, Gide kept writing for many years after that moment of doubt. The Journals of André Gide are an entertaining read. I feel seen, as the kids say these days.

Yesterday, I mentioned Barney Stinson's legendary rules for running a marathon. Truly dedicated readers of this blog may remember that I first quoted Barney's rules many moons ago when beginning to run again after a short layoff.

Back then, I blogged a fair bit about running, and especially about the mental connections I made among training, running, teaching, and writing software. Alas, my running life ended rather abruptly when the ultimate effects of an old tennis injury became apparent over a decade later.

October this year brought the tenth anniversary of my final marathon, a beautiful morning spent on the flat streets and trails of Des Moines. Such a momentous anniversary deserved a celebration, or at least a recollection in my blog. However, in the blur of my fall semester, it blew right by me, much like the fastest runners on the course that morning.

I did not completely forget the anniversary. Several months ago, it came to mind, and at the time I made a mental note to write a retrospective blog post. Few readers would care enough to read such a post, but this would be for me, a way to remember so many fond moments on the road and to mourn again, ever so briefly, something I lost.

I should have set an alert in my calendar app.

If this were a wedding anniversary, a spouse might have reminded me, but this was all on me. (I say "might" there because my own spouse is not the sort to valorize anniversaries and birthdays.) Like so much blogging not done in the last year or so, the post I intended to write turned out to be vaporware.

Here, on a beautiful sunny morning seven weeks later, I don't feel much need to write about that last marathon again. Running is no longer a part of my day, my life, though occasionally it is still part of my dreams at night. Some days, I miss it more than others. Perhaps the next time I feel that longing, I'll sit down immediately and write, rather than plan to write some months on. That's the best way for me to blog: to try to capture a thought or feeling in the moment and make sense of it then.

On a completely unrelated note: While looking in my blog's image library for the picture posted above, I realized that the date of my last marathon, 10-20-2010, is a palindrome of sorts: 10 20 20 10. I love to play with digits and feel no compulsion to hew closely to dictionary definitions when it comes to the patterns I see. Numbers offer small joys in most moments, if we let them.

In a not-too-distant post, Daniel Steinberg offered two lessons from his experience knitting:

So lesson one is to start and lesson two is to keep going.

This reminded me of Barney Stinson's rules for running a marathon (10s video):

Here's how you run a marathon.

Step 1: Start running.

<pause>

Oh, yeah -- there's no Step 2.

Daniel offers more lessons, though, including Lesson Three: Ask for help. After running the New York Marathon with no training, Barney learned this lesson the hard way. Several hours after the marathon, he found that he no longer had control of his legs, got stuck on the subway because he could not stand up on his own, and had to call the gang for help.

I benefit a lot from reading Daniel's blog posts, and Barney probably could have, too. We're all better off now that Daniel is writing for his blogs and newsletters regularly again. They are full of good stories, interesting links, and plenty of software wisdom.