Programmes and Patterns: Or, What Bugs Us About Knitting

A black and red ladybird on one of the rhododendrons in my garden.

“It’s like code!” is a phrase I’ve heard several times over the years when teaching people how to knit and crochet.  If the physical execution is muscle memory, then the pattern itself is a programme or choreography.  Another choice word, also gifted by new knitters, is “recipe”, which – although etymologically unconnected to the word ‘programme’ – still captures the essence of information received and functions that must be performed.  A programme is something that is designed or built to perform a task or produce a result; a series of coded instructions.  In turn, a code is a system of representation.

As we all know, recipes, patterns and other kinds of programme are not infallible.  The quest for consistently error-free patterns has been a long one, and hiccups surface regardless of pre-publication checks.  At Waltham Abbey Wool Show earlier this year, Debbie Bliss mentioned that she has four people checking her patterns – and still errors creep in.

Perhaps we might be better off accepting that glitches are inevitable: “If debugging is the process of removing bugs, then programming must be the process of putting them in,” said Edsger W. Dijkstra.  Further, you can only test programmes by running them and observing whether they do what they are supposed to do.  This restates the value of sample and/or test knitters, who run the programme or knitting pattern in a live situation.  Other mistakes, hard to detect when reading through a pattern or copy-editing, are picked up here – but again, not all.  Sometimes experienced knitters miss things because they are so familiar with a designer’s work, or they subconsciously correct errors themselves as they go; this means that patterns can carry errors for several years, with the design team being none the wiser!  A knitter’s notebook is a sacred thing.

“If debugging is the process of removing software bugs, then programming must be the process of putting them in” – Edsger Dijkstra, the brilliant Dutch computer scientist who called it as he saw it.

Part of the ‘charm’ with programming errors is that they are always unique to the designer, editor, writer, creator – you name it.  There are certain things that you have to be alert to in your own creative work; you might forget to mention needle changes after ribbed welts, be vulnerable to getting pattern repeats tangled up when grading, or have a habit of dangling participles.  Here are three programming errors that might be familiar to knitters and crocheters.

Logic errors occur then the programme or pattern is correct – insofar as it gets you from A to B – but doesn’t yield the desired or expected results.  The needle change omission above is an example of a logic error: you will still end up with a sweater, but it won’t be knitted to the specified dimensions because of the difference in gauge.  The same would apply if you followed a cake recipe and the writer noted the wrong type of flour.  You’d still have a cake, but it might not taste or look as expected.  Logic errors are a type of runtime error, but they are so frequent in knitting and crochet that they deserve a space of their own.

Interface errors are the ones that technical editors, especially when checking for accessibility, are all over like a rash!  Interface errors occur when the knitter cannot use the pattern as intended.  Spelling errors, confusing inconsistencies in notation, e.g., using both sk2po and sl1-k2tog-psso, and layouts without enough line spacing cause interface errors.  The knitter finds it hard to engage with the pattern because the quality standards are poor, and consequently information cannot be processed correctly.

Encoding errors often occur during knitting, and apply to situations where the programme is correct and well written, but the configuration of the server or hardware has difficulty processing the programme’s script.  The first point is that this is not necessarily anybody’s fault, and skill and experience have absolutely no bearing here.  In a knitting context, knitters who are very used to one style of pattern writing may run into trouble when working from another style of pattern writing.  Presenting pattern repeats in chart form rather than written out in rows can also cause encoding errors.  Neither is wrong, and sometimes the solution is to include both styles to accommodate more knitters.  However, including both can lengthen the pattern considerably, and several pages can be overwhelming for some knitters, especially those with dyslexia or ADHD.

What is clear is that encoding errors are normally due to differences in communication style, and they cause problems because the knitter feels frustrated, gets stuck, and progress stalls.  Thus, the programme or pattern does not run; yes, this is another type of runtime error!  In addition, this stress or mental overload causes another runtime error – memory leaks or overwhelm that compromise short-term memory or RAM (random access memory).

Red and black ladybird on a hebe leaf in my garden.

I put encoding errors last because this type of programming error is difficult to eradicate despite the best laid plans.  You can be an experienced knitter, technical editor, teacher, designer, or writer, and no matter how much effort you put into understanding or creating a pattern, there will always be someone who needs more support with the instructions.  And again, the frustrating thing is that runtime errors are not necessarily anybody’s fault; their perpetuity restates the fact that communication is a two-way street.  What might be easy for one person to understand might be difficult for another, and this is no indication of an individual’s capabilities.

The best-case scenario is to ensure that runtime errors are well supported, if not anticipated.  Knitters having a hard time with a pattern may just need to take a break and come back to it; switch it off and then back on again.  Close background apps and free up RAM so that there are few, if any distractions (read: day-to-day life), and you can concentrate on the information in the pattern.  I once worked with a knitter who locked themselves away for as long as it took for them to set up the pattern repeat!

If designers are working with test knitters, or consulting a technical editor, let them know if you want them to pay particular attention to a specific area of the pattern or a technique and compensate them fairly for their feedback.  If you have the means, set aside time to create video tutorials or run virtual knitting surgeries, and be sure to let your customers know the support is there.

It’s impossible to overstate the fact that there will ALWAYS be bugs or glitches somewhere.  After all, computer programming is a type of design and form of creativity.  If you can’t have roses without thorns or aphids, and you can’t make omelettes without breaking eggs, then you cannot have programmes – patterns – without errors.

Aphids all over a rose bud in my garden, earlier this year.

7 Comments Add yours

  1. I really loved reading this post – I loved the comparison between pattern writing and coding, and and I think it’s definitely a true one. I do a lot of test knitting, and I always try to be attuned to errors in the code.

    1. Thank you very much Kath! 🥰

  2. Liz says:

    I really enjoyed this. I work in computer software doing software testing, quality assurance and user support. And I knit.. a lot. This made so much sense to me. Thank you!

    1. 🥰 thanks so much Liz! I especially appreciate hearing from someone who has a foot in both camps, so I’m glad I got this post right. 😊

  3. Alice says:

    I love this post and it’s a great comparison – there are so many similarities between craft and coding! In fact, I wrote a (somewhat tongue-in-cheek) post on a similar theme: why coding is like crochet. I hope it’s ok to share here: https://webscapegardener.co.uk/why-coding-like-crochet/.

    1. Thank you Alice – and share away! I will read your post when I have a moment 😊

Leave a Reply