Over the past 6 or so months, I’ve spent a lot of my quarantine cooking – about 1-2 hours a day. As one might imagine, spending a lot of your time on any activity really forces you to optimize for the things you enjoy. For me, an experiment trying to cook the best steaks led me down the rabbithole of metal cookware. Shortly after purchasing my first cast-iron skillet, I found myself enamored by this new style of cooking and the feeling of caring for my cookware. Though my girlfriend made fun of me for the amount of work I sunk in to cleaning the pan while I learned the ropes of proper temperature control, there was something (or maybe just the sunk-cost effect?) that kept bringing me back to using my new pan. Clearly, there was something to it though, since I managed to rope my roommate into the whole ordeal and convince him to purchase a few more pieces.

In reflecting on my thoughts on programming languages, it’s easy to see the parallels. I’ve long enjoyed writing code in some rather unusual languages (OCaml, Scheme, Prolog, Rust, …) and some rather masochistic languages (C, C++, and probably Rust too). At first mention of my language choices, people often react by questioning the value of using such obscure/”old” languages – what could the value possibly be in a language where you have to reinvent the wheel every time you write a program? Why not use a mainstream language with all the libraries available? To an extent, I find myself agreeing; it’s very likely that I’m much less efficient than the guy using Python, in much the same way that I’m slowed down by waiting 10 minutes for a pan to preheat. At the same time, I think it’s just more fun this way.

Of course, there’s an argument to be made for picking the right tool. One might suggest the use of C++ for writing a low-latency trading system in much the same way that they’d suggest a cast-iron pan for a stove-to-oven recipe. But more and more, I find myself clinging to the special tool as my silver bullet, applying a niche instrument to general purpose work when other tools could make my life easier. If it’s just more fun, why not scramble eggs in this pan and write my web server in that language?

Fast vs. Fun

It seems like this value of maximizing fun is lost on many others, because by virtue of taking more time I spend more time than I need on any given activity. From my perspective, there exists a spectrum of enjoyment vs. time. For some, a boring task is best “solved” by rushing through it and for others it’s best “solved” by going slow and focusing on the fun parts.

However, there might be a little more to it. When I first introduced my friend Zach to OCaml in the midst of a project on a tight deadline, he was obviously quite hesitant at first. Yet a few years later, he’s developed my same addiction (he spent this past summer working on Revery and Onivim – a GUI toolkit and a text editor both written in OCaml!). Maybe we all tend to stick to these kinds of decisions?

Bringing it all together

The more I explore this idea, the more convinced I am that there’s some inherent value to this type of enjoyment (beyond just wanting to gouge your eyes out after spending all day doing something you hate). After all, I’d expect to eventually tire out of the inefficient path and I’d expect the same from my friends who I’ve influenced. And yet it seems to be the case that if they enjoy something just a little bit more, it becomes their go-to rather quickly. It makes me wonder how often we short-change ourselves by refusing to try that new thing because “it’s just too much work”.