<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Joni Smith</title>
    <description>The latest articles on DEV Community by Joni Smith (@joni_smith_e0a25ab69473fb).</description>
    <link>https://dev.to/joni_smith_e0a25ab69473fb</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4138913%2F4f6c47d6-cc87-4973-9392-3b673f81d744.png</url>
      <title>DEV Community: Joni Smith</title>
      <link>https://dev.to/joni_smith_e0a25ab69473fb</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/joni_smith_e0a25ab69473fb"/>
    <language>en</language>
    <item>
      <title>What Crochet Patterns Can Teach Us About Writing Better Instructions</title>
      <dc:creator>Joni Smith</dc:creator>
      <pubDate>Wed, 23 Sep 2026 07:23:32 +0000</pubDate>
      <link>https://dev.to/joni_smith_e0a25ab69473fb/what-crochet-patterns-can-teach-us-about-writing-better-instructions-4pfb</link>
      <guid>https://dev.to/joni_smith_e0a25ab69473fb/what-crochet-patterns-can-teach-us-about-writing-better-instructions-4pfb</guid>
      <description>&lt;p&gt;When I started looking at crochet patterns from a more technical perspective, I noticed something interesting: a well-written crochet pattern has a lot in common with good technical documentation.&lt;/p&gt;

&lt;p&gt;A crochet pattern isn't just a list of stitches. It is a set of instructions that needs to be interpreted consistently by another person. If one step is unclear, the final result can be very different from what the designer intended.&lt;/p&gt;

&lt;p&gt;That sounds surprisingly familiar to anyone who writes code or documentation.&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Repetition is the equivalent of a loop
Crochet patterns frequently contain instructions such as:&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Repeat rows 3–6 four times.&lt;/p&gt;

&lt;p&gt;For a crocheter, this is simply a way of avoiding unnecessary repetition.&lt;/p&gt;

&lt;p&gt;For a programmer, the idea is immediately recognizable: instead of writing the same operation over and over, we describe the repetition once and specify how many times it should happen.&lt;/p&gt;

&lt;p&gt;The same principle applies to technical documentation. If a process contains repeated steps, documenting the pattern can be much clearer than duplicating the same instructions.&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Abbreviations act like a small syntax
Crochet patterns commonly use abbreviations for stitches and actions.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;For example:&lt;/p&gt;

&lt;p&gt;sc = single crochet&lt;/p&gt;

&lt;p&gt;dc = double crochet&lt;/p&gt;

&lt;p&gt;ch = chain&lt;/p&gt;

&lt;p&gt;sl st = slip stitch&lt;/p&gt;

&lt;p&gt;These abbreviations make patterns shorter, but they only work when the reader understands the vocabulary.&lt;/p&gt;

&lt;p&gt;Programming works in a similar way. Developers can read relatively compact code because they understand the syntax and conventions behind it.&lt;/p&gt;

&lt;p&gt;For beginners, however, unexplained abbreviations can make either a crochet pattern or a codebase difficult to understand.&lt;/p&gt;

&lt;p&gt;That's why good documentation should define its terminology before relying heavily on it.&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;A pattern needs to be tested
A pattern can look correct to its creator and still contain a problem.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Maybe a stitch count is wrong. Maybe an instruction is ambiguous. Maybe the finished shape doesn't match the intended dimensions.&lt;/p&gt;

&lt;p&gt;This is why crochet designers test their patterns.&lt;/p&gt;

&lt;p&gt;The same principle applies to software documentation.&lt;/p&gt;

&lt;p&gt;If you write a setup guide, someone else should ideally follow it from a clean environment. If they get stuck because one step is missing, the documentation needs improvement.&lt;/p&gt;

&lt;p&gt;In both cases, the real test is not:&lt;/p&gt;

&lt;p&gt;"Does this make sense to the person who wrote it?"&lt;/p&gt;

&lt;p&gt;The better question is:&lt;/p&gt;

&lt;p&gt;"Can another person follow it successfully?"&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;The finished object is the output
There is another interesting similarity.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;With software, we write instructions and expect a particular output.&lt;/p&gt;

&lt;p&gt;With crochet, we follow instructions and expect a particular object.&lt;/p&gt;

&lt;p&gt;For example, when working on a structured bag design, the pattern may specify particular stitch counts, row sequences, dimensions, and construction steps. Changing one of those variables can affect the final shape.&lt;/p&gt;

&lt;p&gt;That makes crochet an interesting physical example of deterministic instructions.&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Good instructions reduce cognitive load
Whether you're explaining an API or a crochet project, the reader shouldn't have to constantly guess what you meant.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Useful instructions generally have:&lt;/p&gt;

&lt;p&gt;Clear terminology&lt;/p&gt;

&lt;p&gt;Consistent formatting&lt;/p&gt;

&lt;p&gt;Logical ordering&lt;/p&gt;

&lt;p&gt;Explicit assumptions&lt;/p&gt;

&lt;p&gt;Repeatable steps&lt;/p&gt;

&lt;p&gt;Expected results&lt;/p&gt;

&lt;p&gt;This is something I have become much more conscious of while working with crochet patterns.&lt;/p&gt;

&lt;p&gt;For example, I recently worked on a &lt;a href="https://www.etsy.com/de-en/listing/4568214011/crochet-bag-pattern-pdf-ribbed-crochet&lt;br&gt;%0A![%20](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/ahc4bv3ijtxymea4impv.JPG)" rel="noopener noreferrer"&gt;ribbed crochet bag pattern PDF&lt;/a&gt;, where the construction relies on creating a structured ribbed texture and following the instructions consistently across the project.&lt;/p&gt;

&lt;p&gt;The actual craft is very different from programming, but the documentation mindset is surprisingly similar.&lt;/p&gt;

&lt;p&gt;What developers can learn from craft instructions&lt;br&gt;
I think there is a useful lesson here for anyone who writes technical documentation.&lt;/p&gt;

&lt;p&gt;A good instruction set doesn't need to be complicated. It needs to be predictable.&lt;/p&gt;

&lt;p&gt;Whether the reader is:&lt;/p&gt;

&lt;p&gt;running a command,&lt;/p&gt;

&lt;p&gt;configuring an API,&lt;/p&gt;

&lt;p&gt;following a tutorial,&lt;/p&gt;

&lt;p&gt;or making something by hand,&lt;/p&gt;

&lt;p&gt;the goal is the same: remove unnecessary ambiguity between the instructions and the expected result.&lt;/p&gt;

&lt;p&gt;Crochet patterns gave me an unexpectedly practical way to think about documentation, testing, repetition, and user experience.&lt;/p&gt;

&lt;p&gt;I'm curious whether other developers have hobbies where the same principles show up outside programming.&lt;/p&gt;

</description>
      <category>documentation</category>
      <category>programming</category>
      <category>writing</category>
    </item>
  </channel>
</rss>
