The Practice
Pairing
A lot of arts education follows the "guild model", where skills are taught by a master to an apprentice. In composition classes, I had weekly one-on-one meetings with my professor — something that has a direct correlate in pair programming. While on the surface both mainly serve to move a certain piece or feature forward, I contend that they primarily hone perception.
The value isn't just in the code produced during a pairing session — it's in the calibration of your own reading and judgment. You absorb how someone else navigates a problem, what they notice first, which tradeoffs they weigh. Over time, these sessions compound into a richer internal model of what "good" looks like.
Rehearsal
There's an ongoing debate around learning design patterns and algorithms. I contend that repeated exposure and experience creates cognitive structures that theoretical knowledge alone cannot develop. While memorization isn't necessary, familiarity with these concepts enables practitioners to recognize patterns intuitively.
Think of a musician rehearsing scales. No one performs scales on stage — but the muscle memory and tonal awareness they build become the foundation for improvisation. The same applies to code: rehearsing fundamentals creates the substrate for creative problem-solving under pressure.
Reduce, Reduce, Reduce
A core principle: favor simplicity over complexity. Rich Hickey's distinction between "simple" and "easy" is instructive here. Consider a sound engineering analogy: adding multiple effects plugins to a signal chain creates cumulative noise. Each plugin introduces artifacts, and the more you stack, the further you drift from the original signal.
The equivalent software practice involves minimizing code initially — use a Struct before reaching for a class, leverage existing methods creatively, and remove unnecessary abstractions. Maybe you can delegate some method calls up the stack. A little code golfing sometimes goes a long way. The cleanest code is often the code you didn't write.
Finally, let me plug a short post written by Nate Hopkins, one of my mentors: Less > More.
AI's Role
Rather than replacing human creativity, AI functions as a significant quasi-other — a resource for inspiration and feedback within creative problem-solving, not a replacement for the engaging challenge of building software.
The deep satisfaction of programming comes from the struggle with a problem, the moment of insight, the craft of expressing a solution elegantly. AI can accelerate parts of this process, but it cannot replicate the understanding that emerges from having done the work yourself.