Knowing and Doing

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.

We can sharpen our tools for other than practical reasons:

I also think that there is a place for sharpening one's tools just for its own sake. Especially as we get older, and our responsibilities increase, anything related to our work can start to feel like a burden. Sometimes even a small amount of time invested in sharpening our tools can bring a bit of joy and restore motivation.
-- Laurence Tratt

I wear my department head hat so many hours a week that sometimes an opportunity to fiddle with my tools is a welcome break. It's not always the most obviously productive use of my time -- with time so precious, shouldn't I use these moments to work on my research project or write Some Serious Code? -- but that bit of joy can sustain me through a lot of dreary time later. That might even make me more productive then. If not? That's okay, too.

~~~~~

Explanations, including documentation for software, really consist of three parts:

Content, then, conveys more than itself. The prefix is reflected in what our explanation takes for granted. The suffix is reflected in what our explanation seems to value; whatever we have today, we'll probably want more tomorrow.
-- Explaining Software Design

When people talk about critical thinking and critical reading, this is what I imagine: As a reader, even of documentation for software, it's worth thinking about what the doc takes for granted and what it says about the values of the writer.

It's also worth thinking about as a writer. This is especially on point as I prepare for the fall semester that looms around the corner. What do my explanations for students take for granted? How will they recognize and deal with what is not written down? What do my explanations say about the things I value, and that I hope they come to value through the course?

~~~~~

The beginning of a new academic year is exciting, and scary, and a lot of work. It's the work we faculty choose to do.

I read one of Tim Bray's recent blog posts this morning and really liked this passage, quoted from a post of his written four years ago:

The observation that computer programmers can build executable abstractions that work but they then have trouble understanding is not new and not surprising. Lots of our code is smarter than we are.

I know this happens to me. I wonder how often something similar happens to my students as they learn techniques and abstractions?

Imagine: They assemble several small pieces of code, each of which they understand individually at least a little, into a bigger program that mostly does what they want — but they have trouble understanding the program as a whole. Further, the size and complexity of the program as a whole makes them begin to doubt their understanding of the individual pieces.

That seems a little far-fetched on its face, but it would explain behavior I see in class all the time. It's a shame when a student who seems to be doing fine begins to lose confidence as the size and complexity of their programs grow. I try to address these growing pains as best I can, but so much of their learning happens away from me, back in their rooms writing code. A few ask for help and stay on track. The ones who don't, struggle and sometimes stop having fun.

If only I can help them see that this is, many ways, the natural order for even the best programmers: We build abstractions that work but which we have trouble understanding.

People like Tim Bray struggle with this, too. You'll be all right.

~~~~~

Wow. I let the entire month of July, and the last ten days of June, pass without posting. That's the first calendar month with a (0) next to it in the blog's archives. My long absence included Knowing and Doing's 20th birthday, July 9, 2004. We should have had a party!

That means July 2024 was the first month of my twenty-first year blogging. Putting up a bagel is not an auspicious start...

I have a few short posts in mind for the coming weeks. Let's see if I can follow through. I like to write here.

One of the downsides of being department head is that much of the daily work I have to do is less interesting to me than studying computer science or writing programs. It's important work, sure, at least most of it, but it's not why I became a computer scientist.

Today, I ended up not doing most of the administrative work I had planned for the day. On the exercise bike this morning, I read the recent Quanta article about a new way to estimate the number of distinct items in a list. My mind craved computing, so I spent some time implementing the algorithm. I still have a bug somewhere, but I'm close.

Any day I get to write code for fun I call a good day. This is important work, too, because it keeps me fresh. I can justify the time practically, because the exercise also gives me raw material for my courses and for research with my undergrads. But the real value is in keeping me alive as a computer scientist.

The good feeling from writing code today is heightened knowing that tomorrow's planned administrative work can't be postponed and is not fun, for tomorrow I must finish up writing annual salary letters. I am fortunate that writing these letters provokes as little stress as possible, because the faculty in my department are all very good and are doing good work. Even so... Salary letters? Ugh.

Thus I take extra pleasure in an absorbing programming process today.

I realized something about myself as a programmer while on a bike ride with my wife this afternoon.

Even though I prefer to write code in small steps and to write tests before (or in parallel with) the code, I have a weakness: If you give me the algorithm for a task in full upfront, and I grok it, I will occasionally implement the entire algorithm upfront, too. Then I end up debugging the program one error at a time, like a caveman.

Today, I succumbed to this tendency without even thinking about it. I am human.

I have posted or re-posted several links on Mastodon recently, after having been mostly silently for a few weeks. Whenever I end up posting a flurry of items, I find myself thinking, "I may want to use these somewhere later..." and realizing that I don't want to rely on Mastodon search to find them. So here a few, for the record (and for the pleasure of those readers who don't follow my social media postings with the tenacity they deserve).

Oneliner-izer https://github.com/csvoss/onelinerizer converts any Python 2 script into a single line of code.

Favorite line from the documentation:
"Never pass up an opportunity to use the Y combinator."

In my programming languages course, we learn how local variables are a syntactic abstraction. If nothing else, I can use this tool to demonstrate translations of simple Python code into their equivalent function applications.

~~~~~

This is from a short blog post on receiving an AI-generated email message from a friend:

The effort, the clumsiness, and the time invested are where humanity is stored.
-- https://mrgan.com/ai-email-from-a-friend/

Then again, I would like this. I still send actual physical cards to many friends and members of my family each year at Christmas, with (short) personalized handwritten notes. I am not always the best of friends, but occasionally I invest a little effort, clumsiness, and time in saying "I'm thinking of you."

~~~~~

It's surveillance wine in safety bottles.
-- https://mastodon.world/@Mer__edith/112535616774247450

I haven't studied the GDPR provision that Whitaker is commenting on, so I have no comment on it directly. But I love this phrase.

~~~~

"But stay lucid, even during office hours."

That's a tough ask some days.

I was pointed in the direction of this Camus quote by a tweet from @DylanoA4. The image he posted ends with this quote, but the passage beginning with it is even more fitting as the set-up for a prof's joke about office hours. Here that is, courtesy of a post on goodreads:

But stay lucid, even during office hours. As soon as we are alone in its presence, strive after the nakedness into which the world rejects us. But above all, in order to be, never try to seem.

Every prof knows the rejection of empty office hours. "Where are all the students who need my help, or my sage advice on life and the burning topics of the day?" we cry, palms upturned. But don't count on using that time for any other task either... Students will arrive when you least expect them. Stay lucid, and strive after the nakedness into which the world rejects us.

All academics become Stoics, or spend their lives raging against the night.

Avdi Grimm sent out an email to one of his lists this week. After describing his daily domestic tasks, which are many, he segues to professional life. I am not a software consultant, but this sounded familiar:

I telepresence into my client team, who I will sit with all day. My title might as well be "mom" here as well; 20% of my contributions leverage my software development career, and the rest of the time I am a source of gentle direction, executive function, organization, and little nudges to stay on target.

There are days when the biggest contribution I make to my students' progress consist of gentle direction and little nudges that have little to do with Racket, programming languages concepts, or compilers. Often what they need most is help staying focused on a given task. Error messages can distract them to the point that they start working on a different problem, when all they really need to do is to figure out what the message means in their specific context. Or encountering an error makes them doubt that they are on the right path, and they start looking for alternative paths, which will only take them farther from a solution.

I don't sit virtually with any students all day, but I do have a few who like to camp out in my office during office hours. They find comfort in having someone there to help them make sense of the feedback they get as they work on code. My function is one part second brain for executive function and one part emotional support. My goal as educator in these encounters is to help them build up their confidence and their thinking habits to the point that they are comfortable working on their own.

I have had colleagues in the past who thought that this kind of work is outside of the role that profs should play. I think, though, that playing this role is one way that we can reach a group of students who might not otherwise succeed in CS at the university level. Almost all of them can learn the material, and eventually they can develop the confidence and thinking habits they need to succeed independently.

So, if being dad or mom for a while helps, I am up for the attempt. I'm glad to know that industry pros like Avdi also find themselves playing this role and are willing to help their clients grow in this way.

Sometimes, speculative fiction seems eerily on the mark:

Montag turned and looked at his wife, who sat in the middle of the parlor talking to an announcer, who in turn was talking to her. "Mrs. Montag," he was saying. This, that, and the other. "Mrs. Montag--" Something else and still another. The converter attachment, which had cost them one hundred dollars, automatically supplied her name whenever the announcer addressed his anonymous audience, leaving a blank where the proper syllables could be filled in. A special spot-wavex-scrambler also caused his televised image, in the area immediately about his lips, to mouth the vowels and consonants beautifully. He was a friend, no doubt of it, a good friend. "Mrs. Montag--now look right here."

"Spot-wavex-scrambler" is a great phrase. Someone should make it a product name.

That is a paragraph from Ray Bradbury's Fahrenheit 451. I was not far into the book before its description of technology used to entertain — distract, occupy, sedate — the population began to seem eerily familiar. It's not what we have now, and there hasn't been anything especially AI-like in the story yet, except perhaps the sinister robot dog at the fire station. But the entertainment tech hits close to the mark. Mildred wears earbuds all the time, listening to her shows or just to white noise.

The timeline isn't perfect, either ("We've started and won two atomic wars since 2022!"), but the timing isn't all that far off. Almost everyone these days is living with a sense of disruption from the events of the last decade or so, including wars, which is in rhythm with the story. The fictional government, I presume, makes people happy by surrounding them, literally, with video and audio entertainment 24/7 — all the better not to think about what's really happening out in the world.

Reading this is eerie for me in another way. I read a lot of Ray Bradbury when I was growing up, and for a long time I thought I had read Fahrenheit 451. But then I wasn't so sure, because I couldn't bring to mind any memory around reading it, let alone any memory of the content. (The latter is common for many books I read in high school.) On my last trip to the library, I checked out a copy in order to fill either the gap in my memory or the gap in my reading.

It's a prescient book. I see why it remains a common text in high school and college lit courses. I look forward to the rest of the story.

This morning, I finished reading How a Script Doctor Found His Own Voice, about screenwriter Scott Frank. Late in the piece, there's a bit on "how difficult it can be to remain relevant as a screenwriter as you age". Frank took caution from the experience of one of his mentors, director Sydney Pollack:

After decades of success making such movies as "Three Days of the Condor" and "Out of Africa", Pollack had "a way of working," Frank said. "And it stopped working." Suddenly, Pollack was out of step. Frank urged him to do "something different, something small, something that's not a love story where they end up together." He even tried to get Pollack to direct his thriller "The Lookout". But Pollack couldn't change. To Frank, the lesson was clear: you can't "just double down on what you used to do." The only way to remain vital is to take chances.

That called to mind something I read earlier in the week, a short blog post by Jessamyn West, on how the intersection of an LLM chatbot tool and a newsletter called "The Soul of a New Machine" made her laugh. She closes with a paragraph that felt familiar:

I'm now what folks might consider later-career. I'm faffing about with this newfangled technological stuff knowing both that it's a big deal and also that I only sort of care about it (at my peril? perhaps.) ....

I, too, am late in my career. As an academic computer scientist, "newfangled technological stuff" is my line of work, but... I can't think of many things less interesting for me to do than figuring out how to prompt an LLM to write code or text for me. My lack of enthusiasm may portend the sort of irrelevance that befell Pollack, but I hope not. Unlike Pollack, I feel no need to double down on what I've always done, and indeed am open to something new. So I'll keep poking around, enjoying what I enjoy, and hope to find a path more like the one Frank followed: taking a different kind of chance.

~~~~~

Postscript: If you think this post seems like an aftershock to a post from the turn of the year, you are not alone. Still searching.

Whatever you think of this post, though, I heartily recommend the New Yorker article on Scott Frank, which was engaging throughout and full of interesting bits on writing, filmmaking, and careers.

In her Conversation with Tyler, scholar Katherine Rundell said something important about the books we give our children:

Children's novels tend to teach the large, uncompromising truths that we hope exist. Things like love will matter, kindness will matter, equality is possible. I think that we express them as truths to children when what they really are are hopes.

This passage immediately brought to mind Marick's Law: In software, anything of the form "X's Law" is better understood by replacing the word "Law" with "Fervent Desire". (More on this law below.)

While comments on different worlds, these two ideas are very much in sync. In software and so many other domains, we coin laws that are really much more expressions of our aspiration. This no less true in how we interact with young people.

We usually think that our job is to teach children the universal truths we have discovered about the world, but what we really teach them is our view of how the world can or should be. We can do that by our example. We can also do that with good books.

But aren't the universal truths in our children's literature true? Sometimes, perhaps, but not all of them are true all of the time, or for all people. When we tell stories, we are describing the world we want for our children, and giving them the hope, and perhaps the gumption, to make our truths truer than we ourselves have been able to.

I found myself reading lots of children's books and YA fiction when my daughters were young: to them, and with them, and on their recommendation. Some of them affected me enough that I quoted them in blog posts. There is so many good books for our youth in the library: honest, relevant to their experiences, aspirational, exemplary. I concur in Rundell's suggestion that adults should read children's fiction occasionally, both for pleasure and "for the unabashed politics of idealism that they have".

More on Marick's Law and Me

I remember posting Marick's Law on this blog in October 2015, when I wanted to share a link to it with Mike Feathers. Brian had tweeted the law in 2009, but a link to a tweet didn't feel right, not at a time when the idealism of the open web was still alive. In my post, I said "This law is too important to be left vulnerable to the vagaries of an internet service, so let's give it a permanent home".

In 2015, the idea that Twitter would take a weird turn, change its name to X, and become a place many of my colleagues don't want to visit anymore seemed far-fetched. Fortunately, Brian's tweet is still there and, at least for now, publicly viewable via redirect. Even so, given the events of the last couple of years, I'm glad I trusted my instincts and gave the law a more home on Knowing and Doing. (Will this blog outlive Twitter?)

The funny thing, though, is that that wasn't its first appearance here. I found the 2015 URL for use in this post by searching for the word "fervent" in my Software category. That search also brought up a Posts of the Day post from April 2009 — the day after Brian tweeted the law. I don't remember that post now, and I guess I didn't remember it in 2015 either.

Sometimes, "Great minds think alike" doesn't require two different people. With a little forgetfulness, they can be Past Me and Current Me.

I was listening to some music from the 1970s yesterday morning while doing some academic bookkeeping. As happens occasionally, the lyrics of one of the songs jerked me out of my bureaucratic trance by echoing my subconscious:

I need to be three men in one
To get my job done
I need a thirty hour day
Two jobs with double pay

I need a man to go to work
A man to stay at home

That's William Bell in his 1977 R&B crossover hit "Tryin' to Love Two" [ YouTube ].

I love only one, truly, but... University work has been unusually busy the last couple of weeks, and now we enter April, which is always a hyperactive month on campus. Add to that regular life — tax season and plans for May travel and wanting to spend time with the one I love — and I empathize with Bell wanting to be two or three people all at once. A doppelgänger to attend all my extra meetings would certainly be welcome some days!

At times like this, though, it's good to remember how lucky I am that this is the biggest predicament I face. So: hello, April.