Development is like a jigsaw puzzle

Published: Nov 5, 2019 by C.S. Rhymes

Last week I decided to buy a jigsaw puzzle and as I was building it, I had a thought that puzzles share a lot of the aspects of development. After all, a jigsaw puzzle does require a lot of problem solving skills.

Finding the edges

When beginning a puzzle you often start by finding all the edge pieces first. In development this is a lot like defining the scope of your project. The scope, like the edges of the puzzle, is the container that all your work will sit within.

You need to define your scope before you start otherwise you could end up spending time working on something that will never make the final project.

You need to define that you are building a jigsaw of a landscape and that its a rectangle shape before you start otherwise it is doomed to fail from the outset. The edge pieces may just about fit together to make a square, but the pieces inside the puzzle are never going to fit properly.

Splitting tasks up

When you start working on a puzzle it can often feel overwhelming looking at all the pieces in the box. This can also be true of a new development project where you know you have so much to do at the beginning. One way of making this feeling subside is to create a strategy and split the puzzle up into smaller sections.

Spending some time sorting through the pieces first and grouping the pieces into smaller piles, such as one for the mountain and one for the lake, one for the grass area in the foreground, will leave you with more manageable tasks. As each section of the puzzle is completed the puzzle starts to come together as a whole.

If you are working on a development project I would follow the same methodology, splitting the project into sections. If you find that a particular section is still too big you can then split it further into smaller sections again. This is similar to epics, user stories and tasks in agile development.

Acknowledging your mistakes

Sometimes you spend a long time working on a particular section of a puzzle, and you think that you have made real progress, but then you are left with some pieces that don’t quite fit no matter how hard you try. You can either carry on and hope they will fit in somewhere else later, or you can acknowledge that you have made a mistake and start taking the puzzle apart slowly and try again.

Every development project will have some bugs in it, but just because you have spent a long time working on a particular piece of code, you also need to acknowledge when its not quite right and needs a bit more work. Sometimes this requires a complete rewrite, but often you can salvage a lot of what you have built and correct the bug with a bit of refactoring to make the pieces fit together in a slightly different way to produce the desired result.

In the zone focus

Sometimes I felt a strange sensation where I could see a particular piece within the box and somehow know exactly where it went without thinking about it too much. If there is a particular pattern or area of the puzzle, such as a mountain or a lake in my case, I knew I was looking for pieces with a particular shade of brown or blue and I could tell that a piece I saw was the perfect shade along with the perfect shape.

I sometimes have this feeling when coding too. When I get into the zone, I feel like I can write code without stopping to look at documentation or having to think about how it should work. I just wish I knew how to get into this zone more often. I find eliminating distractions by listening to music through my headphones and closing emails and slack can help.

Getting stuck

When you are stuck with your puzzle, sometimes it’s easy to pick it up and throw it back in the box, put it onto the shelf and forget about it, but instead, it’s worth taking a break, then coming back to it with a fresh pair of eyes and a clear head.

When I am debugging I often find myself going too deep into code, having 10 different files open in the editor, jumping between them trying to work out what isn’t working. I find this quite frustrating, hoping that the answer will appear if I keep opening files and jumping around the code base.

When I finally realise this is what is happening, I close all the files, leave my desk and go and get a cup of tea. Quite often an idea will pop into my head when I’m not actually thinking about solving the problem. Trying to force yourself to find the root cause of a bug can often lead you further away from the problem instead of getting nearer.

Asking for help

Another solution is to ask someone for help. You don’t have to get them to build the whole puzzle for you, but a little help to point you in the right direction.

Sometimes, just explaining the issue to someone else, such as there aren’t enough blue pieces for the lake, can help you identify where the problem is, such as the blue pieces for the sky and lake have become mixed up.

This is often known as rubber duck debugging, where explaining the issue to someone or something, such as a rubber duck, leads you to seeing the solution.

Finishing touches

Placing the final puzzle pieces is such a good feeling. Finally, once all the pieces are in place you can sit back and admire your hard work. Being a developer can yield the same great feeling of satisfaction when you have completed your project, knowing the hard work you have put in to acieve your goal.