Crochet and software development don’t seem like natural companions.
If you had told junior-developer me that crochet would eventually influence how I approach software development, I probably would have scoffed.
At first glance, the two have very little in common. One involves yarn and hooks. The other involves code and pull requests.
Yet the longer I’ve spent doing both, the more I’ve realised that many of the habits that make me a better crocheter have also made me a better developer.
Don’t Rush
One of the first lessons crochet taught me was that speed and progress are not necessarily the same thing.
If I rush through a row or round, there’s a good chance that I’ll miss a stitch somewhere along the way. The mistake might not be immediately obvious, but several rows later I’ll find myself wondering why the piece no longer looks quite right.
Software development has a habit of working the same way. A rushed feature or bug fix may appear to work at first glance, only for the unintended consequences to emerge later during testing or, worse, in production.
Over time I’ve learned that taking a little longer to get something right is often faster than having to undo and redo work later. Whether it’s a crochet project or a software release, fixing mistakes is usually more expensive than avoiding them in the first place.
Plan, But Stay Flexible
Crochet has also taught me the importance of planning before starting a project.
When I sit down to plan a crochet project, it is not just a question of whether I have enough yarn. There are also questions such as whether I have the correct hook size, whether the project is suitable for travelling, and whether I have the time available to commit to it.
At the same time, I never assume that I will get from the first chain to fastening off without encountering any issues along the way. A hook could break. A ball of yarn could become hopelessly tangled. I may even discover that the pattern isn’t working for me and decide to start over.
Software projects are remarkably similar.
When I sit down with my business analyst colleagues to plan work for an upcoming sprint, we spend time discussing how a feature might be implemented or how a bug should be investigated. We consider the known requirements, identify potential risks, and try to determine the best path forward.
Sometimes the implementation unfolds exactly as planned. More often, something unexpected emerges once the coding begins. A technical limitation appears, a business rule wasn’t fully understood, or the existing code behaves differently than anticipated.
Planning remains essential, but neither crochet nor software development has taught me to expect a perfect plan. Instead, they’ve taught me to have a plan while remaining prepared to adapt when reality inevitably has other ideas.
Know Which Mistakes Matter
Over time, both crochet and software development have taught me that perfection is not the goal. The goal is understanding the impact of a mistake.
Some mistakes are cosmetic. They may annoy me because I know they’re there, but nobody else will ever notice them. Others will undermine the integrity of the entire project and need to be addressed immediately, even when the fix is frustrating or time-consuming.
Knowing the difference is a skill in itself.
Whether I’m frogging several rows of crochet or rolling back a problematic code change, the lesson remains the same: ignoring a significant mistake rarely makes it disappear. Sometimes, the most efficient path forward is accepting a temporary setback so that the finished result is stronger for it.
Build Margin Into Your Plans
Another lesson that I continue to apply in crochet and software development is the importance of planning for contingencies.
When crochet patterns specify the amount of yarn required, they almost never specify if it accounts for things like yarn tails, gauge swatches, or the occasional mistake that requires a section to be reworked. This is especially true for projects like sweaters, where running out of yarn near the finish line can quickly become an expensive and frustrating problem. Few things will make a crocheter question their life choices quite like playing yarn chicken with the final sleeve of a sweater.
This is why I make a point of buying one more ball (or skein) of yarn than what the pattern calls for. Most of the time I don’t need it. On the occasions that I do, however, I’m always glad that it’s there.
Software development is no different.
While some contingencies are relatively easy to plan for, such as public holidays or planned leave, many others are impossible to predict. Team members get sick. Requirements change. Technical challenges emerge halfway through development.
The goal of planning is not to anticipate every possible issue. Rather, it is to leave enough room in the plan that unexpected events do not immediately derail it.
Whether it’s an extra ball of yarn sitting in my project bag or an additional capacity built into a sprint plan, the principle remains the same: a little preparation now can prevent a lot of stress later.
Never Stop Learning
If there’s one thing that both crochet and software development have taught me, it’s that there’s always something new to learn, even if I don’t end up using it immediately.
No matter how many years I’ve spent with a crochet hook or behind a keyboard, there is always a new technique to learn or a new perspective to consider.
Some of the most valuable lessons I’ve learnt have come from projects that didn’t go according to plan, whether they involved a crochet hook or a software feature.
Not every lesson will prove immediately useful. Some may sit quietly in the background for years before the right opportunity comes along.
What matters is remaining curious enough to keep learning. After all, the moment we convince ourselves that we know everything worth knowing is the moment we stop growing.
Whether I’m learning a new crochet technique or exploring a new framework, the lesson is the same: growth comes from staying curious long after comfort sets in.
