I spent last weekend at a small retreat led by Don Pedi, an expert in traditional fiddle tunes played on mountain dulcimer. (See References.) We spent about three days doing a little tai chi, learning traditional tunes, asking questions, jamming, and just hanging out together. (Yes, I wore my masks and kept my distance.)
I don’t want to strain for analogies, but some things about Don’s expertise struck me as relevant to us in the software trade. (All this is my interpretation – you’d have to talk to him to see if he agrees.)
Learning is Iterative
How do you learn anything? For musicians, it’s iterative. Listen to a tune. Hum along. Play the rhythm without worrying about pitches. Identify some key notes or phrases. Listen for patterns, and be ready to use what you know. Learn where the variations are. Learn the basics, then make it fancier.
Do this enough, and parts get automatic. I’ve gotten better at recognizing scale fragments, chord outlines, and 3-note phrases. People who’ve learned enough tunes hear lots of patterns, and that makes it easier for them to learn the next one.
These same learning patterns apply in software, for both individuals and team. In effect, it’s the whole basis of evolutionary approaches: start from a broad outline, work out the important parts first, and fill in the rest as we learn.
Expertise in Fine Distinctions
Experts often make distinctions. In music, this may mean knowing many versions of a tune, or how the music is altered to match each verse.
We make distinctions in software too – code smells, refactorings, design patterns, architectural styles, etc. One of the things that most struck me from the early work in design patterns was how naming a pattern could let us study it much more intently.
The Importance of Context
Don Pedi knows a lot of tunes. I’m sure he’d like for lots of people to know and play these tunes.
In dulcimer world, many people play by reading “tab”. Tablature is a way of notating music for fretted instruments: for each string, tell which fret numbers are played at any moment. This differs from traditional music notation – tab is easier to read, but reveals less about the chords or structure.
You might think the best way to get Don’s tunes out there would be for him to write down the tab and/or make recordings. And Don does both those things, but knows their limitations.
For him, tab or a recording is too static – a beautiful butterfly pinned to a board. Tab and recordings strip the music from its context, and the music loses something essential.
Instead, music can be learned in small bits. It can be a legacy, handed down to people who treasure it. It’s kept alive by being played, not by being locked into some medium. It’s kept alive with memory and stories – “I got this tune from __ of Viper KY in 1982 when he was 93 years old. He learned it when he was 6, from his father. You can see how similar it is to this other version I first heard in Virginia.”
There are musical nuances too. Musicians don’t give a metronome-like performance. Instead, tunes have their own rhythms, their own pauses and quirks that are never captured in notation, and variations that aren’t captured in recordings.
If Don had to choose between tunes being popularized through tab, with the context lost and the rough edges smoothed, versus a much smaller group that shares the original tune in community, I’m pretty sure he’d pick the latter.
Context in Software
Mike @geepawhill talks about the importance of context in software. He describes the triad of Makers, Making, and Made, where the Made is the software. (See References.) Software and other artifacts are only a part of the story. If you ignore the needs and behaviors of Makers and Making, you’re working in an impoverished context – and likely to struggle more because of that.
Lately, I’ve been refactoring some retro code on Twitch. The code is stripped from its context – for machines that haven’t been made in decades, nobody is working on it, and understanding it requires digging up 40-year-old books and magazines. Doing this is fun – it teaches me things and keeps me out of the sudoku halls – but it’s not productive. The lack of context makes everything harder. It’s not a good way to develop new software!
Conclusion
Inspired by the retreat, and trying to learn Don’s perspective, I’m reminded of three lessons about software:
- Learning is iterative, for individuals and teams.
- Fine distinctions make learning and work easier.
- If you focus on the artifact and ignore the context, you’re losing something essential.
References
“Re-Balancing Made, Making, and Makers”, by Mike @geepawhill. Retrieved 2021-09-21.
“Spotlight on BPR Music Host and Dulcimer Master Don Pedi“, by Abby Bishop and Catherine Komp. Retrieved 2021-09-21.