One of the most visible parts of Atomic Object is this blog, Atomic Spin. Untold numbers of potential clients and employees contact us because of what they read on Spin and what high regard they have for it.
Spin’s success isn’t an accident; it’s a group effort. Everyone at Atomic is asked to contribute regular posts, and though it may be unusual to ask programmers to write, it’s more unusual to have so many programmers who are so good at writing. One of the things that sold me on working for Atomic Object was how well their programmers expressed themselves on the company blog.
Programmers aren’t natural-born writers. Some love to write, but others are happy to express themselves solely through code.
Spin isn’t a good blog because Atomic is made up of unusually good writers. Spin is so good because Atomic is made up of unusually good programmers. Like good writers, good programmers insist on expressing their ideas as clearly as possible. Programmers use code, and writers use language, but the underlying skill is the same. The medium is the easy part. The hard part is learning to express yourself.
I grew up writing stories and code. They were hobbies, and I never worried about craftsmanship. I wrote stories from beginning to end, but programming turned out to be different. Any programmer will tell you that writing code isn’t a linear exercise. Writers will tell you that writing isn’t linear either, but I didn’t know that growing up. I believed that first drafts were sacred, that by the time the idea was on the page, it was ready to publish. Freshman comp in college required a first draft and a revised draft. I hated it.
Even while I shunned revising, I came to love refactoring. I always loved organizing, and refactoring is how coders organize. Rather than organizing pencils or canned goods or flavors of yogurt, programmers organize solutions to problems. I may have resisted revising, but refactoring was a natural fit for my organizational side (I think it’s my right side).
It took me a long time to realize that revising is just another form of refactoring. Like computer programs, written works are solutions to problems — they tell meaningful stories, provide instructions others can follow, or try to persuade someone of an idea. As with programming, there are good ways and bad ways to organize those solutions, and the chances of stumbling across one of the good ways on the first try are very small. On the first try, you probably don’t even understand the problem, let alone what the solution should be. First drafts teach us about the problem. Revising teaches us about the solution. Written works require refactoring just like computer programs do, maybe more because computers never pretend to understand what you mean when really they don’t have a clue.
I suspect that I resist revising first drafts because I try to revise as I write. But while I work to perfect each sentence as I put it down, the overall construction makes leaps of logic or wanders off on tangents. I revise prematurely, and premature revision is the writer’s form of premature optimization. The focus moves from understanding and improving the solution as a whole to improving small portions of the solution, usually at the expense of the whole.
Programming has taught me to notice when I’m diving too deep too early, which is most of the time when I’m writing. I tend to fixate on words and sentences, going back and forth over them instead of going forward and getting the lay of the land. I’m learning to do better. It helps not to pay too close attention to the exact words I’m using. I’ve taken to looking away from the screen when I type first drafts. It helps to be near a window.
There are lots of other ways that hacking is like writing. Strunk and White’s admonition to “omit needless words” is, in essence, the DRY principle. Peer review is also a good idea, as is version control.
Becoming a better programmer has taught me a lot about good writing, and judging by the volume of good writers in the programming community, I have to assume others have too. I’d love to hear your observations on the relationship between writing and programming.