Programming is like Sculpting Marble
The sculpture is already complete within the marble block before I start my work. It is already there, I just have to chisel away the superfluous material.
― Michelangelo
I often think about this quote, about how master sculptors began with a solid block of marble and “uncovered” the artwork within. It wasn’t so much an act of deliberate creation as it was about getting intimate with the rock in front of them, letting it speak to them, the artwork slowly revealing itself. There was a truth to it and if the sculptor wasn’t paying close enough attention they might tell a lie, removing a piece of the art instead of the superfluous rock.
To me, that’s what programming is like.
When I first began learning how to code ten years ago, there was a thrill in getting something to happen — anything at all, even if unintended. Just getting past the compiler errors, having the code run, and seeing something moving on the screen was enough.
The next phase is when I began to accomplish things. Finishing my first tiny iPhone app was, at the time, the biggest accomplishment of my life. It felt like I had scaled Mount Everest. I’d set out to make a piece of software that accomplished some task, and there it was accomplishing that task. Amazing.
Then there’s the long period of learning. Sucking up gallons of information, day and night. I quickly learn to impress myself, and then get used to it. Then I do it again the next day. Eventually, the act of “winning” at all starts to feel normal. I know that I can learn pretty much anything I want.
At some point in the last four years, as programming went from a 25 hour per week hobby/college minor, to a 40 hour per week job, to a 70 hour per week career, I’d found myself slowly entering the next stage. I’d decided that code was not just a set of Lego to be used to build towards an outcome, but that it was actually a digital block of marble. There was a truth to it. I stopped asking myself what I needed to add to my code, and started asking the code where it wanted to go. I asked variables what their names were, wondered who a functions friends are and where it would like to be situated in a file. Every keyword and function call was preceded by a question: “What do you do?” or “Why are you here?”. “Is this really where you need to be?”
“Are you telling the truth?”
To me, a program has a singular truth. The truth is shaped by the context: the platform, the tools, the language, the inputs and outputs, the requirements, outside expectations. Every line of code either tells that truth… or is lying. Oftentimes, this approach creates a feedback loop where asking questions about the context reveals answers about your code’s truth, and writing truthful code uncovers answers about the program’s context you hadn’t thought of yet. And it all starts to fall in line.
Bugs don’t exist in truthful code. Every bug is a lie, the result of forgetting to ask the code what it wants, or putting in scaffolding to meet a deadline. Or as is most often the case, when you ask the code what it wants but you aren’t listening hard enough, or can’t yet understand exactly what it’s saying.
I know that these are unrealistic standards for the “real world” of software development. I’m just as susceptible as anyone else to the demands of deadlines — it’s why we write tests and have QA. But I still hold on to the mindset, and tell the truth when I can.