the scapegoat dev

Having a creative practice as a programmer

Programming is a creative activity. In fact, I think programming is inherently artistic. A program is not just executed by a computer: it is also an artifact shared with other humans. Some will read its source code and appreciate its beauty, style, intent, history, or lack thereof. Others will use the program for its (or their) intended purpose and enjoy the way it does so—its "essence," so to say.

We programmers have refined intellectual collaboration, with our JIRAs and scrums and Google Meets and pull requests and code reviews. We have learned to charter our creative minds under the aegis of capitalism. We have perfected discussing our craft on our beloved StackOverflow, Hacker News, Twitter and Discord, and so many others. We, however, have lots to learn from artists, who have refined what I call "creative practice."

Creative practice is the act of continuously working on one's art—developing craftsmanship; studying artists past and present; finding and refining a personal style; taking risks; reflecting on past failures and successes; even just organizing one's workspace and learning how to mend one's tools.

Lessons learned from drawing and music

Since I was a little kid, I have always wanted to work with computers, but I was also very interested in drawing and music. Whatever facility I had at the keyboard didn't translate well to the piano, the guitar, or the pencil, and so for most of my teens and twenties, despite my best efforts, I never imagined I would be much of an artist.

When I turned 30, in a flash of self-confidence, I decided to give the old "10.000 hours will make you a master" trope a go and set out to learn drawing. It was the beginning of the youtube era, and I attended the first iterations of "online classes," which was exhilarating.

I heard in many of these classes and communities that quantity trumps quality; that you should carry a sketchbook with you at all times; that nothing is too insignificant not to be drawn; that copying the masters is a staple of art curricula everywhere. I learned that sketching is hard but cheap and that rendering is easy but onerous. I learned that even accomplished veterans still practice simple things such as drawing lines, ellipses, and painting studies of light and shadow.

This taught me that there can be a separate track within one's career that runs parallel to one's "productive output."

Let's say that as a painter, your current project is a grand painting of a naked man riding a lion—you will spend several hours every day for a month working on this painting. Yet every day, you also draw in your sketchbook; you study colors; you paint small studies of details you later on incorporate in bigger paintings; you practice your linework and brush strokes; you clean your brushes and order new colors and file away your sketches.

You are an artist not because you finish a big painting every other week—you are an artist because every day you work on your art.

After a few years and a few dozen sketchbooks, I got decent enough at drawing to realize that I had no big aspirations to become a visual artist. Not so for music. I have written about my trajectory as a musician before, and that article touches upon many points I am making here.

The tenet of that article is that it is the act of adopting a creative practice, in all its mundanity, that finally made me a "real" musician. It wasn't sounding good, having clever musical ideas, or even finishing tracks. It was keeping up a consistent routine, furthering my art, and discovering what I wanted to actually "say."

What is a creative practice?

Of course, each person's creative practice will be different and evolve. Here are a few important points that I have discovered for myself.

This is quite subtle, and I still have to remind myself that my practice is about me as an artist (as a programmer).

Here is an example: do I need to learn Rust to be a better programmer, but writing Rust makes me feel like I want to tear my hair out? Then I probably need to either go for a walk, switch to javascript, read a book about Rust, or even just practice my typing speed. I can always come back to Rust when I feel interested in doing so. I am much better served writing some nonsense in Javascript or even just reading Reddit than wearing myself thin.

It was easy for me to let go when programming as a kid and in my twenties. I lost that skill in my last 15 years as a professional and am slowly recovering.

In drawing and music, it took me a lot of effort, as someone who is used to the inevitable and final feedback of the computer, to let go, be messy, indulge in errors, and see how not caring about results unlocks my inner creativity, my "all-encompassing mind's eye." But the messy experiments sometimes reveal what has been waiting under the surface. In programming, this might be a concept or an abstraction remaining unseen, finally revealed by some shoddy attempt at solving a leetcode problem in Erlang.

One of the best drawing courses I took was Dynamic Sketching with Peter Han, which used to be on CGMA. Before every session, we would have to warm up by drawing lines, ellipses, curves, and simple 3-dimensional shapes. This exercise fundamentally transformed my drawing, and I still practice it to this day. Of course, no discipline has perfected deliberate practice better than playing a musical instrument.

I have always been interested in velocity at the computer: I feel that being able to navigate my IDE, write code quickly, and think in editor shortcuts is fundamental to the quality of my cognition as a programmer. I see a strong parallel between practicing a musical instrument and practicing things like vim movement, keyboard macros for my current tooling, keyboard layouts, and window navigation.

A study is something that can be quickly sketched or played or written and that focuses on one specific element. For example, before doing a painting, you can do 20 little studies of possible compositions. Instead of carefully rendering human figures, you draw a little triangle and fill it in with one of three values: dark, medium, or light.

As a programmer, I love building little prototypes and focusing on one aspect of the problem I want to solve. Instead of using a database, I use hash tables; instead of using an HTTP API, I use a function call; instead of using a message queue, I use a simple array. This allows me to quickly try out different data schemas or study the impact of a load balancer on performance. It also makes it easier to relate heady abstractions to concrete details: a quick study makes it much easier to identify what concepts from functional programming could apply to the much more mundane web application I am working on.

The value of a study is not in how good it is: instead, a study sheds light on a problem—it explores a set of constraints. A study might or might not work—that is why it is valuable. Making it crappy on purpose (say, by writing a single file of untyped javascript with no dependencies) removes the pressure of producing something "good." All that counts is that you did the study and learned from it.

A fundamental aspect of a study is that it is meant to be thrown away. We are often overly precious with our source code, checking it into git and unit testing it and linting it and sharing it and reusing it. Really what we should often do is just let it go and try again, slightly differently; we should try and try again until we finally understand what we want, not just in the context of the program we are trying to write but in the larger context of our Art, of the programmer we want to be.

As an electronic musician, if my studio is not wired up correctly and ready to go, I will not create much. If I have to hunt for a cable for 30 minutes when I feel ready to record, I will lose whatever momentum I had. Searching for a cable is not "always making music."

It is vital to make time for the more pedestrian tasks in an artist's life, which also translates to the necessity for us programmers to organize massive amounts of information. If you feel tired, instead of writing a sudoku solver in Idris, you could spend an hour emptying your inbox, tagging posts in Evernote, or upgrading your credentials management on GitHub. The time spent doing those tasks is that much time you will have won when the time comes to set up a new application key.

For programmers, this means keeping backups of your digital artifacts and making them easy to recall. Visual artists have it easy here: their work is immediate and tangible. Musicians and programmers, however, have to invest not only in keeping their output easily accessible but have in preserving it through the vagaries of ever-changing digital formats. The software you wrote a decade ago will probably be hard to compile and run today; programs (or hardware!) required to open specific files might not even be around anymore.

One way to circumvent these issues is to keep a diary or a blog and record what you worked on, what you discovered, and how it impacted you as a programmer. Because writing is such a potent catalyst for thought, writing about your practice is a great way to amplify its impact.

Keeping a creative practice as a programmer

I am still figuring out what a creative practice looks like for me as a programmer—I know that it is not working on an open-source project in my spare time. That is too big of a project, too broad yet too focused; it requires commitment and grit, and sustained effort. A lot of the work a finished project calls for is not making me grow as a programmer. In many ways, working on a software project is like rendering a painting. I know what to do, I have done it before, and I know how to do it well, but it still takes time and effort.

Instead, I have tried in the last two years to do a lot of exploratory software work. I write a lot of little javascript snippets (javascript, especially coupled with typescript, unlocks a creative dimension in my brain); I write a lot of tweets and slack ramblings and drafts and entries in my Obsidian vault; I try to distill some ideas into blog posts; I read a lot of books; I practice my IDE shortcuts and try to learn new technologies.

In many ways, I have done this all my life, but I have never done it in such a consistent manner, focused yet devoid of expectations. I can feel how I both rekindle the passion for programming and just "doing" things I had in my younger years and develop and refine an underlying artistic vision of what my journey as a programmer is about, of what I want to say to the world.