I enjoy writing. I enjoy programming. I enjoy writing about programming. (I hate programming "about" writing, though. Of course, all I've written in that regard are a few half-assed markup languages, so perhaps it comes down to lack of experience.) Writing prose and writing code are amazingly similar, and the great masters of software tend to be pretty damn good authors (I'm thinking of Don Knuth, Joel Spolsky, Martin Fowler, and Kent Beck. Oh, and Brian Kernighan and Rob Pike. And Andy Hunt. And Dave Thomas. And . . . ). I don't know of any great authors who've taken up programming and excelled, but I imagine that E. B. White and William Zinsser would make better-than-average programmers.
Writing a half-assed piece of code that sort of does what it's supposed to isn't all that different from writing a half-assed five-paragraph essay that sort of gets your point across. You start with a vague idea of what you want to do, think up a few places to visit along the way that make a mild amount of sense, and dive right in. You write furiously for a few hours, force your way to a contrived conclusion, and give it a quick glance to make sure that there aren't any glaringly obvious fuckups. Then you hand it in and hope for part marks. Both pieces are shoddily written, and if — O horrors unforseen! — you have to revise them, you're lost in a world of tangled clauses and lizard shit.
On the other hand, writing an outstanding program is like writing an outstanding piece of discursive prose: you think about what you're doing, set up the structure you need to get where you're going, and systematically and ruthlessly remove every obstacle to getting your point across.
Let's start with the most obvious part of this metaphor: when you're writing code, your immediate audience is the compiler (or interpreter — whatever). You desperately want the compiler to understand what you're going on about.
If you get the syntax wrong, the compiler throws an error message. Syntax errors — in code and in language — are routine, annoying, and easy to fix. (This is why I get so annoyed when people misuse apostrophes.) If your syntax is dubious, but technically okay, the compiler throws a warning. Warnings are your compiler telling you "I don't think this means what you think it means". Like annotations from a proofreader, they're there for a reason. Worst of all, the compiler may silently mistake your meaning and generate code that does something you didn't expect. Yes, folks, that's called a "bug".
The compiler is like any other reader — it can't read your mind, it can only read what you wrote. Unlike most sapient readers, though, it can't look past the text to find meaning. It can't be generous in its interpretation. It can't get the gist of what you meant from a broader context. It sure as hell can't give you the benefit of the doubt — or maybe it can't not give you the benefit of the doubt, and spits out an executable regardless of whether your code made sense.
Other programmers — this includes yourself in two weeks (or two decades) — can look past the code to figure out just what the hell you were trying to do. This is where life really starts to suck for a maintenance programmer.
If you write spaghetti code, branching from topic to topic and back again, your readers won't be able to figure out what the hell you're trying to say, what you've already said, and where you might be going. If you want to cover a lot of ideas in one function, you'd better treat them briefly and go into more detail later, or your readers will get lost, confused, and frustrated. If you stuff every task you can think of into a single monolithic block of code, your readers will be just as impressed as they would by a thousand-word paper crammed into one epic three-page paragraph.
If you look at programming as writing, you get some good idioms for free. Unless they're exceptionally well-structured, long sentences confuse readers — likewise, gratuitously complex one-liners need to be exceptionally clear. Paragraphs relate well to functions: keep them short and focused. Cover a single idea in depth, or a number of simple and related ideas, or introduce several complex subtasks and elaborate in what follows. A short trip through Strunk & White's The Elements of Style will give you hundreds of ideas.
The metaphor isn't perfect, of course. Prose is basically linear (hypertext, footnotes, appendices, and the like notwithstanding), whereas code — well-designed code, at least — is anything but. Prose doesn't have to worry about the environment in which it's read — code does. Code needs to, before everything else, drive a computer — prose often doesn't have to do anything.
Still, writing code is a lot like writing prose — both make you organize and present a complex idea in an easily understood manner.
Both make you get your point across.