Practice Matters

Origami

I recently gave a presentation titled “What I Learned About Software Development from Origami”. Originally it was just going to be a fun way to combine two seemingly unrelated interests of mine. But I ended up getting a valuable learning out of it.

I shared a lot of pictures of origami, but the image below ended up being key to the presentation.

You’ll notice this picture has two origami boxes. The one on the right has pretty straight folds and looks pretty square. The one on left has folds that look less straight and less square. It’s still a box, but the one on the right definitely looks more box-like.

So what’s the difference between these two origami boxes? They were both made with the same size and type of paper. Both were made using the same set of instructions. The difference between the two boxes is not in what folds were made but rather how those folds were made.

But how the folds in origami are made can have more impact than just how the resulting origami model looks. Let’s look at another image.

In the case of the origami cup (a relatively simple origami model), if the folds are not exactly straight and perfectly crisp then the cup will probably turn out fine anyway. However, in the case of the origami Yoda (a much more complicated origami model), if the folds are not pretty close to exact then everyone’s favorite short, green force wielder could look misshapen and unrecognizable. If the folds are far enough off from ideal, you might not even be able to complete the model at all. In this case the quality of the folds could determine not just how good the origami model looks at the end, but what origami models are even possible.

Isn’t This Post About Practice?

So what does all of this have to do with practice? From the origami examples above we can anecdotally conclude that the quality of folds can determine both the quality of the origami model as well as what origami models are possible. So how does one learn to make better folds? Practice of course!

Another one of the images I shared was an example of what happens when your folds aren’t of high quality. When I was folding the model to take a picture of it, it was actually one of the most challenging models I made for the entire presentation. Why? Because I don’t practice doing origami folds poorly. I only practice doing them well. So doing the folds poorly was a challenge.

What About Software Development?

This is a technical blog about software development, and so far in this post all I’ve talked about is origami. How does all of this relate to software development? In my presentation I compared origami to software development. In origami what folds are made is important, but so is how those folds are made. In software development what software we make is important, but so is how we make it.

What do I mean when I say “how we make software”? I mean things like:

• Do we write automated tests for our software?
• Do we write those tests using test driven development?
• Do we strive to write our software in a way that is easy to read and maintain in the future?
• Do we integrate the changes we make to our software with the changes other people make to that software frequently (ideally at least daily)?
• Do we deploy our changes to our customers frequently?
• Do we collaborate with others when we write our software?

The exact list of what practices define the “how” in how we write software is certainly up for debate. But I would argue that like with origami, the “how” not only impacts the quality of the end result, but also impacts what end results we can achieve.

Back to Practice

In origami, a couple of great ways to practice and improve are to fold the same models lots of times, and to learn to make new models you haven’t made before. Are there ways that we can practice the “how” of software development like we can practice the “how” of origami? Sure there are!

The Global Day of Coderetreat is coming up soon. If you’re not familiar with the idea of a coderetreat, this description from coderetreat.org may help.

Coderetreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design. By providing developers the opportunity to take part in focused practice, away from the pressures of ‘getting things done’, the coderetreat format has proven itself to be a highly effective means of skill improvement. Practicing the basic principles of modular and object-oriented design, developers can improve their ability to write code that minimizes the cost of change over time.

You may have noticed the word “practice” or “practicing” occurs in every sentence in that description. That seems to suggest that the idea of practice is important in a coderetreat. What kinds of things do people practice during Global Day of Coderetreat? They practice things like TDD, pairing and writing clean code. The goal of Global Day of Coderetreat is specifically to practice the “how” of software development.

I would strongly encourage you to participate in a Global Day of Coderetreat, especially if you haven’t before. But maybe coderetreats aren’t your thing. That’s okay. There are other ways to practice too. I like to use code katas to practice things like TDD and clean code. Using a code kata you’re already familiar with can also be a great way to practice learning a new programming language or learning more about a feature in your current programming language. I like to use small side projects to practice things like automated build pipelines and deployments. It’s okay if you don’t practice the same way I do. But find ways to practice. Find time to deliberately practice. And like with origami, be willing to learn new things so you can learn new ways to practice.

Master Yoda was right. Wars do not make one great. But practice might.