This is a long form blog post of my conference talk of the same name. Slides can be found here.

I’ve been writing code in some form for almost 10 years, but I’ve been a crafter all my life. Unplugging and making things with my hands is where my true joy lies. I’ve played with many different crafts, but the one I continually come back to is crochet. I think this is in part because thinking like a crocheter is very similar to thinking like a programmer.

Let’s start by clarifying what crochet is in case you’re unfamiliar. Crochet is a hand craft using a continuous strand of yarn and a hook where the crocheter loops the yarn on itself in varying patterns in order to create the end product. Crochet may seem old fashioned, something that grandmas do in their spare time and completely unrelated to coding, but I promise that’s not the case.

Let’s start by thinking about ‘craft’ and its definition.

noun. A pastime or profession that requires skilled work, sophisticated technique, and science upon knowledge.

These 3 things—skilled work, sophisticated technique, and science upon knowledge—are the key components to be a craft. When thinking about crafts, many people often think ‘arts and crafts,’ ‘craft beer,’ or even ‘honing your craft.’ We instinctively know the difference between art and craft but I think making the distinction explicit helps and its that last component that’s key. Art is more about visual expression and creative intuition. Craft is more about science, and by extension, technology.

Remembering this, let’s think about code as a craft. In particular, let’s compare crochet with code.

Crochet < > Code

A crochet pattern is written out so that the crocheter knows which stitches to make, how many to make, and where to make them. A program is lines of code compiled to tell the machine what to do, how many times, and when. In both cases, its a set of instructions to be executed in a particular order. A crochet pattern is essentially a program; a program is a pattern.

When writing a crochet pattern, the designer is identifying and planning the stitches to make the end product. They test different stitch combinations and calculate how much yarn is needed to complete the project. A programmer, on the other hand, writes and rewrites lines of code to create the best solution to solve a problem. They test different solutions to see what makes the most sense. Whether designing a crochet pattern or writing a program, the designer and programmer fulfill the same role and complete the same activities.

Continuing on the same thread thinking about roles in the project process, when someone purchases a designer’s pattern and starts following the instructions, they become the hardware that the designer’s “code” executes on. As programmers, we consider the various hardware requirements on our projects and that informs decisions we make about the tools we use. It also informs how we write our code, but this is a lesser consideration today with the advancements we’ve made in memory management and garbage collection. Either way, both crochet designers and programmers have learned that the best instructions are simple and elegant.

When the crocheter is following the designer’s instructions and making their project, they are creating a physical manifestation of the algorithm the designer wrote. All algorithms, whether a crochet pattern or a program, are composed of and written in smaller parts.

A crochet stitch can be compared to a code method. Both are a small set of instructions given a name so we can invoke it repeatedly from various places within the larger program.

When creating a crochet pattern, the designer often uses stitch repeats to indicate sets of repeated stitches. These repeats can be repeated a certain number of times, such as in a for loop or until the end of the row, such as how programmers often parse input with a while loop.

Finally, a pattern designer often organizes their pattern into rows that can be compared to a class. The pattern designer defines their class (their row), and then every repeat of the row is creating an instance of the class.

Project process

Not only are the base skills that we need in order to create both crochet projects and code projects similar, but our process for starting these projects is also similar. The first step in either project should design and architecture. We start by thinking through the features that we want: texture, color, search, map functionality, etc. After making decisions about our features, these decisions will inform our architecture and how the components of our project should fit together.

A crochet designer would think about things like:

• Do I want to crochet in the round?
• Do I want to crochet each piece separately and join at the end?
• Do I want to join as I go for a different seaming experience?

A programmer:

• How do I want my search functionality to work?
• Do I want to have a top nav search from everywhere within the app?
• Do I want filtering?
• How do I share the data between the filters and the results?

Designing crochet patterns has actually taught me to spend more time on design and architecture in my code projects. When we’re coding, we often take the power of our tools for granted, specifically version control and cut and paste. In crochet, if I skip the planning phase and dive right into making stitches, I can waste hours of undoing and redoing my stitches until I get my desired result. There is no way to speed up the stitching the 4th time I start that row. Now I approach all of my projects, both crochet and code, with more intention and try to spend more time planning at the start so I know what direction I want to take the finished product.

The feature and architecture decisions ultimately inform what tools are chosen for the project. For a crochet project, if the designer wants to create a light and airy sweater, then they know they're going to need a large hook and a smaller weight yarn. If the programmer knows that they need a lightweight API to be consumed by multiple clients, they may choose to stand up a Sinatra API rather than starting a Rails app.

Reuse is everyone’s best friend in both the crochet community and in code. No one likes to reinvent the wheel. There are many crochet patterns available for free, and many designers use these as inspiration for their designs. If the designer knows they want to create a drapey shell stitch shawl, they may look for shell stitch variants until they find one you can modify to suit their project. We know programmers love to reuse code. There’s a reason there are so many Node packages available. Why rewrite something when someone has already written and tested it?

From a programmer’s first commit, the refactoring process starts. Code can always be improved and is often rewritten many times as the structure of the program changes and becomes more stable. In crochet, we also refactor, but we have a better word for it. We call it “frogging,” because as the crocheter undoes their stitches, they need to “rip-it, rip-it, rip-it.” But sometimes, we don’t need to frog our entire project. In some cases, if the crocheter notices that they missed a stitch in the previous row, they can monkey patch their current row and add an extra stitch. It really depends on the pattern if this is possible, just like with code. Sometimes monkey patching is a great quick fix in an area that doesn’t really matter to the overall project, but sometimes monkey patching can introduce even bigger headaches than if they would’ve just frogged/refactored everything and started from the beginning.

Finally, the last step before putting the project out into the world should be testing. In code, we QA and user acceptance test our code before we deploy to production. Or at least we should. Our QA engineers are vital to making sure we ship quality code. In the crochet community, these heroes are our pattern testers. Pattern testers are given crochet patterns to try out before they are published. Not only do pattern testers identify bugs in the pattern where stitch numbers don’t add up correctly, but they also fulfill the role of user testing. They provide crucial feedback when instructions aren’t clear or where the pattern can be written less ambiguously.

Code IS craft

We should reframe how we think about code and think of it as a craft. Writing elegant code requires all of the same components as crafting. There is absolutely skill, sophisticated technique, and technical knowledge required to be successful in the field. In both cases, we are using our hands and our brains to create something for others to enjoy.

When thinking about code as a craft, we can look to the crafting community for ways to improve our industry. I’ve touched on this in another blog post specifically geared towards what we can learn about onboarding from the crochet community, but there’s even more insights we can glean from this group.

Welcoming community

On the whole, crafting communities are open and welcoming. Within the crochet community, I’ve noticed an incredible willingness to answer questions and provide information for beginners. Questions are met with enthusiasm and answered thoroughly. We should embrace this openness more fully in the software development world.

Clarifying shared language

Well written crochet patterns include explanations for all of the stitches, abbreviations, and techniques used in the pattern. Even the most standard abbreviations are defined at the start. I appreciate this dedication to approachability. When a beginner downloads their first pattern, they have all the information they need to get started. In software, we should take the time to make sure we’re defining all of the jargon we use whenever we think there’s a chance our audience might not know it.

Multiple modes of communication

With crochet patterns, the pattern designer provides written instructions for how to complete the project. These instructions are often accompanied by step by step pictures so the crocheter can compare their progress as they work. But many pattern designers are going a step further and providing stitch diagrams for their patterns. For people who find written instructions difficult to follow, the stitch diagram can be easier to understand. The more ways someone communicates an idea, the more likely the audience will understand and enjoy the message.

When we are tasked with explaining code to a new team member, we should remember this. Instead of opening files and reading code, let’s set aside some time to draw pictures and show the data flow through the app or the composition of classes and how they fit together. It will be more fun and the new team member will more quickly be able to create a mental model of the project they’re joining.

Break the rules

Crafters are never afraid to break the rules. Just because crochet has been a craft typically associated with grandmas doesn’t mean it’s not an edgy form of self expression. Look up yarn bombing. Crocheters and knitters are using their craft to graffiti cities. As developers, we shouldn’t feel constrained by the way things are always done or listening to those who bemoan ‘best practices.’ We should try things out, see what works for us and our team, keep what does and get rid of what doesn’t. If we don’t like something, then change it. Obviously there are limits to this, but no one grew and learned who never tried something new.

Multidisciplinary approach

I hope you walk away inspired to look to other disciplines for problem solving inspiration. Just because something doesn’t seem related to software and coding, doesn’t mean that we couldn’t learn from it. I mean, if you made it this far, you just read nearly 2,000 words about how crochet is like code and how thinking like a crocheter is incredibly similar to thinking like a programmer.

I’ve been thinking about this topic quite a bit recently and it inspired the following posts if you’re interested:

1. What software developers can learn about onboarding from the crochet community
2. What software developers can learn about client engagement from preschools
3. What software developers can learn about estimating from road construction
4. What software developers can learn about consulting from hair salons Coming soon