Knowing and Doing

First from French writer André Gide, in Le Traité du Narcisse (1892):

Everything has been said before. But since nobody listens we have to keep going back and beginning all over again.

Every teacher knows how Gide feels.

Then from Bruce Springsteen, in a New Yorker interview I've lost track of:

This music has not been heard at this moment, in this place, by these faces. That's why we go out there.

Springsteen said that when asked how he could still sing "Born to Run" with so much energy after decades of performing. I think something similar to myself on many teaching days. I love the thing I am teaching and, even though it's old hat to me, it's new to my students, and I want them to love it, too.

I've always been a sucker for quotes that aren't about teaching, or programming, but could be. Making that sort of connection can motivate me on those days when I need a little pick-up.

But I also realize that making connections to other disciplines is a big part of how we teach or write programs at all. Metaphors are everywhere in both. Consider this line from Zach Tellman in a recent issue of the newsletter about his book in progress, "Explaining Software Design":

The queue is a useful metaphor because it makes us ask useful questions.

We create analogies and metaphors because they help us ask useful questions. They help us see our own objects of study, or own activities, in a new way.

I guess this is my way of saying that I'm okay with my irrational fondness for applying quotes out of context to my own world. Doing so occasionally helps me ask better questions. Even when they don't, I get to smile.

I decided to scratch an itch this afternoon with a trivial bit of code.

My students use a homegrown system to submit their work in my courses. After the assignment is due, I scp the assignment's directory from the server to my machine and add it to the course repository. This directory contains one subdirectory for each student, holding their individual submissions.

I use a few scripts and a couple of manual steps to review student work, write up notes for them, and send them the reviews. Most of the scripts iterate over the subdirectories. For many tasks, it is simplest to assume one subdirectory for each student in the class.

I do all this work on two machines, one at home and one in my office. I use git to keep the repos in sync.

It's always been the case that, for any given assignment, one student might not submit anything. That's not a problem when I'm running my scripts on the same machine where I downloaded the submissions. But on the other machine, which gets the data via a git push or pull, the empty student subdirectories — poof! — disappear. git tracks files, not folders.

I'm sure there is a mechanism somewhere in git for handling this sort of thing (isn't there a mechanism for everything somewhere in git?), but in the past I've done it by hand: I glanced at the subdirectory listing and, when I saw an empty folder x, I typed touch x/_nosubmit. When there is only one empty student folder, this is quick and easy. But as the number of empty student folders goes up, it becomes tedious. Two developments over the last few semesters have driven the tedium to an uncomfortable level.

First, I've noticed that the number of students who miss the initial submission deadline rising. There are a variety of reasons that this is happening. I am happy to work with students who need to submit later, but this means more empty directories when I make my first pass reviewing submissions.

Second, I am trying to give students many more low-stakes opportunities to write code and get feedback. Instead of grading one assignment per week, I may now be evaluating submissions for three different tasks.

Put these two factors together, and I rapidly grew tired of scanning subdirectory listings and touching empty files.

Sounds like time for a new command. At first I tried to do it in a single line of bash, using xargs, but that didn't work. (My intuitions about xargs often fail me.) So I wrote a simple for loop:

    for entry in $(find "$1" -type d -empty)
    do 
        touch "$entry"/_nosubmit
    done

Stash that loop in a file, chmod +x, move it to ~/bin, and the discomfort goes away.

It occurred to me almost immediately that I should have made the name of the file to touch an optional second argument, using _nosubmit, my placeholder of choice, as a default. But you know what? YAGNI. If I ever find myself in need of more flexibility, I'll add a fifth line of code to initialize a FILENAME variable and use its value in the touch line. For now, simpler is good enough.

As I wrote on Mastodon :

Several decades on, I still get a great thrill from writing a four-line shell script to automate a common task.

Simple pleasures for a simple programmer.

Really. Lea Verou mentioned in this blog post that she hopes to write another blog post soon explaining...

How I used web technologies instead of LaTeX to write my PhD thesis (and print it to PDF for submission), with 11ty plus several open source plugins, many of which I wrote, an ecosystem I hope to one day free more people from the tyranny of LaTeX (which was amazing in the 70s, but its ergonomics are now showing their age).

I wrote my Ph.D. dissertation in WordPerfect (yes, I am old). The idea of writing a document as large and complex as a Ph.D. dissertation in HTML and CSS is both intimidating and intriguing, a challenge worth tackling — if only I hadn't already been facing the challenge of completing my research and, you know, writing a dissertation. For me, trying to write a simple midterm or final exam for one of my courses using only HTML and CSS usually results in me banging my head against a surprising number of walls followed by an hour or so of making tedious small changes to the stylesheet to get everything Just Right.

Verou had the advantage of deep expertise in web technologies and having done her research on the same. Even so, I am impressed and may take a peek under the hood of her website to see some of her best tricks.

This reflection is a convenient way for me to preface the fact that I am teaching web development again this fall. As I wrote in an earnest appeal for assistance last spring, this is an introductory course for non-majors, covering HTML, CSS, and a little interactivity using JavaScript. The course went reasonably well the first time around, though my coverage of JavaScript fell flat with most everyone in the class, especially the non-majors. I'm still working on ways to do better when we reach JS in a month or so.

After only a few weeks, though, I have been impressed with my students' eagerness to put their new web knowledge to use. On the first real homework assignment, I asked students to create a web page using a bunch of the HTML elements we had learned. I suggested possible pages they might create but left it open for them to create any page they wanted. As you might imagine, most students like this kind of freedom.

A couple of students wrote fan pages for their favorite musical artists (*). For me, that was shades of 1995. Another student used his assignment to create an instructional guide for the dog walker he and his significant other were hiring. He apologized for creating a page he didn't think I'd care to read, but I was very happy, and told him so.

I remember how much fun I had learning to write HTML back in the early days of the web and then writing all sorts of pages about things that I cared about. That's what knowing how to write can do for you, and knowing how to write for the web means being able to share what you write with anyone who cares to read. My students are using what they're learning to write about things they care about.

That makes me happy. And I think that Verou would be proud, too.

(*) Taylor Swift really is popular... A couple of my students were surprised and a little impressed that I like Swift, too. My daughters and I have bonded over music since they were toddlers, and they love to share their musical interests with Dad. Swift is one of many artists they've turned me on to over the years.

I sometimes half-jokingly tell my students that, whenever they write a new piece of code, they should have at least two alternatives in mind; that way, at least they know they aren't doing the worst possible thing. (They always laugh.) That's an old Kent Beck line, which I memorialized in a blog post many years ago.

It's part joke because it's cold comfort even to experienced programmers, and because students often don't trust themselves to generate alternatives, let alone evaluate their quality. But it's also quite serious, because it can be the first step novices take on the path to becoming a reflective practitioner.

That old story came to mind obliquely yesterday when I saw this Mastodon post by Kent, which ends with:

Next time you hear, "But we have to make this decision *now*!" ask yourself, "What skills would we need in order to *not* have to make this decision until later? How can we learn those skills?"

This seems to be an instance of a question useful to ask oneself more generally. What data, knowledge, tool, or skill would I need to be able to make this decision later?

We shouldn't fetishize postponing decisions, of course. Looking for a reason to wait to make every decision could become a recipe for not making any decisions. Further, this fetish can paralyze novices, who doubt their own abilities to evaluate choices. They can find themselves in a spiral of infinite postponement.

Fortunately, as long as we don't turn this mindset into a pathology, waiting to make a decision is rarely going to be a speed bump to writing programs. There are always plenty of decisions to make, so being able to delay some is a favorable option to have in hand.

In such a world, there is great value to be found in viewing a seemingly forced decision as an opportunity to learn.

It is almost never good to be in a position of having to make a decision right now, to have no alternatives from which to choose. We shouldn't settle for that condition without doing a little work first.

~~~~

Kent has a knack for making me think more deeply with an aphorism or a simple story. I've always admired that. This post is yet another example.