Programmes and Patterns: Or, What Bugs Us About Knitting

Share this post or save it for later:

“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.

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).

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.

Share this post or save it for later: