The Creative Act For Software - Breaking the Sameness

I have (again) been reading Rick Rubin's "The Creative Act - A Way of Being" which is a book about creativity and the wellspring from which it arrives. I read through it very quickly the first time. It's awesome. It's inspiring. The chapters are short and you feel something reading each one. Rick Rubin is a very successful music producer, but this isn't a tell-all or a memoir, this is some kind of spiritual, philosophical guide to .. well life. Creativity he says "is our birthright", it is what makes us essentially human. In a beautiful poem, he describes art as "choosing to do something skillfully...to make the finest work you can."

My first time through the book I was writing a lot of software, so I found myself constantly seeing similarities between creation of artwork and the development of computer code. I found that most of the advice in the book (intended for people involved in creative acts) was also useful when writing and debugging code. It's probably most useful for tasks that require creativity.

In an interview I heard Rick recommend reading a chapter a time when it makes sense for you, and today I am going to focus on "Breaking the Sameness." I'll reflect on how each piece of advice relates to my personal experience writing software. This chapter deals with times during the Craft Phase (a time when you are discovering something genuinely new) that you "hit a wall and the work isn't getting any better".

I know exactly what this feels like. Some days every bit of code you touch seems to make things worse. If you are a person who creates software, maybe some of these techniques could be useful to you as well on those "hit-the-wall" days.

Before stepping away from the piece, it's worth finding a way to break the sameness and refresh your excitement in the work, as if engaging with it for the first time - Rick Rubin

Nine Techniques to Break Through

There’s no better solution than fresh air to get unblocked, but if you are interested in techniques you can do without "walking away from the code" then consider the nine types of advice from this chapter.

Small Steps

Rick talks about getting a musician to set small targets and simply write one line of a song a day as a way to unblock the creativity. If you are having trouble getting the creative juices flowing for a big feature dev project, consider making a simple change that is low risk to get some momentum. Upgrade a library. That is literally one line of code that could get you moving. Sometimes just opening the project or service where you need to work can "reopen the creative channel". The hardest part is often getting started.

Change the Environment

For musicians Rick tells us that it can be helpful to turn off the lights or even once to hang upside down. The point of this advice is to introduce variation into the work. I have solved layout bugs by simply resizing the browser in unexpected ways, or moving from one screen to another. One monitor was lower resolution and revealed a style I missed on the other, more expensive one. A classic technique for testing functions is to "fuzz the inputs". This can be useful for automated testing, but also may help when debugging as a manual "poke around and find out." Nonsense like passing a string where your code is expecting an integer to see what happens can occasionally unblock an impasse.

Change the Stakes

Fear is a barrier to creativity. Reduce stakes by stepping away from the intense pressure cooker code you are working on, and make a smaller problem. Open the browser console and declare some variables there. Make the immeasurable feat you are working on fade into the distance and take on the smallest part of what you need to do. Then keep doing that. Solving small stakes problems is a great way to build up to larger ones. In The Pragmatic Programmer, the more intense (and involved!) version of this is referred to as "tracer bullets." If you can execute low stakes code in production that is the ultimate game changer. Small stakes experiments can help make progress where things are stalled or intractable.

Invite an Audience

In this section, we reflect on why having musicians perform for an audience can alter the art they create. As a software dev, you may not want to go full twitch streamer, but experimenting with pair programming can be an invaluable exercise. Writing code in front of another forces you to make decisions (and justify them!) and can really unblock a stall. I also highly recommend creating a presentation on any new topic you are learning or an especially difficult coding challenge you may overcame. There is always new insight to be had from public displays of code.

Change the Context

Rick recommends that when performing a written work that was created with a specific person in mind, sometimes artists try singing to a different person in order to change the performance. When developing, consider as many users of your final work as you can. Many software features are designed for customers first, but if you are designing a database schema for a customer facing data, consider what other users may also need. Do you require additional fields that are useful for admin or super-users? Could you actually leverage an operations team to greatly simplify things for customers or vice versa? Changing your context during early decisions can save a ton of time down the road, but it can also solve a real problem in front of you. Pivoting is good if things have become intractable, and seeing a different side of a problem can often reveal an unexpected elegant solution.

Alter the Perspective

There have been times when I got "the yips" (as they say in baseball). I just couldn't write a passing test for the life of me. Nothing I was writing was working, and I would spend hours solving small problems that end up being the wrong problem. At times like this, it may be worth it to write something completely different for a moment. Separate yourself from the syntax and problems of the day and move to a whole different language. Struggling with some edge-casey typescript all morning? Learn how to write a server in a language you've never used. You'll be amazed how deep your knowledge really is when you try something else where your skill level is zero. Return to the problem with a new perspective and things may just seem easier.

Write for Someone Else

In the book, Rubin tells a great story about how the lyrics for the song "(You make me feel like a) natural woman" were actually written by a man. I love this story, and find this technique especially helpful at a new job or inside an unfamiliar code base. Ask yourself how the person who left this code here before would have added a new feature. Is the previous author telling you a story or guiding you to a particular place? Code is often a communal exercise and trying to write for others is a great way to reduce the amount of time you spend in review and before merging. Also try rubber-ducking. Explain the code to a rubber duck. Write the code for the duck. They help you look inside and find the answers to unblock the work.

Add Imagery

One of my favourite experiences writing code recently had to do with a data extraction process whose end output was the delivery of reports to an external partner. We knew that an increasing variety of these such extracts were going to be needed, and were looking to do some system design to make sure that what we built would grow with the company as scope naturally expanded. It was difficult to define domain lines for the problem - is it the report's responsibility to deliver itself? Who takes care of the generation of the files from the source data? Should the data extraction process be coupled to the delivery? I ended up kind of stuck and spent an hour reading about shipping containers. I figured that we were shipping reports and that people who ship things on boats had probably solved similar problems. Things started to crystallize - we would create "manifests" that described the exact contents that were being delivered, and those would be marked as complete upon delivery. Once the reports were collected from the "dock" the manifest would receive a final time stamp and the deliver would be considered complete. Adding imagery to the problem helped to unblock the design and led to a very resilient system.

Limit the Information

When I got to the last section, I thought that Rick may actually have been writing about software development. Limiting the information is a classic debugging technique. If things are broken and you don't know why, start reducing external dependencies and simplifying the inputs. The smaller you can make the problem to solve the better. And, once unblocked, you are once again free to receive the creative input of the universe in your code. In the book, Rubin talks about showing only minimal backing tracks to musicians before getting their input and asking them to collaborate on the code. This can be a great approach with code as well. If you have a new pattern that you want people to adopt, try sharing a simple MVP and asking them how they might use it before adding too much of your own input. Just like a great producer trusts the talented musicians in his studio, so too must you trust the developers on your team to fill in the blanks where it makes sense.