“If you fail in copying from a master you succeed in birthing an original art”, Kushal Poddar

Last year, a colleague of mine picked up woodcarving. They told me about their battle with the “originality demon” and how, even when learning a new and productively right-brain skill, they felt every knife stroke needed to be an original one. Each complete whittle needed to an attractive addition to a catalog of novel works.

Then a content creator – a carving guru, as my colleague referred to him – referred to some of their more simple or instructive carvings as “diddles”. These diddles were common, practiced, and rehearsed; there’s absolutely nothing original about these them. He event went as far as to dictate each cut as if they were notes on a staff. Yet, they were a critical part of this creator’s trade, and so my colleague took solace in the idea that regardless of profession or experience, we need to iterate on the trite before we can produce even a modicum of original work.

My colleagues’ story resonated with me; programming works the same way.

I can’t count the number of times I’ve stumbled on a new idea, excitedly put pen to paper, and resurfaced a few hours later to learn – after some light ‘market research’ – that someone else has solved the problem. At that point I’m faced with the decision to write it off as a fun investigation or to forge ahead knowing that someone beat me to the punch. And of course someone else has! Given the glut of public repositories on Github alone, it’s hard to imagine some problems haven’t been solved.

I wouldn’t call this a particularly productive outlook, but for some innate reason it’s a shared human experience. We want to be adventurers and make great discoveries, and yet the most notable advances are often those in a solved fields.

Take chess, for example. The further a player deviates from the “main line” or accepted variation, the higher their odds of finding a novelty – a move no one has considered before in that position. 99.9999% of those novelties aren’t fabulous moves, but there’s a one-in-an-infinitesimally-small chance they’ve discovered something game changing. Chess is not a solved game; that’s why we continue to play. On the surface, it looks like there are a finite number of moves. On the surface, every player has perfect knowledge. And on the surface, there shouldn’t be a stone un-turned. For those reasons alone, finding novelties Chess is exhilarating. Repetition, learning the lines, and studying old games are the only way you’ll find a novelty worth its salt.

Like chess games or wood carvings, frame your programming projects as diddles. Sorting algorithms, data structures, security groups, EMNIST data, hello worlds – all are diddles. There’s nothing original about heap sort and certainly classifying handwritten letters seems like a solved problem. We should take solace in that. Before we write our magnum opal, we should understand existing systems. How can we presume to be entirely original until we know all existing prior art.

There’s another part to diddles too. In a recent post about Basic English and controlled languages, I touched on that, to learn quickly we need to first learn slowly. By limiting the syllabus to the most common parts, we’re giving ourselves time to build a solid, reliable, and practical foundation. My colleague may have carved 15+ canoes in one weekend, but their last iteration was infinitely better than their first. By freeing themselves from the need to produce original work, they were able to focus on the techniques of carving.

Thinking about my own experience learning Go, I probably wrote just as many CLIs as my colleague has carved canoes. CLIs aren’t sexy and they’re most certainly not novel. But now I can whip out a CLI faster than you read this post. And how many times have I needed to in the wild. Tons!

So write like Didion! Paint like Jackson! Dribble like Jordan!

Practice your diddles, re-implement your darlings, and study how “innovations” make use of your favorite data structures. Before you blow anyone’s mind, first learn what makes their brain tick.