Writing Software is Like ... Writing | Hacker News Reader

Writing Software is Like ... Writing

artima.com

48 pointssocratees32 comments

By and large, engineers have similar productivity levels.

Slightly off-topic, I was told by an electrical engineer that in most engineering disciplines, about 5% of graduates end up doing design work. The other 95% of engineers do support, quality control, sales, and other non-design tasks. (I have no evidence for this except one conversation. Support or refutation welcome.) By contrast, we expect most CS graduates to do design work. If true, this surely contributes to the unflattering difference between software engineering and other kinds of engineering.

Doesn't sound all that wrong. My dad is an engineer with a thesis in bridge-building, and the closest he's ever come to engineering is to draw up the plans for an annex to our house 20 years ago.

1. CS != SE 2. Graduates with engineering degrees are sought-after and very employable in many areas, because engineering is hard and the people who do it are smart.

To be honest with you, the only difference w/ SE and CS at my school is that you take a few more science courses, maybe an extra math course, a DSP course and thats about it. And it's a significant amount more of stress. And I think you have to take less theory courses.

> By and large, engineers have similar productivity levels.

I don't know, but I have my doubts that this is true. In fact, I doubt it's true in any discipline, from maids to CEOs.

It works as a essayist generalization. It's like saying most people get average results. It acknowledges the Gaussian inevitable.

Next thing you know, someone will be comparing hackers to painters.

What kind of person would do that?

Someone who is good at painting and hacking and sees similarities. Just like this person is good at writing and hacking and sees similarities.

A glib bloviator: http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm

I'm sure thousands of words could be written about why code is like writing. The similarity in process is what strikes me most, but I found it easier to write up a few aesthetic guidelines that apply to both.

1. You mustn't make your readers think hard without rewarding them for their effort.

2. Quality is apparent in many dimensions and at all scales. Defects from any perspective affect the quality of the work as a whole. Writers have strengths and weaknesses, but must strive for competence by every measure.

3. Readers strive for simplicity and coherence. For instance, if a character behaves in an unexpected manner, readers will try very hard to reconcile the character's behavior as the actions of a coherent, believable individual. Characters can be multifaceted and dynamic, but outright insanity should be used with caution. (See rule 1. What is true of characters is also true of objects, classes of objects, and functions.)

4. Verbosity dilutes good qualities and amplifies bad ones. (See rule 1.)

5. If a beautiful chapter can be replaced with a good sentence, or a beautiful sentence can be replaced with a good word, then the substitution must be made. (This may not be true for all writing, but it is true of all code.)

6. Innovation is welcome, but should be focused and purposeful. (See rule 1.)

7. Deviation from these rules is welcome, but should be focused and purposeful. (See rule 1.)

I agree. Further, I think the creation process is similar (start with an outline or rough draft and make revisions). The more extensive the later revisions, the more painful they are to make. Even the smallest change later on in the process can result in a significant inconsistency.

Unfortunately for software a small inconsistency can kill the whole thing, writings seems more resilient here.

A closer analogy imho is with lawyers.

Writing doesn't necessarily involve logical thinking of the type programming involves, and it doesn't seem to involve "hacking" (in the best sense of the term), and it doesn't involve working withing constraints in a pre-existing system.

it doesn't involve working around constraints in a pre-existing system

You need to read some books or sites on screenwriting. I can't paste a link (iPhone) but try googling "elliott rossio wordplayer".

Also: the writing of serials, such as sequels. Google "stross martin the art of being late" for Charlie Stross's explanation of the pain involved.

You want to see constraints? Those folks have constraints!

Contributing specific information for a different domain easily makes this the best comment in the thread. It should go to the top.

http://google.com/search?q=elliot+rossio+wordplayer

http://google.com/search?q=stross+martin+the+art+of+being+la...

Yeah, but: 1) the logic must work; 2) the text must scan.

Exercise: rewrite a law in iambic pentameter, add tests.

I see the problem he's identified and I have used this analogy before. But when I use it I generally say "Programmers are like writer's who can't make a single spelling or grammer mistake and have to write a story about every action their characters could possibly take"

I don't think the analogy is sufficient without those caveats though

So, Choose Your Own Adventure writers?

Also, slightly funny/ironic: the extraneous ' in your post.

From the comments, how software is like writing and why the typical meeting-punctuated office environment might necessarily not be the best environment for software writing:

"Here's another perfect scenario that I run into that upper management just doesn't seem to "get" that totally fits the "writer" scenario: fragmented time.

Upper management (and even middle management -- made up of the guys who never could figure out how to write a good "novel" in Java or C++ or Ruby or...) looks at your week and they go: "Okay... you had x hours of meetings, y hours of predictable admin time (timesheets, etc.), and x - y = z hours left over which was nearly 20 hours out of a 40 hour week!! HOW COME YOU'RE BEHIND THE DEADLINE!!"

What they don't "get" is that "20 hours" was 1 hour and 2 hours there over the course of a week. You can't write a book that way and you can't write a novel that way. You most definitely have "plots" in software and "subplots" and characters that need to be developed JUST like in writing. And you can't do it 1 hour here and 2 hours there. It's definitely NOT like "math" or "engineering." It's MUCH more art than science. I've been saying this for years.

You can't give me 1 hour here and 2 hours there. I need longer spans of time to do the "development" (which THERE is a more appropriate word, but in software we don't take that word the same way we do in writing.) if you want a solid plot that will not fail and supporting subplots and good characters... I NEED DEVELOPMENT TIME!! LOTS OF IT (in span of time)!!"

Don't you think that engineers and mathematicians also benefit from having uninteruppted time? Time to think, plan, retrospect, introspect? I think this would be true with any mental line of work.

It's a better analogy than almost any of the other ones, maybe because programming isn't only like writing, it is writing (a point the OP makes in its title).

The fact that people put so much effort into coming up with analogies for programming, and that they're all ultimately unsatisfying, suggests that programming is a fundamentally new activity.

Edit: But it's good the analogies are gradually getting less catastrophically wrong.

I heard a quote once that said something like, "For the niche of highly reliable systems, programming is nearly indistinguishable from mathematics. Highly reliable systems should not be a niche."

I think that current methods make it equivalent to writing or -- as user psranga says -- more like law, such as in writing an airtight contract. But I think the future is in software construction that is away from languages and syntax towards something much more mathematical.

Unfortunately, the demand for software far outstrips the number of people able to create software mathematically. Additionally, domain applications demand domain knowledge which is even rarer among the mathematical software creators.

For large classes of problems, software should not be written mathematically -- it's not efficient.

"So, what do you do?"

I've been doing this forever. When someone asks me that potentially conversation-killing, interview-type question, I explain that I am a software developer. That I write software, how I like starting from a blank screen and building something up iteratively, how I like building something people can use and then quickly segue and flip it back to them - what they like to do to be creative, what they like to make, create

I think this is a great article. Software development is not purely an engineering task. My famous example is quicksort... it is as mathematical as the Taj.

I remember witting mathematical proofs for quicksort... If we treated it more as an engineering/mathematical problem I believe we would have less bugs, but it will take MUCH more time so instead we rely on calling ourselves writers and artists so we can throw crap on the wall and hope to make some $$.

This is very true. The thing that improved my (mathematical english) writing the most is trying to write papers the way I write code/code documentation.

It's always seemed to me that people found the right analogy ages ago: programming is like wizardry.

The writing analogy was how I explained what I do to my girlfriend. It's a good way to describe to the general public what you do in a way that won't put them to sleep.

This analogy goes a long way in explaining what we do to those not steeped in the creative aspects of programming.

Writing software is a lot like writing, yes.

I've been reading Stephen King's "On Writing" several years ago. What caught my attention is how King describes writing process.

He says that a writer visualizes everything in a scene he is about to describe and "hears" people talk, "sees" objects move. Then the writer uses a method of telepathy that involves using letters and words in a proper albeit frivole format to convey the whole scene to a reader.

In a way, and this is another analogy, writer telepathically TRANSFERS the scene he has in his brain to the brain of a reader. Like this:

King's brain -----writing-writing-writing---> reader's brain.

It's not the words, not the letters that matter but the scene that King can build in reader's brain. If reader doesn't understand the notions of telepathic protocol (e.g. written informal English), he can't build this scene in his brain.

In a way, this is like Paul Graham said: programmer IS a program. He has a program in his brain, all important parts of it, everything and then he modifies and "sees" what an object does to another object, how the data gets transformed. Then he writes whatever he has seen and heard in his brain to software, writing it out piece by piece, much like a good writer.

When there are bugs, they are similar to misunderstandings. Watch a fundamental Christian read an essay about people searching for truth and god. He'll think that it is a personal assault at his faith, while another person might think it's a brilliant and inspiring essay about freethinking.

Hence the principle of writer: write for your audience.

The problem of course, is that for a writer, audience and the writer himself are extremely similar. A writer and his audience are made of the same stuff. They've usually listened to the similar people, similar music, read similar books.

A programmer and his audience (interpreter/compiler) are much different. Programmer's audience doesn't understand why Beatles kicks ass so he can't allude that, programmer's audience has much different values and understanding.

Yeah, but try alluding to the fact "Beatles kicks ass" to a baptist pastor and you'll see a huge bug: for pastor Beatles might as well have come from the devil himself.

Also, note how I assumed that all pastors hate Beatles. You might have had a different experience; hence you might be pissed off at me.

Holy shit, I did write a lot of words.

References:

Stephen King's telepathy => http://www.inmedium.org/2006/09/from_on_writing_by_stephen_k...

PS. Wow, I just understood that when you make this analogy with open-source software, many things make sense. Can you imagine a world where to read a book you had to hire a translator from company's obfuscated language (machine codes) that would make you forget the contents of it after you were finished? What a bunch of apeshit crazy motherfuckers!

It is already happening, just read RMS' page on Don't buy Harry Potter books (http://www.stallman.org/harry-potter.html).

Right on.

Reply on news.ycombinator.com