Code == Knitting?

FullSizeRender (2)

“Knitting is basically coding”. Its a comparison I have heard banded around by a couple of senior tech experts and one that I frequently use myself to either tech scared knitters or craft scared coders; but how true is it?

A knitting pattern is essentially a computer program: it defines what you need to do in the correct order to achieve something. The difference between the computer program and a knitting pattern is the thing that carries out the pattern. In one it is a computer (with no knitting needles), in the other, a human (with knitting needles).

Really? It’s that simple?

Yes, and to demonstrate this, I will now write out two different knitting patterns, in pattern style and ruby style, so you can see that there is very little difference!

Knitting Pattern:
“Cast on 126sts.
Work in K 1, P 1 rib for 1.25ins.
Work in stocking stitch for 3ins, finishing at end of a P row.
Next row: K two stitches together, K across row.
P two sts together, P across row.
Rep until you have 10 sts.
Cast off.
Thread yarn through top 10 sts, pull together and stitch down the side to finish piece.”

FullSizeRender (1)

Computer Program:
hat =
hat.cast_on(stitches: 126)
hat.rib_stitch(length: 1.25, knit: 1, purl: 1)
hat.stocking_stitch(length: 3)
until hat.stitches == 10
hat.decrease(increment: 1)


And in human language:
Cast on 126 stitches onto your needle
Work in 1X1 rib stitch until your work measures 1.25 inches
After this, work in stocking stitch (purl one row, then knit the next) for a further 3 inches
On a knit row, knit the first two stitches together and knit to the end of the row.
On the next row, purl the first two stitches together, and continue along the row.
Repeat this (decreasing) until there are only 30 stitches left on your needle
Then cast off
Thread the yarn through each of the top stitches and pull tight to gather the top of the hat. Then stitch the two sides together to finish the hat.

The result – ONE HAT!

So – can people who knit code and vice versa?

Yes! It’s all about taking it one step at a time and not being put off by the big picture. Tell me to knit a jumper and I will run a mile – tell me to just knit one stitch – then if I repeat that a gazillion times to make a jumper – much easier to deal with!

Its the same with programming:
“Can you build me a website?” – “Errr…”
“Can you just take a couple of these lines of code and repeat them until you have a website?” “Yes!”

Continue reading

My Guide to Git, Part 1


When I first started at my current company I soon discovered there is nothing more dangerous to a codebase than a inexperienced dev with git access keys. On my second day I accidentally deleted my entire days work because of some command.  Of course I have no idea how I did it and I was far too scared to admit it to my boss and so I promptly did the whole days work that night amongst many frenzied google searches and silent prayers that no one in the team would realise the fraud of a developer I was.

Of course – it was fine, after a couple of days I worked out how I had deleted everything and made several notes to never do it again. Which I did. The next day.

Undoubtedly one of the hardest things to get to grips with when you start learning to code is Git. Unlike markup and programming languages, version controlling is not visual. Therefore, if you are unused to working from a programmatic viewpoint, it is incredibly hard to conceptualise. There are tools that can make this easier (git guis – I’ll get onto them in a future post) but even these require a fairly good knowledge of what on earth is going on in order to understand.

In this post – I’m going to take you through the metaphors I developed when I was first trying to get my head go with git, and in the following posts I detail my git toolbox – a nice little dictionary of my favourite git commands.

So what on earth is going on?


So git is a ‘Versioning Control System’, (ohhh, thats some excitingly dull words right there). This basically means that it is a tool that, when you ask it to, makes note of the state of the folder or file you are working on.

So imagine you are playing a computer game – every time you reach a checkpoint, the game saves your progress to that point. That is exactly what git does – except it does more. It keeps a record of every checkpoint you have reached – which means you can go back to that point.

Say you reached a hallway in Hogwarts (yup, we are playing a HP PC game now) and saved the game, you proceeded down the left corridor. This turned out pretty well, you found a Wizard card and a caldron full of beans, but you also found a venomous tentacular and you fainted. So instead you decide to go back to the checkpoint and try the right corridor. This turns out well as you find a stamina boosting chocolate frog – giving you enough life to face the venomous tentacular.

Good that you got that frog - as getting past Peeves here is a bitch
Good that you got that frog – as getting past Peeves here is a bitch

Lets get more complex

So, we have established the idea of these check points (or ‘commits’ as they are really called) and the ability to navigate around them, however, this does not fully appreciate the ‘different version’ bit of version control!

So now lets imagine our file as a tree, with a main trunk of work with regular commits. The trunk is your ‘master’ branch, this includes all the changes are ready and safe to be in your finished website.

But say you want to develop a new part of your website? Maybe a brand new feature.

In this instance your website is a very simple site where you list your favourite people from history. Ah, but then you think: “There are simply not just enough reference to Isabella, the She Wolf of France, on the internet” so you decide to build a hall of fame for the most badass monarchs.

Centuries before Shakira there was Isabella. She was badass.

However, halfway through building your hall you realise that you don’t have a good way to assign images to entries in your website. These are two very different features your website needs, and so they don’t necessarily need to be worked on at the same time.

So – you create two branches from your master tree – a hall_of_fame branch and a better_images branch. You can work on both projects independently, switching between the two easily, then, when they are done – you can merge them into master and push it to live.

The great thing with this branch approach is that you can continue with the general day to day fixes to the site easily. Because the code for these new features is on a seperate branch – you can easily adjust the spelling mistake you made on your last entry (Joan of Arc and John of Arc are very different people) without polluting your codebase with half baked files relating to a hall of fame.

So – got that?

I hear your silence and take it as yes.

Next time – collaborating with branches!