The Joy of Programming

For the past handful of years I’d been a happy Rails developer. Happy – or, perhaps more aptly, content – because I knew that that I could effectively build pretty much anything I could dream up in Rails. This contrasted with what, in retrospect, was the more rebellious phase of my career, in which I hungered and scoured for newer, fancier tools with more bells and whistles.

Don’t get me wrong; I’d always kept my ear to the ground: I read newsletters, flicked through subreddits, and subscribed to RSS feeds. I’d see projects go by, maybe throw them a star on GitHub, and file them away in some distant part of my brain for “later”. Many of the projects I’d come across would find a use for me in my day-to-day work, but the more esoteric or not-in-my-ecosystem tools and ideas more often went forgotten.

I thought this was just par for the course in the industry: growing up, if you will, leaves us with less time to waste on distractions.

And that’s fine, because you don’t need those distractions; there’s more to life than work, and working so you can go home and work some more just so that you think you’ll be better at work seems to me like a bad way to live life. No one is a worse engineer because they spend some time with their friends or family rather than polishing off Knuth’s biblical works in hopes that they’ll get a leg up on the competition. But I digress.

A couple of months ago, a co-worker recommended me a book: Practical Object-Oriented Design: An Agile Primer Using Ruby by Sandi Metz. It provided a great back-to-basics masterclass in OOP (and I strongly recommend it) – some of the concepts I’d lost sight of over the years – but more importantly it was very refreshing to feel like I was actively working on and improving my skills as a developer. I hadn’t read¹ a technical book in too long.

With the itch to learn more, and thinking further mastery in Ruby would be most relevant to me, I quickly ordered a couple of other well-reviewed Ruby books² and, having heard innumerable recommendations, finally bought a copy of The Pragmatic Programmer – now thoroughly updated as part of its twentieth anniversary.

I devoured The Pragmatic Programmer: it’s an eminently readable whirlwind tour of all things software engineering, carefully bound together with neat anecdotes and nibbles of trivia. The reason this post came about, though, is because of the following advice (Thomas & Hunt 2019, pp 15–16)³:

Learn at least one new language per year

[…]

It doesn’t matter whether you ever use any of these technologies on a project, or even whether you put them on your resume. The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things.

It got me thinking. When was the last time I learned a new language, or built something in a new framework — not for work, but just because I could? What else was going on in the industry outside of my little Ruby filter bubble?

A lot, it turns out.

Over the next couple of weeks I spent some of my evenings and weekends exploring; nothing too deeply, but making a small scratch on a lot of surfaces in a short time. I wrote some Rust, rediscovered Lisp, hacked some C#, and pushed a whole lot of initial commits. I had fun, and I didn’t need to explain why.

What once seemed like a superpower had become nothing more than a day job. It took a fanciful excursion into the unknown to remind me what programming felt like when it was fresh and new.

I’ve taken a few lessons away from this experience, but I think the biggest is that something doesn’t need to be productive to provide lasting value; though I’m still doing Ruby and Rails (it’s still a great platform!), I haven’t been this excited about development for a long time.