The unbridled joy of creation

Sat Nov 12 '22

There’s a lot to be said about the current state of software development at startups—page after page of agile methodologies, code review practices, grandiose plans to tackle technical debt, and a indomitable mountain of meetings, all standing in the way of the actual act of creating software.

But this isn’t about that.


I recently rediscovered my passion for indoor rock climbing, which is like the gym, but with problem solving. In some ways, climbing is akin to solving a software problem, where—to be efficient—you need to plan ahead before you jump onto the wall. But the type of climbing I like most is the creative, spur of the moment, try something until it clicks, climbing.

Part of coming back to bouldering has been joining a training study being run by a local university, and one of the requirements of the study means that I need to keep a climbing log of each visit to the gym. I was given a spreadsheet as the template for the logs, and I started by using google sheets on my phone to track my attempts and failures. It’s not a great experience, especially when your hands are covered in chalk.

It looked something like this:

Date

Grade

Attempts

Failed

Nov 2

V0+

1

N

V1

2

V4

12

Y

Two things frustrated me about this climbing log (beyond the google sheets experience on mobile):

  1. I had to remove and update the attempts to increment the count.

  2. You don’t really “fail” a climb until you stop trying it during the session entirely, so you end up only classifying climbs as not failed (meaning you succeeded), and later filling this column in for previous climbs.

I could have improved the spreadsheet experience by adding some fancy drop-downs or VLOOKUP’s, and probably would have had a terrific experience in the end. After all, spreadsheets are great.

There’s (probably) an app for that

I briefly looked for apps that would simplify my life but couldn’t find any that satisfied two important conditions: you must be able to export your data easily (for submitting my study results) and I didn’t want to sign up for an account for some service to use an app on my phone. Increasingly, it seems that this is an unreasonable condition to have to use a phone.

So rather than settle for something that didn’t meet my conditions, I chose to create one myself: 🤏 pinch.

A screenshot of pinch
The resulting user interface after a few changes.
an example of adding a project or boulder in pinch
The current workflow for adding a green V1+ boulder problem in pinch.

Some context is needed before I proceed…


A brief tangent

I was recently afforded the opportunity to take a four-month sabbatical from work, which was an amazing experience in many ways. In particular, it let me devote a lot of time to creative works. Below are some highlights of things I created in those four months.

Nursery

renovation and wooden art for a nursery
Fully insulated, drywalled, and finished nursery. Learned how to use sketchup to model and then created some wooden mountains/clouds.

Woodworking

maple frames for art I like
Made some frames out of maple for art I like.
milled lumber polaroid frame
Used some maple from a tree that I milled several years ago to create a polaroid picture frame. We have a pile of polaroids and swap these out randomly for people to discover.

Videography


The reason I went on this tangent is to highlight some of the ways that I normally scratch my creative itch. Even when I’m working full-time, I’ll find ways to create something, usually with my hands, as it is something I find very rewarding.

When looking for apps to suit my needs for a climbing log tracker, I remembered that I could suit them myself, and then I did so[1] and it was awesome. This one small project reminded me of just how much fun software can be to create, and how much work you can accomplish when there’s no barriers.

I’ve tried to do this before with other ideas, or needs that I have from software, but I’ve often been handcuffed by the same kinds of decisions that come up when doing software development professionally—is this the absolute best way to write this software? What is the best framework to use? Am I following best practices? etc…

This time, however, I allowed myself to settle into the same mode I employ when creating outside of software, a flow state where getting something done is better than making something perfect. If you described this as a method of software development, some may consider you crazy, but it really works. The one (big) caveat is that you have to allow room for reworks and rewrites, something that is a lot easier on a solely-developed side project.

If you are permitted that room and you unblock yourself from making the perfect thing, you will still make something great, and doing this repeatedly will improve your skills. I believe this is called “practice” and it’s not something that I think software developers employ enough.