On Showers, Golang, and Creativity
The Eureka Factor
Many ideas come to me in the shower. Some are flashes of sheer brilliance, now it’s time to wash beneath my armpits. Some are subtler insights, often outside the immediate domain of showering — a simpler way to design the API for the feature I was working on at work, perhaps.
Showers are commonly believed to bring out creative ideas. It’s not just me. Many blog posts already elaborate on the connection, so I won’t say much. Briefly, mechanical, mildly relaxing activities activate something called the default mode network in your brain, which cognitive scientists have associated with creative thought.
Showering is not the only mindless activity, however. Programming, also, can sometimes be mindless, mildly relaxing, and mechanical. That brings me to the subject of Golang.
I’m a newcomer to Golang, so take what I have to say with a grain of salt — possibly the whole shaker — but my impression is that idiomatic Go code involves a bit of boilerplate. Writing Go feels more mechanical, sometimes, than writing equivalent code in, say, Javascript, my first and truest love, whose every line of code is interesting (too interesting, some might say). For example, Javascript gives you generic .map and .filter. Go has no generics, and requires you to write your own .map and .filter for every type, but you probably should just use a for loop.
Let me be more concrete. At Livestream our Go services are influenced by the go-kit framework, which outlines a conception of best practices for Go web services. Peruse the example of what service middlewares should look like, and you will observe a lot of what smells like code duplication. There are nine copies (one for each RPC of the service) of essentially a single function that logs at the end of each request. Whereas in my beloved Javascript, using express, you would accomplish something similar with these nine lines, written once. It should be said that nothing about the Go language forces you to duplicate in this way, but it seems to encourage you to do so as a matter of philosophy.
In my approach to Go until recently, I’ve been of the mind that this sort of tedium — writing basically the same function nine times — is a necessary evil. You feel dirty when you write code that seems redundant. In other languages, it usually means you are doing something wrong: you need more or different abstractions. But in Go, you just have to hold your nose and duplicate code. It is a sacrifice we make willingly so the Go Gods will bless us with nice tooling and fast compile times.
Lately, though, I’ve been second-guessing this “necessary evil” idea. Is writing redundant code truly an “evil”? Maybe you don’t have to hold your nose — maybe underneath the stink, it actually smells good! If you get over your hang-ups about it, mechanically writing boilerplate code can actually be a pleasant experience. I know exactly what to type, my fingers fly across the keys, and I see my creation materialize. It’s good Vim practice. Even though I’m not accomplishing anything particularly interesting, I do feel like I’m making progress. And while I’m making progress, the “default mode network” is activating, and the creative ideas begin to come. Perhaps it will be an idea about the chunk of code I’m currently cranking on — should I be using a different data structure, maybe — perhaps about the higher level architecture of the application, or perhaps just an idea on what I would like for lunch. Do not underestimate the importance of lunch.
Put differently, what you might be tempted to think of as Go’s obtuseness and inflexibility, you may also choose to think of as having mandatory “shower breaks” built into the language. “It’s a feature, not a bug.” That perspective certainly helps me better enjoy my experiences with Go. Your mileage may vary.
Now if you’ll excuse me I’m off to go take a shower.
Go lover? Expert showerer? Consider joining our team of well-showered engineers at Livestream: building the infrastructure to serve live video to millions, one shower at a time.
If you liked this post, follow me on Twitter. There will be more.
