Tell me about your thought-process, not just your results


While there is a lot of talk about the role of schools on "teaching to think", the reality is far from that ideal. Explaining/exploring/practicing human-thought-process is ignored (and sometimes actively-shunned) in undergraduate and graduate level teaching. This hurts students a lot. Bad memories about my first networking class lurk as I write. The textbook opened by describing the format of TCP and UDP packets in all their gory details before introducing any of the TCP or UDP protocol ideas or even the basic networking concepts/problems. The instructor followed the textbook blankly and used the powerpoint slides that came with the textbook, which apparently did not target a human audience. We were just asked to memorize (learn?) and not to think or question. I really hated the class, and also the networking area as a result. Luckily, my dislike of networking was cured eventually (thanks to the "Elements of Networking Protocols" and "Computer Networking: A Top-Down Approach Featuring the Internet").

Why is this the case in teaching? I think a big part of the answer is laziness. Most instructors are lazy (unmotivated, ill-equipped), so they follow the textbooks. Most textbook writers are also lazy, so they follow the style of technical papers on the subject, which are not student/learner-friendly. Then the question is "Why are the technical papers written that way?". I guess part of the reason is the pretense to appear more formal. This may as well go back to the Bourbaki style of mathematics. Freeman Dyson has this to say about the topic on his "Birds and Frogs" article:
"[The Bourbaki project] changed the style of mathematics for the next fifty years, imposing a logical coherence that did not exist before, and moving the emphasis from concrete examples to abstract generalities. In the Bourbaki scheme of things, mathematics is the abstract structure included in the Bourbaki textbooks. What is not in the textbooks is not mathematics. Concrete examples, since they do not appear in the textbooks, are not mathematics. The Bourbaki program was the extreme expression of the Cartesian style. It narrowed the scope of mathematics by excluding the beautiful flowers that Baconian travelers might collect by the wayside."
The goals of introducing generality and rigor in the Bourbaki process are great but that should not (and does not) imply shunning the presentation of the thought-processes that led to these results. Our job is to communicate to other humans and the goal of formalizing things should be to make things easier to grasp for humans not to obfuscate them.

I have my suspicions that another part of the reason to shun presenting thought-processes in publications is to cover up the tracks of our "lacking" thought-processes and put up a macho face by just presenting our "seemingly perfect" end-results. "- It was hard for me to figure this out, so it should also be hard for the reader to understand." That sounds ridiculous, but I have witnessed similar conversations in a couple of my collaborations when I pleaded to simplify the presentation by explaining our thought-process. In general, theory papers are more prone to commit this sin, and systems papers (good ones) are more thought-process friendly. Unfortunately, most conferences/journals value complexity (rather than simplicity) as a sign of technical depth, and this takes the incentive of explaining the thought-processes behind your work, which might render it as obvious/simplistic.

We all have humble brains; don't let anybody tell you differently. Falling short of superpowers (genius/giftedness), we invent processes/systems to succeed, and the good thing about these processes are they are replicable (unlike being genius/gifted). This is why I argue that explaining thought-processes are very important. The novelist Haruki Murakami comes to mind here. On his book "What I Talk About When I Talk About Running", he says roughly the following. Gifted writers write without effort; everywhere they touch in the ground the water pours. Other writers have to strive (he gives himself as an example); they have to learn to dig wells to get to the water. But when the water dries (inspiration leaves) for the gifted writer (which happens sooner or later), he becomes stuck and clueless because he has not trained for this. On the other hand, under the same situation, the other type of writer knows how to keep going and succeed. This is the reason we should teach our students/audience how to dig wells, and not to rely on occasional strike of insights for success.

Explaining your thought-processes is also great for improving the presentation/exposition of your results. Humans love stories. (I dare you not to get addicted to "This American Life") Tell us stories, and we pay attention and remember them. In my classes (and also in my papers) I tell stories to give the context and motivation for a problem. I let the tension build slowly until I can feel the audience getting excited or troubled with the problem. Then, I talk about strawmen solutions (in the class I encourage the students to come up with these strawmen solutions themselves), and discuss how these fall short of solving the problem. Then it is time for me to introduce the new gleam of insight into the problem, and how the solution follows from that. In short, I try to communicate to fellow humans with humble brains and limited attention-spans like me.

PS: My good friend and colleague Ted Herman has emailed me a link to this beautiful poem after reading the draft of this post which was then titled "Tell me about the journey, not just the destination".

Comments

Popular posts from this blog

Hints for Distributed Systems Design

Learning about distributed systems: where to start?

Making database systems usable

Looming Liability Machines (LLMs)

Foundational distributed systems papers

Advice to the young

Linearizability: A Correctness Condition for Concurrent Objects

Scalable OLTP in the Cloud: What’s the BIG DEAL?

Understanding the Performance Implications of Storage-Disaggregated Databases

Designing Data Intensive Applications (DDIA) Book