Before I’d ever written a single line of code, I was a graduate student in creative writing who wrote poetry and narrative nonfiction full time. I say full time because it was a daily practice: I’d wake up every morning and write for two hours. If I missed the morning for whatever reason—an early class, a hangover, house guests—I’d be sure to write that night.
This daily routine was one I had to train myself into. And even after it had been ongoing for several years, it was still something I needed to ease into each time. To do that, I’d reread whatever I’d written the day before and edit as I worked my way through it. That’s how I’d spend the first half-hour or forty-five minutes in my chair: tweaking line breaks and reordering words, correcting grammar and smoothing out the rough spots. This work had a couple of benefits. First, it was work that just plain needed to get done—first drafts can’t stay first drafts forever. And second, it helped limber me up for whatever new work I might produce during the rest of my time in the chair. It was like stretching before a run. Like mise en place for the mind.
For a number of reasons, I no longer have a daily writing practice. But I do write code just about every day, both in and out of work. And though I hadn’t noticed it until a coworker pointed it out to me years into my career (by noticing a pattern in my git commit messages), I still employ this same technique to find my daily reserve of productivity. Every morning, before starting into that day’s work, I review whatever code I wrote last. I tinker with syntax, simplify functions, rename methods I’d drafted the day before—whatever strikes me as needing to be cleaned up or clarified gets cleaned up and clarified.
As with writing poems and essays, this slow process of revisiting existing decisions and problem solving serves a similarly dual purpose: it completes a first pass at refactoring, an essential part of the process, and it again opens up the necessary mental reservoirs so they’re ready and available for the new day’s work that needs to be done.
But there’s also a third thing this process of easing into code does, which is to continually remind me that code is written primarily to be read. By which I mean code is written to be read not by the compiler or the parser or whatever other robot brain we point it at but by other humans. All code’s primary purpose—yours, mine, Mark Zuckerberg‘s probably—is to describe and order your thoughts on a problem and how you solved it to the next person who reads it.
In much the same way that I used to refine my poems and essays to better articulate whatever point I was making or image I was trying to convey, I find myself now thinking about how readable and clear my code is for the next person who might need to work with it. This is not something done entirely out of altruism either—it has a very practical payoff when working on a team or in the (almost certain) event someone has to maintain the code you’ve written at some point in the future. My productivity, made better by refining the work I'd done before and leaving me ready to solve a new set of problems, can help improve (or, at least, not slow down) the next person’s productivity.
Even if that next person is you. Even if you‘re just rereading your work the next day.