If You Code, You Should Write

The Practice of Programming

Programmers are, in essence, problem solvers. They live to solve problems. When
they identify a problem that needs solving, they cannot resist the temptation
to study it, poke and prod it, and get to know it intimately. They then start
considering solutions. At this point, the programmer is not often thinking in
code — they’re thinking about the problem using high-level concepts and terms
that most non-programmers would understand.

Consider the problem of how to post a news story to a website. The programmer
might think about the solution this way:

Log in

Go to ‘new story’ page

Enter title and text

Press ‘submit’

Of course, there are a million details in between those points, and after them
as well. The programmer knows this, but defers thinking about details until the
higher-level solution makes sense and seems reasonable/plausible. Later in the
process they’ll think about things like the site’s security model, WYSIWYG
editors, tags and categories, icons, avatars, database queries and storage, and
the like.

Once they’ve reached a point where they’re satisfied that their solution will
work and is thoughtful of the major points to be considered in the solution,
they open an editor, and begin to type things that make no sense to their
immediate family. Programmers express their solutions in code, of course, but
they express them nonetheless, and this is not a trivial point.

The Parallels Between Programming and Writing

Writers often take the exact same course as do programmers. Programmers and
writers alike are often given assignments. Assignments take the form of a
problem that needs solving. For a programmer it’s a function or method or class
that needs implementing to perform a certain task. For a writer it’s an article
or column or speech that covers a particular topic. So in these cases, the
problem identification is done for you (not that more discovery can’t be done
— in both cases).

Next is the conception of the solution. Programmers puzzle over the problem,
its context in the larger application or system, its scope, and its complexity.
Writers puzzle over their topic space, its breadth and depth, and its context
in the bigger picture of what their publication tries to accomplish. In both
cases, writer and programmer alike take some time and probably kill some trees
as they attempt to organize their thoughts.

At some point, for both writer and programmer, the time comes to use some tool
to express their thoughts using some language. For a writer, they open a text
editor or word processor and write in whatever language the publication
publishes in. For the programmer, they open an IDE or editor and write using the
standard language for their company, or perhaps their favorite language, or (in
rare cases), the best language for accomplishing the task.

In neither case is this the end of the story. Programmers debug, tweak, and
reorganize their code all the time. Writers do the exact same thing with their
articles (assuming they’re of any length). Both bounce ideas off of their
colleagues, and both still have work to do after their first take is through.
Both will go at it again, both with (hopefully) a passion that exists not
necessarily for the particular problem they’re solving, but for the sheer act
of solving a problem (or covering a topic), whatever it may be.

Finally, once things are reviewed, and all parts have been carefully
considered, the writer submits his piece to an editor for review, and the
programmer submits to a version control system which may also be attached to an
automated build system. Both may have more work to do.

Starting Out

The process is essentially the same. If you’re a new programmer, you can expect
to have more than your fair share of bugs. If you’re a new writer, you can
likewise expect your piece to look a bit different in final form than it did
when you submitted it to the editor.

Just like programming, writing isn’t something you do perfectly from day one.
It’s something that takes practice. At first it seems like an arduous process,
but you get through it. As time passes, you start to realize that you’re going
faster, and stumbling less often. Eventually you get to a point where you can
crank out 1500-2000 words on your lunch hour without needing too much heavy
revising.

You Should Write

So, I say “you should write”. As someone who owes his career to books and
articles (not to mention friendly people far more experienced than myself), I
consider it giving back to the medium that launched my career, and helping
others like others helped me. I hope I can make the technological landscape
better in some small way. If we all did that, we’d be able to collectively
raise the bar and improve things together.

If altruism isn’t your bag, or you’re just hurting from the recent economic
crisis, know that it’s also possible to make money writing as well. It’s not
likely to become your sole occupation unless you happen to live in a VW Bus, or
you do absolutely nothing else but write full time, all the time. However, it
can be a nice supplement to a monthly salary, and if done regularly over the
course of a year is more than enough to take care of your holiday shopping
needs.

I’ve had good experiences writing for editors at php|architect and Python
Magazine (I *was* an editor at both magazines, but you don’t edit your own
work!), O’Reilly (oreillynet.com and a book as well), Linux.com (when it was
under the auspices of the OSTG), TUX and Linux Magazine (both now defunct), and
others. I encourage you to go check out the “write for us” links on the sites
of your favorite publications, where you’ll find helpful information about
interacting with that publications editors.

I’d argue what you’re really advocating is a more general principle … there comes a point in any individual’s development in any art or skill where they need to be teaching in order to take the next step up in their own ability and understanding. It’s not something unique to programming by any means.

Best regards,
Stu

Will Hall

I have recently (at job interviews) been describing coding a bit like chemistry wherein you have a limited amount of elements (from the peridodic table) the same as you have a limited amount of expression, however, the art is in the combination of them to achieve success (and often things do not turn out how you expected to begin with).

m0j0

@Stu — I certainly agree with your point, and it’s a good one. Thanks for sharing. It would’ve been good to include in this piece, but what I was really trying to do was speak a bit to the objections I’ve heard from programmers to the act of writing. There seems to be some kind of phobia towards it amongst some subset of programmers that, from what I can tell, seems to be quite a *large* subset. I also didn’t want the piece to be too long (and I tend to be long-winded). The first draft of this article had a huge section covering the different reasons programmers don’t write, talking about how *editors* work, etc. I ripped it all out. If anyone wants to see that kind of thing, you can check out this post.

m0j0

@Will — good analogy. I have also described it as being sorta like music, since I also know that a lot of the programmers I meet are also musicians. You only have so many notes, but each instrument has physical attributes that make certain patterns, styles, tonal ranges, etc. easier to exploit. I play guitar primarily, but also play bass, piano, and have played wind instruments in the past. All have different strengths and make different things possible/easy. Picking an instrument is a little like picking a language. Or vice versa