Practicing coding as a performance

Coding is often done in a solitary setting. We sit and think alone, write, revise, possibly submit for code review, revise again, and then merge. It’s an activity that could be compared to writing prose, painting, or sculpture.

However there are times when we must perform as coders, more akin to a musician improvising. Some examples include interviewing or pairing with a new colleague. You might also consider hackathons or time-sensitive, critical bug fixes to be performances.

Many programmers, including me, get very nervous in these situations and avoid them if possible. But what if we could practice coding as a performance to help alleviate some of the pressure? What if it could benefit us in other ways for our normal, non-performance-oriented coding?

The benefits of coding practice

Below, I’ll describe some of the ways that I’ve practiced, but some of the benefits that I’ve found are:

• Lowered time and mental barrier-to-entry on new projects.
• Faster ramp-up in new projects to best practices like testing, linting etc.
• Moving cognitive load from “grunt work” problems to the actual problem I’m trying to solve. In other words, getting to flow faster.
• A mindful awareness of my own feelings and mental blocks while coding.
• Detachment from any one piece of code and being willing to replace it with a better implementation whether written by me or not.
• Getting out of mental ruts.

An experiment in structured practice

A few years ago, I led a month-long round of code kata among the engineers at the company where I worked. These are programming problems that you try to solve again and again for practice or training. Hopefully they help you exercise mental pathways, reinforce your learning, and become more familiar with both the specific problems and coding in general. I gave suggestions of problems to work on and asked managers to give their employees time to work on these if they chose to participate.

A different kind of structured practice

Everyone was free to practice on what they wanted, but in my own practice, I moved my focus away from traditional algorithm problems to design patterns. Many days, I would start from a totally new project and bootstrap it up to the point where I could do a simple problem, but with a fully-functional testing infrastructure in place. I put time bounds on myself and sometimes I didn’t even get very far into the code, but I practiced starting a new project.

Before starting that practice, there was a cost in my mind to starting a new project. I’d think about all the bootstrapping and boilerplate I’d have to do. So many ideas stayed in my notes and never made it out. When I did start new projects, I might wait to put in tests until I absolutely had to do so because it meant I’d have to figure out how to set that up and it would distract from the “real work.”

After starting new projects, adding testing, and getting to working code for 10–30 minutes or so each day for even just a few days, a lot of those barriers seemed to fall away, if only mentally. I knew I could get started quickly and to the code that I wanted to focus on.

New beginnings

It’s been a few years since I did this experiment and recently I decided to return to it in a much smaller way, but again by starting projects. Lately I’ve been doing a lot of Javascript web development in React and it’s become a lot easier to get started with a project using create-react-app. Similarly for other languages and frameworks, there’s been an amazing shift to making starting new projects easier than ever.

Starting over can be fun!

One of the benefits of starting new projects with these bootstrapping tools is that they include new defaults and recommended packages bundled in. When I started some of my other projects in the recent past, I would have to figure out how to set things up, but now a lot of that is solved. By using new best practices, I get to see how I could revise some of my existing projects.

If you’re interested in trying this type of practice, here are some ideas on how to structure your sessions:

• Start a new project using the newest versions of a stack with which you’re already familiar.
• Build a small feature that you’ve done before — avoid creativity and novel learning if you can at this stage. You’re practicing.
• Pay attention to your thoughts as you code — when you feel like you have to make an active decision (e.g. where should I put this file? should I break this into smaller pieces? etc.), just pick one option quickly. The next time, try the other option.
• Limit the time spent each time you practice. As you repeat creating new projects, you’ll get faster and thus have more time to explore more deeply in the same time box.
• Save your work at the end of each session, but don’t start from it in the future. Feel free to revisit just to see how you may have done something or how far you’ve progressed, but treat each session’s work as disposable. (c.f. Sand Mandalas)

Finishing a sand mandala

This current round of practice has already encouraged me to get started on some new projects. They seem easier after I’ve had a chance to create and throw away some code in practice sessions.

Despite doing all this practice, I still don’t exactly look forward to performing for anyone else anytime soon, but I realized that I’m enjoying performing for myself by getting to flow on new projects faster.

Have you tried practicing in a similar way? What worked and what didn’t?

If you try this practice, please leave a reply on how it went. ✍️

Thanks and happy practicing!

If you enjoyed this post, would you 💚 and/or share so other folks can find it? A follow would be mighty nice of you as well. :)