I recently bought a fancy ergonomic keyboard. It has a bunch of fiddly ways to customize it, including altering the behavior of any of its keys far beyond what your standard QWERTY is capable of. The idea, of course, is that mastering it will turn you into a computing wizard, lines of code inundating your screen like sheets of rain in a thunderstorm.
I now suck at typing. It turns out altering the positions of your keys and how they function requires a steep learning curve. And just when I started to feel like the muscle memory was setting in, I went on a trip and attempted to type on my laptop’s standard keyboard and all my c’s were coming out x’s, and I kept hitting Caps Lock when I wanted Escape. And next week I have to switch back.
Am I frustrated? Hexk no, I think this is fantastix!
Writing custom software is an art, not a science.
Software often gets compared to other engineering disciplines, like building a house or sending a rocket to Mars.
I think writing quality custom software is much more like creating a unique piece of art. Aspects of the process may be repeatable or reusable, but it is never as formulaic or bound by the same constraints.
Learning to use a new keyboard is a bit like trying to learn to paint with your off-hand, or painting everything upside down, or only being able to splatter paint onto the canvas from above.
I don’t think my new keyboard will turn me into the Jackson Pollack of coders (or the king of spaghetti code), but in creative work, it’s vital to play and explore boundaries. Picking up a new tool (or wielding an old tool in a new way) is a great way to uncover new mastery for your craft.
Remember to slow down.
I really loved this recent blog post from a woodworking site, Take Your Time, about the benefits of purposefully doing slow, “inefficient” work. The author is talking about a hobby as opposed to their primary job, but they hope for “the possibility that engaging in a different kind of work in my shop might also transform and recalibrate my work as a parent, teacher, son, and partner.”
One of the twelve principles behind the Agile Manifesto tells us “Simplicity — the art of maximizing the amount of work not done — is essential.” Bob Ross didn’t paint beautiful landscapes in 30 minutes because he could move his brush at more than 100 strokes per minute. He built up foundational knowledge for years through repeated practice and painted happy little trees and lakes and mountains with just a few simple brushstrokes.
Nobody ever got a great piece of custom software written efficiently because the programmer was a fast typist.
And I wonder, what would an episode of The Joy of Painting be like if Ross had tried something like painting with his left hand? What might the 100th left-handed episode produce?
Build empathy through failure.
Author Karen Rinaldi wrote a book called “It’s Great To Suck At Something.” Here’s a delightful podcast interview with her espousing the benefits of doing something you’re bad at.
For me, one of the biggest benefits of doing this is the way it opens you up to empathize with others who might struggle at tasks where you excel. It allows them to see that you are also human and not perfect.
At Atomic Object, we put a big emphasis on mentorship, and I don’t think it’s possible to be a good mentor if you can’t put yourself in the shoes of the person you’re mentoring. It’s harder and harder these days for me to remember what it was like when I was first learning how to program (although I’ll never forget the time I accidentally DDOSed the office network with a bad Apache configuration).
Right now though, I’m struggling to find the correct keys efficiently. But when I do, it is EXHILARATING.
This is what inefficiency in writing custom software means to me.
If we’re going to give our customers, and ourselves, the best of what we have to offer, we’ll have to discard (not waste) a few extra canvases in the process. This isn’t about not trying hard, or getting away with doing less. In fact, I think it’s about trying harder to do more.
Hopefully, I will eventually master this keyboard, and be able to effortlessly switch between it and other more standardized keyboards, the way multi-linguists shift between spoken languages.
And when that happens, I’ll have to find another way to make my work a little bit less efficient.