I wrote the following in a SIGAVDI newsletter many years ago:
The other day I wrote some Ruby code to emulate the UNIX which command. Afterward, I started composing a RubyTapas episode explaining the implantation.
There were some points worth noting in the code, and I think it’ll make a solid episode. But as I was writing it, I realized that I was leaving out the parts that a lot of my viewers would probably most like to see.
Sometimes I watch videos of masters on tasks I have no skill at, like electronic music composition, or graphic design. The questions that are most often in my mind are not “how did you do that?”, but: “how did you know to do that?”
I can see (or hear) that the result is agreeable. But how were they aware that that decision they made was even available to them? How did that choice become a part of their repertoire in the first place? And what forces led them to choose it over all the other possibilities?
In the case of my episode script: sure, I could demonstrate how to use the PathExt environment variable to correctly identify all executable file extensions on a Windows host. And I could look like an all-knowing guru for being aware that PathExt is a thing.
But how was I reminded that it was a thing in the first place? Because (spoiler alert) at the outset of my work, I had forgotten all about it. How did I quickly re-educate myself in the nuances of Windows pathfinding?
In my experience, these are the questions that intermediate programmers are thirsting to get answers for. They don’t so much want to know the things that the masters know. They want to understand how the masters think. How do they get from point A to point B?
And this is the part that is so often neglected in training. Because it’s hard. Because reflection doesn’t always come naturally. We sink into a “flow state” and lightning strikes, and only in retrospect do we try to tease apart the train of thought that led to the miracle.
Just as an example: I’ve realized that when I’m studying a problem, I rely a lot on “second-order Googling”. That’s a process whereby I don’t try to discover a solution in a single search. Instead, in my first few searches, I just try to find other people talking about the problem area, using my own naïve description of the task at hand.
Then, once I discover some conversations that are taking place among people experienced in that domain, I read over them looking for the specific terminology that I had missed. Once I have the terminology, I’m able to use it to compose much more focused searches that usually lead me directly to the answer I’m looking for.
But I don’t always realize consciously that this is what I’m doing. It just sort of happens, and anyone who tunes in at the end would ask: OK, but how did you know to google those terms?
In order to better capture the thought process, I’ve been experimenting with recording myself coding live, with no prep and no script. But it’s still surprisingly difficult to convey the thought process that leads to a particular decision. Maybe I ought to have a coding partner whose defined job is simply to ask “wait, what just happened?” every 5 minutes.
Revisiting these thoughts in 2025, I’m pondering what I’ve gathered since then. Here’s what comes to mind:
- I’ve learned not to bother with trying to show the process alone. There is really no substitute for someone sitting next to you (physically or virtually) saying “wait, what did you just do?”
- If you’re pair-programming and you’re the junior in the dynamic (whether by age, or by experience with a specific technology), please don’t be shy to ask “how did you know to do that?”. It’s one of the most valuable ways you can add to the session, for both you and your senior partner.
- For my money, helping “find the words” is one of the most truly useful things generative AI / LLMs have brought to the table. These days I often turn to Claude to help me find the right general terms of art for a process, and then I can do the rest of the research on my own.