Knowing and Doing

Yesterday someone retweeted this message from Hillel Wayne into my timeline:

A surprising and undervalued aspect of mastery comes from narrow-scope "microskills". In software, these would be things like

- Python list comprehensions
- Grep flags
- Debugging specific error messages
- Using a window manager

We can, and should, do targeted training.

Later in the short thread, Hillel says something that brought my students to mind:

In other words, the high level thinking is the difference between a task being possible and impossible, but the microskills are the difference between a task being 20 minutes and six hours. That's why it can take us days to find the right one-liner.

Some students love to program and look for every opportunity to write code. These students develop a satchelful of microskills, usually far behind what we could every teach them or expose them to in class. They tend to do fine on the programming assignments we give in class.

Other students complain that a programming assignment I gave them, intended as a one-hour practice session, took them eight or ten hours. My first reaction is usually to encourage them never to spin their wheels that long without asking me a question. I want them to develop grit, but usually that kind of wheel spinning is a sign that they may be missing a key idea or piece of information. I'd like to help them get moving sooner.

There is another reason, though, that many of these students spin their wheels. For a variety of reasons, they program only when they are required by a class. They are ambivalent about programming, either because they don't find it as interesting as their peers or because they don't enjoy the grind of working in the trenches yet. I say "yet" because one of the ways we all come to enjoy the grind is... to grind away! That's how we develop the microskills Hillel is talking about, which turn a six-hour task into a 20-minute task, or a disappointing one-hour experience with a homework problem into a five-minute joy.

Students who have yet to experience the power of microskills are prone to underestimate their value. That makes it less enjoyable to practice programming, which makes it hard to develop new skills. It's a self-reinforcing loop, and not the kind we want to encourage in our students.

Even after all these years in the classroom, I still struggle to find ways to help my students practice programming skills in a steady, reliable way. Designing engaging problems to work on helps. So does letting students choose the problems they work on, which works better in some courses than others. Ultimately, though, I think what works best is to develop as much of a personal relationship with each student as possible. This creates a condition in which they are more inclined to ask for help when they need it and to trust suggestions from that sound a little crazy to the beginner's mind.

I am teaching my compiler development course this semester, which means that I am working with students near the end of their time with us, whose habits are deeply ingrained from previous courses. The ones who don't already possess a few of the microskills they need are struggling as the task of writing a parser or semantic checker or code generator stretches out like an endless desert before them.

Next semester, I teach my programming languages course and have the joy of introducing my students to Racket and functional programming. This essay me already thinking of how I can help my students develop some of the microskills they will want and need in the course and beyond. Perhaps a more explicit focus early on the use Dr. Racket to create, run, test, and debug code can set them up for a more enjoyable experience later in the course -- and help put them on a virtuous self-reinforcing loop developing skills and using them to enjoy the next bit of learning they do.

It's been another one of those months when I think about blogging a lot but never set aside time to write. Rather than wait for the time to finish a piece I'm writing, about the process of writing a demo code generator for my compiler students, I thought I'd drop a few tidbits now, just for fun. Maybe that will break the ice for writing this holiday week.

• Two possible titles for my next blog: Dear Crazy Future Eugene and Eugene Wallingford's Descent Into Madness. (Hey to Sheldon Cooper.)

• A nice quote from one of my daughters' alumni magazines: A biology major who is now an executive at a nonprofit agency was asked about the value of having majored in science.

When science is taught the right way, she said, "it is relevant in just about every situation".

Everyone can benefit from thinking like a scientist, and feeling comfortable with that mode of thinking. (Hey to Chad Orzel and Eureka: Discovering Your Inner Scientist.)

• Dan Wang on the US's ability to be a manufacturer of batteries:

Batteries are hard to ship and tend to be developed for particular automakers. So they're made close to the site of auto assembly. The US could be a big battery maker if only it built the charging network and offered subsidies on the scale of Europe and China, it's not hard.

The worlds of manufacturing and big industry are different in fundamental ways from software. I learn a lot from Wang's deep dives into process knowledge and investment. A lot of his ideas apply to software, too.