I know I've been bad a blogger regularly, and it may be obvious from reading things here or talking to me that I've been knitting a lot. What is less obvious is that I've been writing a lot about knitting. While I'd like to do some meta posting about these projects, instead I'm going to just jump in with a bit.

---

I was getting my blood drawn last week--just routine--and the phlebotomist said "how are you doing with all the snow?" it had snowed almost five days ago, and while most of it had melted it was the first real snow of the year.

Most people didn't spend 3 years in Wisconsin, I guess. It didn't really register as that much snow.

We must rewind, because I didn't actually hear her correctly the first time and though she said "how are you doing with all this," and I just assumed that the "all this" was the omircon spike of the coronavirus pandemic in New York City.

I clarified, just because I'm not used to small talk about such enduring existential issues. After we chuckled, I said something like "oh, not much... Just knitting mostly."

She was intensely interested, she asked what I was knitting (sweaters) and she (a crocheter it turns out,) was interested in learning to knit. I did the only thing that was reasonable and said "there are a lot of good videos on youtube, and also there's this book called Knitting Without Tears by Elizbeth Zimmerman and you should read it, it's great." Good deed done.

In the course of this conversation she said "oh how many sweaters have you made?" I could tell that she was like "oh a couple," but the truth is somewhat alarming, and I also don't remember exactly.

"30 or 40, I think." This has the potential to be correct, though I'm not sure.

"Oh."

"Yeah, I dunno, I've been doing this for a while."

Also true. Lots of these sweaters were total rubbish, and since I knit my first sweater in 2003 or (or something,) and while I managed to make a number of sweaters that were really great, I also made a lot of sweaters that were really terrible in one way or another. The process of making sweaters better, in my experience is to knit one, and see what works and what doesn't work and then fix it in the next go round. While having nice sweaters to wear is a good side effect of knitting, the process is the important part.

This is one of the reasons why I buy yarn in larger lots (often by the kilo or more, so I can knit a few sweaters) and while I usually just cast on a for a new sweater (or pair of socks) as soon as I finish the preceding one. While this might be an extreme implementation of this idea, the general approach is perhaps more applicable.

---

I started writing this post a few days ago as a kind of introduction to what I hoped was going to be some kind of pithy instructions for knitting a sleeve, but I decided to split it out after it was clear that I'd gotten a bit carried away.

Then, last night, I came to a realization about a different sweater that I've been knitting for a couple of weeks. Basically I wanted to take the basic pattern for a sweater that I've knit a bunch of times before and update it to be more like the sweaters I've been knitting more recently: slim sizing, vnecks, set in sleeves for the shoulders.

I don't think it worked out: the sweater is a touch on the small side (but not unworkable), knitting the sleeve caps with short rows in two color patterns is frightfully difficult (and likely to look really messy in a part of the sweater where the eye is drawn to.)

I'm also not wild about the v-neck (as implemented) because I didn't account for the fact that in two-color knitting the stitches are more narrow (and therefore the row gauge is equal to the stitch gauge) and as a result the angle of the v-neck is shallower than I wanted.

Finally, and while this is tractable, I'm grumpy about the fact that I made the steeks a bit narrower than I should have and the've all been threatening to unravel in an unexpected way: there's some hubris here, as I did the "just cut, don't worry" method of steek preparation.

They don't all work out. 'I've put the sweater in a bag and I think I'm going to let it sit for a little while before I really cut my losses, but I think I'd rather knit something I'm far more excited about than slog through a sweater I'm unlikely to wear (and would be unable to give away given the sizing.)

---

To my mind, it's just as important to celebrate, learn from, and write about the sweaters that didn't turn out as it is the ones that did.

As I said in Knitting Catchup, I've been knitting a bunch recently--a few sweaters, and a bunch of socks--and I found myself writing a list of sweaters that I was thinking about knitting, and thought it'd be interesting to share. But first, some background...

---

I've begun a writing project that explores, in great detail, how to knit a very basic sock. I've knit socks here and there forever, but I think in the past year knitting lots of socks has become a thing and I think one of the most thrilling aspects of knitting is the way that repetition (at many levels,) gives you the space to develop a deep understanding of your project and I think this gives rise to craft. I definitely want to knit a bunch more socks, and also I've been toying more with the idea of knitting sets of socks, maybe on the order of 5 or 10 pairs (for myself and friends) so I can see what it'd be like to only wear hand knit socks.

The last sweater I finished was a bottom-up-raglan seamless number with a v-neck, and the whole process was a lot of fun and I definitely want to explore some variants on this. I've also been working on a colorwork sweater for a couple of weeks, and while I've enjoyed that a lot, I think that I'd like to mostly stick with a few more plain sweaters, to explore different shapes and also be able to have a collection of sweaters that I can wear most days during the cooler months.

Pursuant to both of these projects I've recently begun buying yarn in bulk, mostly un-dyed (either to stay natural or to be garment dyed at some point.) This affords reasonable and predictable options for getting really soft yarn. The first batch appeared over the weekend, so I'm itching to cast on a new sleeve!

---

Here's the list of sweaters that I'm interested in knitting:

• I'd like to explore knitting more bottom up yoke sweaters, I've never made the hybrid yoke sweater, and while i've done the set-in-sleeve option a few times, I haven't done the saddle-shouldered sweater yet.
• I'd like to give crew necks another go. Particularly with some of these silk blends, I think a nice crew neck could be fun to explore, both to see if I can tolerate wearing them. I've been doing a lot of collars with ribbing recently, and I think a crew neck with a rolled edge might be nice.
• While I sometimes find lots of garter stitch to be too densen and sometimes awkward, a little garter stitch edge here and there can be really fetching, and I'd like to explore what it'd be like to put more garter stitch in places, like as a v-neck collar or maybe even the lower hem of a garment. I think, for me the challenge is mostly in finding a way so that he extra depth of the fabric doesn't feel like it's flaring out.
• I've thought about doing a sweater that was entirely made out of 2 by 2 ribbing. This might be a terrible idea.
• I made a sweater last year that had garter rib on the yoke, but was plane otherwise, and I really enjoyed it, though it has some flaws (Henley neck that doesn't quite work, sleeves were a bit wrong,) and I'd like to play around with this idea, both with "garter rib for the yoke" but also more garter rib (in general,) including maybe a garter rib cardigan.

I'm excited. Looking back at this, I think I need to also pull together a list of more concrete pattern ideas rather than just a list of variables, but there's time! And I definitely can cast on a sleeve for fun!

I haven't been writing or blogging much in the past few months, but I definitely have been knitting a bunch. Things have been busy and overwhelming, in totally unexceptional ways, and my knitting has been a near constant companion in providing balance and focus in various ways.

I embarked in the late spring in a kind of epic project: I bought a kilo of a lovely gray fingering weight Silk/Yak/Merino blend, and promptly started a cabled sweater based on Alice Starmore's Na Cragga sweater (the cover of Aran Knitting). I changed a lot: the gauge (ran weight to fingering) and the construction (knit flat with pieces to in the round) and the shape (tapered body, short rows across the back, set-in sleeves and saddles,) and monkeyed with the pattern (added two repeats of the center panel, dropped one of the patterns, extended the ribbing pattern into the body of the sweater,) and made a v-neck. I kind of stalled out on the project, at roughly the underarms, in June and took a few months off of regular knitting.

In the late summer, as delta began to spike here, I started knitting socks again. I've always loved socks, and have gotten really into knitting really plain cuff-down socks with medium length ribbed cuffs. I've knit maybe 20 pairs of these socks, and while I've taken a bit of a sock-knitting break in the last couple of months--I guess during the depths of winter and the omicron spike--I definitely hope to knit a bunch more socks.

In the mean time I've been working on two sweaters:

• a second sweater that I just finished knit out of the second half of the aforementioned kilo of Silk/Yak/Merino. I ran out of yarn on the collar which of course necessitated ordering more of this yarn, which is just utterly delightful. It's a bottom-up raglan sweater with a v-neck. Nothing else special, and it's so comfy and soft in every way. I'm not sure I'm sold on Raglan shaping, but I'd forgotten how much fun this construction is.
• I started a two-color pull-over using some of my favorite color patterns from Norwegian and Turkish patterns. I'm almost to the shoulder, and the plan is to knit set in shoulders and sleeve caps (short rows!) with a v-neck. This is the first color work sweater I've made in years, and it's been really fun and engaging to knit this sweater. I'd also given away almost all of my previous colorwork sweaters and they are very much my thing, and while I don't know that it's the kind of thing I want to focus on, making one of these every so often seems good.

There have been a few things that I've learned about myself as a knitter recently:

• I don't really enjoy knitting cables: the dense fabric rarely appeals to me as a sweater wearer, anything that isn't really simple ends up breaking up the rhythm in a way that I find distracting and the result is that knitting feels like a chore.
• I'm no longer afraid of grafting as I once was. I seem to only be able to really do it effectively if I hold the "right" sides together and graft from the "inside" of the garment (sock, sweater/etc,) but this seems to actually be fine in practice. This makes seamless bottom up sweater (as well as socks) much more approachable. In the past I struggled through it or tricked someone into doing it for me (or used 3 needle bind-offs.)
• I did a lot of sweaters with open-henly-style collars for years, because I often find that crew neck sweaters are too warm and otherwise overwhelming. Since I started on this path, I've begun making sweaters out of fingering weight yarn, and have switched to the v-neck as a solution for the "more open" neck problem. I think this demands more investigation.

In an upcoming post, I'd like to explore some upcoming knitting projects and the design questions that I've been contemplating.

Stay tuned!

Short rows are this little magic thing that you can do in hand knitting where you knit a row over only some of the stitches to create a piece of fabric that is longer in one part than in another, and also when coordinated correctly a sequence of short rows can cause the fabric to curve and bend. It's makes things possible in hand knitting that aren't at all possible using other textile process, because you're creating a piece of fabric that is a custom shape in three dimensions. Short rows appear for lots of reasons: dropping the bottom edge of the sweater, sloping the shoulders of a sweater, forming a top-down-sleeve cap, or to turn a sock heel, for example.

The problem with short rows, is that it can be quite difficult to hide them in an existing fabric, because there's a little gap or hole where the short row starts. Solving this little problem has given rise to an entire discipline of knitting techniques. Most of the time, after knitting a short row, you "wrap" the next stitch, which you slip and move the yearn around, as the basis of a transition. This anchors the yarn from the short row, and helps reduces an awkward effect on the stitches that you knit.

The problem is that the "wrap" is (often) visiable in your knitting, so that's in ideal. The options are:

• in garter stitch the best thing to do is to just ignore the wrap. If the tension of the wrap itself is right, the wrap doesn't look out of place, and you can just ignore it.
• most of the time you want to "process" the wraps, by picking up the wrap and knitting it together with the (now formerly) wrapped stitch. Getting the tension on this is quite hard, though you can twist the wrap or clean things up in the next row most of the time. If you're having trouble with wrapping:
  • consider wrapping in the other direction. So that you move the yarn to the front of the piece before or after slipping the stitch, depending on what you're presently doing. In my practice, wrapping front to back is slightly tighter than wrapping back to front, but I think this depends on your hands a bit.
  • rather than wrapping the stitch, a small yarn over can serve the same purpose, as long as you're sure to knit the yarn over with the stitch that was not part of the short row. Use this if your wraps are too tight.
• for sock heels, and in some other situations, you can skip the wrap, but slip the first stitch of the short row and decease the short sliped stitch into the next (non-short row) stitch on the next row. This works only in situations where you can stand to decrease 1 stitch for every short row turn.
• Some folks enjoy not processing the wraps, in situations where you're knitting a sleeve cap off from the shoulder down in a sweater. You can see the wraps, but because you're doing lots of sequential short rows, it looks like a pattern.

As a degenerate emacs user, as it were, I have of course used org-mode a lot, and indeed it's probably the mode I end up doing a huge amount of my editing in, because it's great with text and I end up writing a lot of text. I'm not, really, an org mode user in the sense that it's not the system or tool that I use to stay organized, and I haven't really done much development of my own tooling or process around using orgmode to handle document production, and honestly, most of the time I use reStructuredText as my preferred lightweight markup language.

I was thinking, though, as I was pondering ox-leanpub, what even is org-mode trying to do and what the hell would a product manager do, if faced with org-mode.

In some ways, I think it sucks the air out of the fun of hacking on things like emacs to bring all of the "professionalization of making software" to things like org-mode, and please trust that this meant with a lot of affection for org-mode: this is meant as a thought experiment.

---

Org has a lot going on:

• it provides a set of compelling tools for interacting with hierarchical human-language documents.
• it's a document markup and structure system,
• the table editing features are, given the ability to write formula in lisp, basically a spreadsheet.
• it's a literate programming environment, (babel)
• it's a document preparation system, (ox)
• it's a task manager, (agenda)
• it's a time tracking system,
• it even has pretty extensive calendar management tools.

Perhaps the thing that's most exciting about org-mode is that it provides functionality for all of these kinds of tasks in a single product so you don't have to bounce between lots of different tools to do all of these things.

It's got most of the "office" suite covered, and I think (particularly for new people, but also for people like me,) it's not clear why I would want my task system, my notes system, and my document preparation system to all have their data intermingled in the same set of files. The feeling is a bit unfocused.

The reason for this, historically makes sense: org-mode grew out of technically minded academics who were mostly using it as a way of preparing papers, and who end up being responsible for a lot of structuring their own time/work, but who do most of their work alone. With this kind of user story in mind, the gestalt of org-mode really comes together as a product, but otherwise it's definitely a bit all over the place.

I don't think this is bad, and particularly given its history, it's easy to understand why things are the way they are, but I think that it is useful to take a step back and think about the workflow that org supports and inspires, while also not forgetting the kinds of workflows that it precludes, and the ways that org, itself, can create a lot of conceptual overhead.

There are also some gaps, in org, as a product, which I think grow out of this history, and I think there are

They are, to my mind:

• importing data, and bidirectional sync. These are really hard problems, and there've been some decent projects over the years to help get data into org, I think org-trello is the best example I can think about, but it can be a little dodgy, and the "import story" pales in comparison to the export story. It would be great if:
  • you could use the org interface to interact with and manipulate data that isn't actually in org-files, or at least where the system-of-record for the data isn't org. Google docs? Files in other formats?
• collaborating with other people. Org-mode files tend to cope really poorly with multiple people editing them at the same time (asynchronously as with git,) and also in cases where not-everyone uses org-mode. One of the side effects of having the implementation of org-features so deeply tied to the structure of text in the org-format, it becomes hard to interact with org-data outside of emacs (again, you can understand why this happens, and it's indeed very lispy,), which means you have to use emacs and use org if you want to collaborate on projects that use org.
  • this might look like some kind of different diff-drivers for git, in addition to some other more novel tools.
  • bi-directional sync might also help with this issue.
• beyond the agenda, building a story for content that spans multiple-file. Because the files are hierarchical, and org provides a great deal of taxonomic indexing features, you really never need more than one org-file forever, but it's also kind of wild to just keep everything in one file, so you end up with lots of org-files, and while the agenda provides a way to filter out the task and calendar data, it's sort of unclear how to mange multi-file systems for some of the other projects. It's also the case, that because you can inject some configuration at the file level, it can be easy to get stuck.
• tools for interacting with org content without (interactive or apparent) emacs. While I love emacs as much as the next nerd, I tend to think that having a dependency on emacs is hard to stomach, particularly for collaborative efforts, (though with docker and the increasing size of various runtimes, this may be less relevant.) If it were trivially easy to write build processes that extracted or ran babel programs without needing to be running from within emacs? What if there were an org-export CLI tool?

I can't quite decide if this title is ironic or not. I've been trying really hard to not be a build system guy, and I think I'm succeeding--mostly--but sometimes things come back at us. I may still be smarting from people proposing "just using docker" to solve any number of pretty irrelevant problems.

The thing is that docker does help solve many build problems: before docker, you had to either write code that supported any possible execution environment. This was a lot of work, and was generally really annoying. Because docker provides a (potentially) really stable execution environment, it can make a lot of sense to do your building inside of a docker container, in the same way that folks often do builds in chroot environments (or at least did). Really containers are kind of super-chroots, and it's a great thing to be able to give your development team a common starting point for doing development work. This is cool.

It's also the case that Docker makes a lot of sense as a de facto standard distribution or deployment form, and in this way it's kind of a really fat binary. Maybe it's too big, maybe it's the wrong tool, maybe it's not perfect, but for a lot of applications they'll end up running in containers anyway, and treating a docker container like your executable format makes it possible to avoid running into issues that only appear in one (set) of environments.

At the same time, I think it's important to keep these use-cases separate: try to avoid using the same container for deploying that you use for development, or even for build systems. This is good because "running the [deployment] container" shouldn't build software, and it'll also limit the size of your production containers, and avoid unintentionally picking up dependencies. This is, of course, less clear in runtimes that don't have a strong "compiled artifacts" story, but is still possible.

There are some notes/caveats:

• Dockerfiles are actually kind of build systems, and under the hood they're just snapshotting the diffs of the filesystem between each step. So they work best if you treat them like build systems: make the steps discrete and small, keep the stable deterministic things early in the build, and push the more ephemeral steps later in the build to prevent unnecessary rebuilding.
• "Build in one container and deploy in another," requires moving artifacts between containers, or being able to run docker-in-docker, which are both possible but may be less obvious than some other workflows.
• Docker's "build system qualities," can improve the noop and rebuild-performance of some operations (e.g. the amount of time to rebuild things if you've just built or only made small changes.) which can be a good measure of the friction that developers experience, because of the way that docker can share/cache between builds. This is often at the expense of making artifacts huge and at greatly expanding the amount of time that the operations can take. This might be a reasonable tradeoff to make, but it's still a tradeoff.

I end up reviewing a lot of code, and while doing code review (and getting reviews) used to take up a lot of time, I think I've gotten better at doing reviews, and knowing what's important to comment on and what doesn't

• The code review process is not there to discover bugs. Write tests to catch bugs, and use the code review process to learn about a specific change, and find things that are difficult to test for.
• As yourself if something is difficult to follow, and comment on that. If you can't figure out what something is doing, or you have to read it more than once, then that's probably a problem.
• Examine and comment on the naming of functions. Does the function appear to do what the name indicates.
• Think about the interface of a piece code:
  • What's exported or public?
  • How many arguments do your functions take?
• Look for any kind of shared state between functions, particularly data that's mutable or stored in globally accessable, or package local structures.
• Focus your time on the production-facing, public code, and less on things like tests and private/un-exported APIs. While tests are important, and it's important that there's good test coverage (authors should use coverage tooling to check this), and efficient test execution, beyond this high level aspect, you can keep reading?
• Put yourself in the shoes of someone who might need to debug this code and think about logging as well as error handling and reporting.
• Push yourself and others to be able to get very small pieces of code reviewed at a time. Shorter reviews are easier to process and while it's annoying to break a logical component into a bunch of pieces, it's definitely worth it.

I somehow managed to knit the body of a sweater in like 10 days, and am once again knitting sleeves. I also want to re-knit the cuffs of the last sweater, because I'm coming to terms with the fact that I'm not really happy with them, and my current plan is to knit the sleeves of my next sweater before knitting the body, which means I have a little bit of a queue for knitting sleeves.

In preparation I measured a lot of sleeves of sweaters that I've knitted (and still have, to try and figure out what I like. Here are my conclusions:

• I realized that regardless of the shoulder shaping, the length of the sleeve should be basically the same. This is based on the assumption that the shoulder fits, and sometimes you can compensate for an illfitting shoulder by modifying the length of the sleeve, so take it with a grain of salt.
• I've been measuring sleeves, on drop shouldered garments from the shoulder seam to the cuff, and for other shoulder shaping, from the underarm to the cuff.
• I prefer sleeves that are a little bloused (e.g. bigger, with a more aggressive cuff,) because I like to wear sweaters over shirts, so having a bit more room makes things more comfortable. Also having floppy cuffs is not great.
• The sweaters that I like the most, seem to have 21 inch sleeves total with 1-2 inch cuffs. I try and spread the decreases out, as evenly as possible. The cuffs seem to be between 8 and 9 inches around (ideally,) and shoulder apertures tend to be between 18 and 20 inches around.
• I'm tentatively coming out in favor of knitting all sleeves from the shoulder down to the cuff, but I do want to give it a shot going the other way at least a couple of times before I'm definitive on that subject. When you knit the sleeves first of a sweater, the process of knitting the sleeve dictates the yoke of the sweater, which means if you're off a bit in the sleeve the whole sweater seems off. Knitting sleeves after the yoke, means you don't have to figure out the entire sweater when you're knitting the cuff.
• Separating thinking about the sleeve cap from thinking about the sleeve, is conceptually useful (sleeve caps take a while, the process of knitting them in the round is different,) even if this doesn't make a lot of sense when you're actually knitting or thinking about a garment.