I’m finding that my writing process and coding process is more similar than previously imagined. This shouldn’t be a surprise. I’m not the only one that’s gone on and on about the similarities between artistic and design processes. Maybe it isn’t really a surprise, or a revelation, but an unexpected clarification.
When I write, I spend most of my time thinking and not writing. My actual time spent putting words onto electronic paper is minimal compared to how long I spend pacing around my office moving pieces around inside my head. In fact, when I do it right, the actual writing part of writing is as close to effortless as work can get. That’s one of the reasons I don’t like to write before knowing what I’m writing; when I do, it feels too much like work. The other reason is that I hate editing. I’ll talk about that later.
I’ve now worked on a handful of end to end projects in my engineering job, which is enough to start noticing patterns. I’m finding (shock) that I spend a very long time organizing the overall picture of what I’m doing in my head (or sometimes in a notebook) before writing more than a few liens of code or defining a few empty methods. It leaves me feeling unproductive for the early part of my project, as well as afraid I wouldn’t finish on time. How was I going to get the coding done with half of my time already spent?
Yet in every case, once I had a good model of what it was I was doing, the actual coding part of the project only hit a snag if I needed to figure out how to technically implement something. Like this: I know I want to find this part of an XML document, but I don’t know the correct method to accomplish it. I also was spending much less time than expected having to debug what I had built, both because I had worked out a number of the logic problems before coding, and because the time spent thinking had produced relatively clean code that was easy to fix.
I doubt I’m the only person who uses a long Thought Before Code spin-up process, or even that I’m in the minority. At least, I doubt this is a rare practice amongst successful programmers. The unsuccessful ones rarely have consistent processes, which is probably what makes them unsuccessful. Still, I wasn’t expecting such a clean similarity between how I write stories and how I write code.
Then I thought about it further, and it makes a kind of sense I should have seen before. When I go through my writing spin-up, it’s not the language or the flow of a conversation that I work out before writing. It’s the way the larger, more abstract pieces are going to interact. It’s how the motivations of a character are going to bounce them into or off of other characters, how all of those characters are aligned in such a way that what results is a clean, smooth narrative.
What I’m working out are all of the pieces that must exist behind the story for it to be the thing that I see in my head. The delicate connections between this strand and that, between event and response, between motivation and action. It’s a kind of architecture, really.
When I was in my first photography class, my teacher described the most important part of taking any picture: pre-visualization. Don’t press the button, he said, until you can see the picture that will result in your head. This wasn’t just looking through the viewfinder and lining up the framing or pulling focus or deciding how far to zoom. It was more than that. It was visualizing the way you wanted the picture to look by understanding how the camera would see the scene.
A photographer needed to put himself inside of his camera. They needed to internalize how light levels and shutter speed and aperture size and framing and zoom and depth of field and all of that would interact to produce an actual, physical photograph. More, they also needed to internalize how another person would then see that photograph, to know how, once that photograph was set, the elements of it would draw the eye to one place or another.
They needed to think through the entire photograph, from how they saw the scene, to how the camera would see the scene to how that final picture would give to the audience exactly the sense the photographer had before depressing the button.
Once again, there’s an element of architecture there. When you’re building something, you need to understand how the stresses and supports and elements of your final work are going to interact. Like when kids who are good with Legos are about to build: What pieces do I have? What colors? How can those pieces connect in such a way to become the castle I have in my head? If you just start chucking Legos onto the base – like I did – you’d end up ripping up half of the thing to get it working, and even then, you might not have the time and energy to get through it.
A lot of people talk about how programming is an art, but not enough people talk about how art is a science. The art is the detail, it’s the delicate hows that make up your work. The art of a photograph is the specific way your eye follows the curve of a railing and the shadow it casts towards the face of your subject, and more specifically, how that image is crafted to make you feel. The science of it is internalizing how light exposes on silver nitrate, and how the settings on your lens will leave one part in focus but another pleasantly blurred. You can shoot from the hip with art, and a lot of the time you probably should. But the science? Spending some time working that out may be for the best.
Or perhaps I just feel unproductive in those early days and need to justify it. If so, consider this bit of writing a resounding success.