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.