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.

  • A creative practice is a habit. Ideally, it is something you do daily. I find time-boxing to be an effective trick here: 2 pomodoros before starting work is more than enough.

  • It is more about the practice itself than about results. The pressure to create something, or even worse, the pressure to create something good, is a recipe for burnout. I often try to deliberately create something terrible because nothing is worse than making something good and then trying to replicate that success.

  • It is time you dedicate to your art. The most important advice while learning music was to "always make music." This sounds tautological, but it means something profound to me. If I feel that my practice is going in a direction that is contrary to my interests, if I think that I am getting frustrated, then it is time to stop or do something else.

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.

  • Creative practice is a way to explore your craft. This is the time to do experiments, to learn new techniques, to do things you would never do at work. There is no prize to win, no shame to be gotten—this is your practice and yours alone. Do you want to copy the kernel source code by hand? Do you want to write a compiler in python? Do you want to see how many curly braces you can fit into a single javascript program? Go for it! Everything you do is valuable, but nothing you create is of value.

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.

  • Creative practice is often deliberate practice. All art forms have some craftsmanship component, and one becomes a better craftsman/craftswoman through deliberate practice. This means focusing on one particular aspect of the craft, for example, drawing lines and practicing it in a rigorous, repeatable, and criticizable form.

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.

  • Quick studies are essential. I originally called these "software prototypes," but fellow Recurser Max called them studies, which is a much more suitable term.

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.

  • Creative practice doesn't need to be creative. This took me a long time to understand. A lot of creative work is not innovative—a lot of it is problem-solving and perspiration, and iterative improvements. And some of it is pure organizational work, like cleaning brushes or untangling cables, or renaming files. When you look at it from a time perspective, however, it is just as important as coming up with new ideas.

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.

  • A creative practice needs to be reflected upon. Not everything you produce needs to be analyzed and dissected, and criticized, but it is often good to take a step back and think about where you are coming from, what you have achieved and discovered, and where you want to go next. This is why it is so valuable to keep the artifacts created during your practice. You can not only look back at what you produced last week but compare it to what you did a month ago, a year ago, or a decade ago.

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.

- 39 toasts