Second Sock Syndrome | Hacker News Reader

Second Sock Syndrome

sheepamongwolves.net

188 pointsnickdrozd33 comments

Cache/archive/mirror: https://archive.is/jrQ4n#selection-727.0-731.211

In short:

> What is the Second Sock Syndrome?

> SSS usually refers to the inability to produce complete pairs of socks. Knitting the first sock usually goes quickly. But the second one seems to drag on, never gets completed or even cast on in the first place.

It's entirely a knitting blog, but surely this was posted here as it's a problem I know I face in all sorts of domains, including programming. Once the interesting part is figured out, finishing the project is the tough part.

It seems similar in name only to Second System Effect, from Fred Brooks.

The challenge for your second sock is to accurately repeat your process of the first one. The challenge of the second system--where you reimplement something from scratch maybe--is to keep the scope limited but you are trying to depart from the mistakes of the first one.

https://adamo.wordpress.com/2019/02/03/the-second-system-eff...

Yeah, but maybe you should be making a second system instead of a second sock.

This is valid for team paradigms— building a successful team requires understanding what is interesting to each candidate member and building the group where most product engineering falls under the different members’ ‘interesting’ slices

Being creative and innovative have their downsides. Most of them find it impossible to do repetitive tasks.

Doing repetitive/ tasks is excruciating unless I am doing it for something I care about (i.e. a start up idea or project of my own). If I know I'm doing something for "the man" or something I don't have equity in it gets really bad.

I find the solution is to use my half-finished product, or let someone else use it. The problems they, or I, run into tell me what to complete, or what to add, or to just start over and do it again.

Any time I have doubts about how to finish, what that really means is I need more feedback and take a completely fresh look at my priorities.

Your summary - and, importantly, the title here on HN - skips the important part: 'and How to Fight It'

As such, I was going to skip the article. Fortunately, I saw mumblemumble's comment below

https://news.ycombinator.com/item?id=22407569

The take-away for developers is perhaps this: There are a lot of ways to deal with the boring part of a job where there's not much new or creative stuff happening. Some are better than others.

I'd break the suggested strategies into a few general categories. You can be so intrinsically motivated that you never really encounter this problem in the first place (1). You can play psychological games to try and make it harder to lose interest (2, 3, 4, 8, 9). You can alter the workload in a way that makes it more interesting, but may cause quality to suffer (5, some 7, 10, 11, 12). You can rearrange the work in a way that actually creates more work, but also helps it stay interesting for longer (6, some 7, 10, 11, 12).

I find that those last two categories tend to go hand-in-hand in programming, too. So finding ways to help yourself just muscle through the boring part really is preferable in a professional setting.

OTOH, for fun projects, both sock knitting (and mittens) and development, I tend to go for those latter strategies. The corollary here is that I try not to knit socks for others, and you probably shouldn't take a dependency on anything I'm not getting paid to write.

In SW development we try to avoid this by building a framework where the second instantiation comes at almost no extra cost. However, we have the problem where we start building the framework and then never solving the original problem...

Very common in game development. Someone focuses too much on the engine but forgets the game. Or focuses too much on the graphics pipeline but forgets gameplay.

A portfolio of completed projects is actually a thing worth having in game dev. Doesn't necessarily mean a project polished to the nth degree but instead, a project that is a cohesive whole. (I'm not saying polish is a bad thing...)

Notes to the pedantic: this doesn't exclude a portfolio of specific examples. eg a set of graphics assets or level assets. Or a graphics library. But the thing needs to have been "done" and not in perpetual "there's this obvious giant hole where this important functionality is missing". And yes I've had success with incomplete projects but they were fully playable just with "programmer art".

While this is definitely a problem developers face, many of the solutions in this article only apply to socks. HN, do you have any tips for completing personal projects when they stop being fun?

One of the mentioned approaches is "give up". For personal projects this is a totally valid approach. If you're doing it for fun and/or learning, finishing need not be a goal.

Sometimes this is true. I've started several side projects to learn a new programming language. So I created 2-3 projects with the different frameworks, never feeling guilty if I should give up or restart with a different approach. But the 4th time, though, it just "clicked", and I'm launching a new project with a new programming language + framework soon, and I intend to monetize it on day 1.

If I have very few customers, it's a portfolio project. If I have a bit more, it'll break even and I can dedicate some time to it. If it grows even more, I'll try to make a business out of it.

This is valid when your only goal is to learn a thing.

But I think it's really important to remember that finishing is itself a skill that is worth learning and if you don't finish things, you gain no practice at that skill. Writing the first 80% of a hundred programs may give you a lot of skill in different domains, but it won't give you the ability to finish a program in any of them and get it to a point that it can benefit other humans.

I struggle with this all the time. The only thing that I have found to mitigate it is contemplating the public embarrassment of the resulting failure or lack of completion. This mental anxiety usually gets me moving. Not the best solution, but for now it's about all I have.

You may want to check out a guy named Robin Sharma. You can find a bunch of his videos on YouTube. No need to pay for anything. The videos contain pretty much all you need. I'm trying to work on incorporating his ideas into my routines. What he talks about really is all about mentality and what sets apart superachievers from everyone else.

EDIT - just realized your question was specifically aimed at personal projects. The second paragraph still applies, in that case, but you can ignore the first as there won't be any embarrassment from personal projects not being completed. Oh, that just reminded me...for the personal stuff you can use one of those sites that is designed to hold you accountable by bringing in family/friends to monitor your progress and you set a clear goal with a clear penalty if you fail to deliver, and they are there to see if you follow through or not. The website I am familiar with is https://www.stickk.com/ but I'm sure there are others.

My grandmother used to reward herself for completion. Basically, when you complete it, you buy yourself a treat or do something pleasant for yourself (get a cup of vine and bubble bath, whatever).

I'm notorious for having many half-finished personal side projects sitting around; some software, others hardware.

If someone else talks about a similar topic (e.g. a related article gets onto Hacker News, or someone asks "when will it be ready?") then I'm much more motivated to actually finish it.

If I need to find a job, I often try to write up the documentation and post Show HN projects. Occasionally I'll do that anyway, but it's easier when I'm in "writing" mode anyway (if I'm writing cover letters and emails).

The best motivator is to have someone else to work on a project together. Seeing the EspUSB WiFi mouse & keyboard through to production is something I wish I could witness, but I just can't get past the paperwork alone.

As somebody who has been in art school I think "putting it out there" in some way can do wonders.

E.g. plan to put it on your homepage or github. Or if it isn't suitable look to present it at some event, a local hackerspace or even to your friends or relatives.

By having a goal like that you are forcing yourself over the edge while at the same time making visible what you are doing all the time which both benefits you in the end.

While this can be scary, with the right audience it can be extremely gratifying to get recognition for what you're doing.

Edit: of course you really don't need to finish every project you start. Sometimes you learn so much during a project that you would actually so it differently if you were to start again.

The thing about knitting is that you can't avoid knitting that second sock. In technology, we can just build a machine that copies the first sock.

The problem we face is that it usually takes an order of magnitude more time to build that machine than to actually knit the second sock...

You build an abstraction layer, yes:

    knit.sock(.left)

However, your next roadblock would be the framework itself: you throw new tasks at it that it can't handle, you start adding more states and conditionals, more lambdas and/or polymorphism until it gets so ugly you start hating the framework (and yourself) and realize you will never finish it. Time for a big rewrite.

One of the essential skills in software engineering is the ability to carefully craft beautiful and minimalist abstraction layers that won't let you down.

Knitting is just a monoid in the category of endofunctors. Once you realize that a sock is just a piece of yarn transformed through a series of knots, you can determine that it's topologically equivalent to where you started and you don't need to knit the other sock.

A knit is not a knot.

Tail-recursive yarn. Service mesh.

I don't know specifically about socks, but with other things, I get through the repetitiveness by optimizing the process, and then each successive output gets quicker or easier. You never do it the best way the first time, and then the game becomes how can I do this with less steps or less effort, what are the tricks? Eventually you get up against the wall and there aren't anymore gains to be made, but at that point it's usually become mindless muscle-memory, and it isn't really much of a chore; it's actually usually quite enjoyable.

This maybe a good strategy when you need to churn out a series of items, but what's interesting about the 2nd sock problem is that its very hard to justify the effort in optimizing the process just to make 1 more sock.

I've found that often "lacking motivation" is a misinterpretation of "lacking understanding of a fundamental idea." Do you really lack motivation to implement clock recovery in your toy software modem? Or do you not know how digital PLLs work.

IMO knitting is closer to CRUD dev: it's a little challenging but it's mostly just reading/following patterns and counting (although this is coming from someone who crochets and doesn't knit.)

One related "problem" I've encountered is when the 2nd iteration of something turns out better than the 1st (and the 3rd, 4th, 5th get subsequently better). Perhaps not as big of a problem when you're making stone tiles, or some other output, but it sure does suck to have one good sock and one "eh" sock.

The second sock syndrome is perhaps never an issue if you have a real environment of collaboration, comadrerie or even apprenticeship. Just more yarn and code by yourself is not going to cut it for long unless you have an external motivator.

The chemicals which activate our sense of happiness more than anything is the feeling when we see our friends and family have breakthroughs and achieving a goal. It’s probably a bigger factor for the one that is trying to reach that goal.

This is perhaps why twitch is so popular, even in an activity such as gaming which has been made to be fun by itself alone, socialization is a force multiplier.

I can have a sense of this at different work places, people are so focused on result and not on the process that people stop caring of craftmanship and disciplin. In the long term it makes the company rot from the inside with high turn over and lost knowledge and increase of technical debt and finally a losing business.

I love how an article about knitting gets related so quickly to other domains (by reading the comments). I had to search on that blog to understand that it wasn't related to a technical domain.

However, from the title I thought it was about the law (if it's not a law, it should be) that says that if a pair of sockets in a drawer are put together you can easily find the pair. Instead if you find one of the socks of the pair, the other sock of the pair, while still in the drawer, is mysteriously teleported into another dimension, never to be found again.

https://archive.md/jrQ4n

https://web.archive.org/web/20200224190006/https://sheepamon...

You could make it challenging, like knit the second sock in a mirror image, reversing the knitting direction that you have learned and practiced.

That's example 6 on the list.

Reply on news.ycombinator.com