Cutting Code

Woodwork

Sometimes I craft. Embracing the experience and process of breaking a problem down into code that can be committed to “paper”. When I am crafting code I care about how the code reads, how the pieces fit together, whether the pieces are rigorous and tested well. When I am crafting code I think, analyse, think, analyse, think, take two steps forward and three steps back.

It’s slow progress initially, but over time things get easier. My understanding of the problem improves. The pieces I have already built tend to stay working. It can be deeply satisfying, but that satisfaction is mostly in the code, not in the result itself.

Whittling

Sometimes I create. To say it’s an art perhaps doesn’t give real artists enough credit, but it is my art. Often I don’t know why I am creating. Some thread of thought, or new piece of technology, or something has come to my attention and I have to play with it, to see how it can be bent and forced and shaped into something creative.

From the outside the process probably appears chaotic, and that’s because I don’t care about the process, I don’t even think about it. When I am creating I have no goals, no endpoint, no desire, just a drive to experiment. I don’t think about the code I am writing. I don’t care if it’s “good” or “bad” or “ugly”, I almost don’t consider it my code. It’s like I am taking a random walk through a scrapheap of code fragments, picking up the interesting pieces and smushing them together until the result interests me in someway.

For me, creation is a fast process. An hour, an evening, maybe the best part of a day. Not fast in terms of “how long does it take to get to a specific goal”, but fast in terms of change. New code is written quickly, without thought, code is thrown away just as quickly, the direction I am pointing changes constantly. It has to be a fast process, because if it is slow, or interrupted, all the pieces I have collected fall apart and get lost amongst the scrapheap, and I have to start over.

Felling

Sometimes I hack. I hack when I have a very specific goal, and I just need to get there quickly. It’s like I am standing in front of a tree in a quiet forest, with a sharp axe, and my only goal is to get the tree to the forest floor as quickly as possible so I can head home again.

This desire to be fast, rather than to take my time and craft a good solution, can be caused by different factors. How much do I care about this problem? How much energy do I have? Is somebody waiting on it? How likely is it that this hacking is going to come back and bite me? Am I going to need to look at this again in the future?

Hacking is generally fast, but very linear. I know exactly where I need to get to, and I’ll hack and hack and hack until I get there. Sometimes there will be a big boulder that I have to work around, but I’ll immediately head back to the shortest possible path to the goal line.

Mending

Sometimes I fix. Debugging software is simultaneously the most frustrating and deeply satisfying part of cutting code for me. Knowing that there is a bug somewhere in a huge amount of code that I am the owner of is deeply unsettling to a perfectionist, but the process of hunting and finding that bug requires understanding, insight, and surprising leaps of ingenuity–which is very satisfying.

On the face of it, debugging is an incredibly slow process. One hour, two hours, half a day, two days. To write what? One line of code? One character even? But that doesn’t do justice at all to the act of debugging. For me debugging goes in bursts. From long slow periods of reading and thinking about a piece of code. To bursts of activity: lots of tweaks, and small changes, adding lines that will be removed later, to help prove or disprove assumptions and theories. It’s like trying to find your way out of a forest, where some paths are more obvious than others, and the right one might be the least obvious of all.

The right choice

So which is right? How should we cut code? For me there is no best way. But what is important is to think about what we are giving up when we write code in a certain way, or follow a certain process. And also what we gain.