Perhaps this helps to explain why the quality of the code we receive from "offshore" colleagues is, on average, very poor? If you do not have a strong grasp of the English language, can you write "good" code?

Maybe that's why more things are not open-source, people are just too embarrased of their writing abilities and poor spelling with variable names like yeild or zylaphone.

Sorry but in a similar note, well more in how your writting is presented...

Is it me or Jeff's blog has the WORST FONT ever?

It kills my eyes, it is difficult to read in my firefox, the letters are too small and close together.

Well that is my personal opinion anyway :-)

Excellent post! The quote from Knuth just made me fully aware of how I must write code from now on.

And Raymond Chen said, (OK, quoted), "Writing specifications is like writing a novel. Writing code is like writing poetry."

https://blogs.msdn.com/oldnewthing/archive/2006/02/08/527573.aspx

Agree that code must be written for humans and computers though I certainly prioritise the former.

But I do disagree that most of us enter this field "because the machines are so much more logical than people". In my experience the vast majority of software engineers like solving hard problems.

I think one does not need to "have a strong grasp of the English language" in order to code well... If one can explain everithing like the american indians or tarzan.

When I zoom in two steps in firefox, the font looks just fine here.

I did a similar comparison to On Writing Well a while back here: https://kentb.blogspot.com/2007/09/on-writing-software-well.html

Is anyone else tired of Jeff reviewing a book and including a referral link to Amazon? I realize he makes money off of this site - but come on. It's kind of like, "I don't really have anything to talk about, so let me pick a book from Amazon, try to write something about it and relate it to software development and I'll include a referral link to it."

Complete waste of my time. I swear I'm going to unsubscribe to this blog.

I'm surprised that you would say that "Coding is just writing". After all, isn't your favorite book "Code Complete" by Steve McConnell? He dedicates an entire chapter to software metaphors, including "Software as Writing" in Chapter 2.3. There and throughout the book he points out that the "Software as Writing" metaphor works well on the individual and small projects, but "leaves the party early" for larger projects, where he instead preferrs the "Building Construction" metaphor.

It's not that there is no truth to the Software as Writing metaphor, it's just that it's not the best analogy - and it is certainly not one size fits all! I agree with much of this post, I'm just surprised that you didn't make reference rest of the Big Picture.

I could not agree more.

My own preference is for The Complete Plain Words (https://www.amazon.co.uk/dp/0140511997), which I believe should be read by anyone working in any capacity that involves non-trivial communication.

Writing is closely related to thinking. To be clear with language is usually to be clear in thought. Unfortunately this is not how English has been taught in American public schools for a number of decades now. Students are instead taught that the point of literature is emotion (not language), and do pointless exercises trying to figure out how Romeo and Juliet "felt" and how the student "feels" when they read about how they "felt." And from a testing point of view, they are taught that language is nothing but memorization of vocabulary, elaborate diction that has little place in the modern world _other than on standardized tests_.

It is a perfect recipe for a society which sorely lacks for critical reasoning skills, as well as writing ability. And it has led to an entire generation of students who think that literature is just an assignment a teacher gives you.

Sigh. OK. Rant over. How this ties into coding, I'm not entirely sure, but there we have it!

My four rules of programming are: Keep it clean, neat, concise and coherent.

Everything else is just fluff...

I find Style: Toward Clarity and Grace (https://www.amazon.com/Style-Clarity-Chicago-Writing-Publishing/dp/0226899152) excellent too. I keep a copy of both in my desk at all times.

Not everyone worships Strunk and White, of course. In particular,
some linguists don't seem to like the work:

(sometimes parents give their children copies of Strunk and White to
take off to college, a practice I believe constitutes child abuse)

(from https://itre.cis.upenn.edu/~myl/languagelog/archives/004176.html)

My late friend and co-worker John Stoddard always said "The difference between a good software engineer and an great software engineer is that the latter wields a word processor as well as he does a compiler."

This is an interesting post. In my first CS class in college, my professor had us stop writing all code for the first two weeks, and we wrote a ten-page paper using pseudocode for a small calculator program using LaTeX. We then went back and added our C code so that we could extract from the same document our source and a nicely formatted PostScript document.

At first, I thought he was nuts. Ten pages for a calculator program? Ten years, later, I now write very thorough comments and documentation because of that training. I'm often made fun of at first... then praised for having documented my code so well while everyone else is told to comment more like me.

Is it a requirement? I think that depends on time. Obviously, we'd all like to write perfectly architected applications, but sometimes, cost and time constraints prevent that. I think the same proves true with code documentation. Of course, those constraints don't mean we shouldn't strive for the goal.

Great article!

I can't believe it, I actually beat Jeff to the punch (kind of)...

https://frankkoehl.com/2008/04/writing-modular-code-make-it-legible/

Obviously I support your point of view 100%

Jeff, thanks for writing on this important topic. In my opinion, the importance of writing code for the people who must read and maintain it does not get the emphasis and attention it deserves.

I advocate writing every piece of code as if a co-worker, perhaps one less experienced than one's self, was going to have to read and then very quickly understand it, probably without the benefit of having its author on-hand to explain it.

You have a good point! :)

It's interesting, because a few years ago I researched how to reduce spreadsheet error and make them safer. After reading everything I could about both spreadsheets and programming in general, I came to the conclusion that I could reduce good practice to two simple rules
1. make spreadsheets easy to check, and
2. make them safe to use (and maintain)

Both of these are very much about recognising that you are building your spreadsheet for someone else to check or use. It's not for you at all. And both these guidelines are about people rather than being technical. Which is in tune with your post.

"I advocate writing every piece of code as if a co-worker, perhaps one less experienced than one's self, was going to have to read and then very quickly understand it, probably without the benefit of having its author on-hand to explain it."

Someone with less familiarity with the code than the writer (you) is going to have to read it later .... you in a years time ....

That's the point of well written code, you should be able to understand it quickly so you can debug/enhance/change it, without having to rewite it because it is not understandable

I think that writing code and writing both require a thorough understanding of what you're writing about and what your goal in writing it is. If you really understand what you're writing about and why, you're a long way toward writing well and writing good code. The unnecessary parts of your writing creep in when you can't figure out what's really necessary to meet your goal, not because people enjoy throwing in extra loops and variables.

A philosophy professor of mine once gave me some excellent writing advice that I try to apply to writing and writing code. Paraphrased: "Don't just write so that you can be understood; write so that you cannot be misunderstood."

"Writing is closely related to thinking. To be clear with language is usually to be clear in thought. Unfortunately this is not how English has been taught in American public schools for a number of decades now. Students are instead taught that the point of literature is emotion (not language), and do pointless exercises trying to figure out how Romeo and Juliet "felt" and how the student "feels" when they read about how they "felt." And from a testing point of view, they are taught that language is nothing but memorization of vocabulary, elaborate diction that has little place in the modern world _other than on standardized tests_." -Shmork

Ok, so to relate this to coding, the point of making students attempt to emphasize with characters in books is to help them better remember facts and WHY those characters are doing what they're doing. In code this means figuring out why the programmer has a function that removes all the curly braces in a form submit post. Or why they have a function that retrieves a standard string over and over. Being able to emphasize with the programmer will lead to a greater understanding of the code.

I also don't know what American schools you went to, but vocabulary tests were only done in elementary school and a little in middle school in my area. You have to be able to read first in order to understand later :p The tests I took with the exception of foreign language tests had little to nothing to do with memorization during high school and quite a bit more to due with critical thinking and application of knowledge.

Another correlation:

I was struck by the quality of Linus Torvalds' writing on his new blog (https://torvalds-family.blogspot.com/). It is safe to say he is an excellent programmer, and it turns out, an excellent writer as well.

You are so correct. Strunk and White holds a key place in my house. I originally went into college to get a degree in CS and came out with a degree in technical journalism, only getting back to my first love of programming about 10 years ago. The trick isn't so much doing the writing, but making it readable.

With so much code being done around the world by folks who have the programming chops (hopefully) but speak English as a second language, all too often it's very difficult to understand what was meant vs. what was written. Spelling errors, grammatical errors, and so on are very context-specific. Even with a few spelling errors, if the message is clear, that's 90% of the battle.

"Omitting needless words" is important to clear expression, but in most cases it's even more mundane than that.

SVO. Subject verb object. The structure of the basic sentence boiled down to its basic parts of speech. If more people understood this simple formula for writing a sentence, we'd be so much better off. :)

Thanks for a thought provoking post!

@OrganicCat - perhaps that explains why you've confused 'empathise' and 'emphasise' so completely :)

This is a long held belief of my own. In fact I first came across refactoring under the term "Sub Editing" when working for a paper. Watching a skilled sub-editor at work is akin to seeing top refactorers: they continously make small changes whic improve the structure: move words, delete some, re-order the sentance, remove some, move the sentances in a paragraph around, re-order some paragraphs and before you know it a 1000 word essay becomes a consice, clear 200 word article.

Excellent. These are the kind of thought-provoking posts *for which* I come to this blog. :)

A software engineering professor of mine in the '80s used to harp on providing enough inline documentation and using meaningful variable names to ensure that a reasonably logical person (potentially without any computer science background) could read our code and understand: 1) what problem we were trying to solve, and 2) how we were solving it (potentially including why we chose to solve it that way or not to solve it another way). I later revised the criteria down (sadly, in some cases up) to a relatively intelligent nine-year old. Every time I was able to meet that criteria, I ended up with code that I knew I could pick up in six months and maintain without having to retrace steps and reinvent.

Much of programming is problem solving, which is what attracts many of us to it in the first place. When well written, the fact that we can compile and run our solution is almost incidental. Although, it does pay the bills...

Another benefit I've noticed is that when I try to make the code clearer, I often find ways to refactor it or notice logical inconsistencies that weren't obvious before. When I'm really, really lucky I start finding sections of code I can eliminate entirely.

Sadly, many of my colleagues either are too unmotivated or have been seduced by what they understand of best practices to focus on making their code more readable. Some of the excuses are laughable--"I don't use long variable names because they take too long to type" from someone that apparently doesn't understand that even Notepad allows you to search and replace.

<RANT>
As I get older and more bitter, I've begun to rail against all sorts of (perceived) idiocy: 'IF SomeBooleanVariable = FALSE' instead of 'IF NOT SomeBooleanVariable', several hundred line long routines, and can someone *please* tell me why 'gRC' is supposed to more meaningful than 'PageNotFound'.

The problem with many of the legacy programs I have to maintain isn't necessarily any of those or the host of other irritations swarming around them, but they have become a symptom and signpost of a disordered approach to solving a problem. Unfortunately, they spread from one program to another as they're copied as "working examples" simply because their inherent flaws haven't been exposed yet.
</RANT>

The point of software engineering (as opposed to pure coding) isn't to completely eliminate bugs. That's frequently either impossible or impractical. It's to make as many of the mistakes as early as possible in the development life cycle and learn from them how to isolate problems and leave enough clues when they happen that you can determine root causes.

Write your programs as if you were going to get called at 3:00am and needed to figure out what was going wrong and at least potentially how to fix it while your boss was waiting impatiently on the other end of the line. If you don't, one day you will be.

To those commenting (or assuming) that many of those who program and are not native English write bad code. It may appear bad to you because they write for those who speak their natural tongue.

I agree. We should write code like Shakespeare. There is even a programming language for it: https://en.wikipedia.org/wiki/Shakespeare_programming_language

It's not just useful when it comes to coding. Before you write code you have to decide what the code is going to do, and how it's going to work (even if roughly). If more than one person is involved, you need to have some sort of communication about that, ideally written. As the code is developed, you need further communication about changes, problems, bugs, and you need to document classes/interfaces/etc. Finally, and most importantly of all, you need to clearly communicate to users, sales/marketing, bosses, etc. all the important facts and details about the software, how to use it, what it does (and doesn't do), etc.

Some of the murkiest problems and annoyances I encounter is indecipherable run on change requests, documentation, explanations, etc. And when that extends to users and sales/marketing, you end up with frustrated and dissatisfied customers.

This needs to be said: Strunk and White is a pox on the English language, a cancer that needs to be excised, purged, cursed, and spat upon. Imagine a programming book that included every bit of voodoo programming you've ever seen, every ugly, uncommented, cut-and-paste script kiddie monstrosity compressed into a dense, reeking shitcake and spread on bread for your to call it honey--*that* is S&W.

Perhaps my hyperbole got away from me there. Ahem.

Anyway, what I mean to say is that S&W perpetuate all sorts of myths, half-truths and lies about English usage. Slavishly following their advice will make your writing obscure and pedantic, not clear and communicative. Just say no.

https://www.dreamsongs.com/PoetryOfProgramming.html

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
- Martin Fowler, Refactoring: Improving the Design of Existing Code

I couldn't agree more Jeff. I can't count the number of times I've looked into a codebase only to realize that the code was confusing and that the author(programmer) was as well. I've consistently seen this confusion lead to buggy and extremely error prone code.

Another parallel between writing and programming is that both require multiple drafts. You have to write, rewrite, revise, and edit. (In programming, many of those are called simply refactoring.) You have to build that into your schedule.

Yes, release early and often, but don't put your first draft out there. All those mistakes will come back to haunt you.

This blog went from a great resource for like minds, to complete junk.

rss--;

I originally commented over at James Devlin's site, but if this issue is going to come up again, I feel the need to comment again :-)

While they are both based around creating things, the essence of writing is very different from the essence of coding. Consistency and rigor make for great code, but horribly dull reading. Nouns drive elegance when programming, but force verbicide when writing. Coding requires a mathematical like dedication in construction, building on its history, while good writing follows its own unique path each time, avoiding what has gone before. Style is all important in writing, while it is convention that is really important in programming.

They are in most ways very opposite from each other, which is why you rarely find people who excel at both. It's a left brain vs right brain difference.

Beyond that, it doesn't scale either. Could you actually imagine a fictional novel written by twenty different authors? If they even managed to get it finished, it would be quite a mess. Yet, its not hard to imagine a house built by twenty different contractors, is it? Some things are individual pursuits, while others can be done by groups.

Paul.

As a long-time programmer/writer (I create documentation for SDKs as my bread-and-butter), I can attest to the correlation between clear writing and clear code. I have rarely seen outstanding code from someone who could not construct a coherent sentence. There are occasions where I have seen ESL (English as second language, or non-native) speakers who wrote good code, but had difficulty with some of the more esoteric elements of the English. Heck, I've seen many a born and bred in the USA developers who could not write a straightforward email missive if their life depended on it.

Methinks much of the issues with poorly written code would disappear if said developer could stomach a code review. Said reviews typically force devs to defend their spaghetti code and usually leads to much more readable code.

I too have seen the "if(x == true)" constructs among my colleagues. In one unfortunate case, I had to embarrass a coworker in front of the group when asked to resolve a bug I had filed on his code. The poor SOB did not even understand Boolean logic for crying out loud!

Some of Strunk and White is not entirely appropriate to SW development. Although in most cases I agree leaner is better, in SW you must also program defensively. For example, when calling a routine, you should first ensure that the args are not null, unless of course that is the point (as in testing the routine). Within a routine, you must be able to handle null args. Therefore, in both the caller and callee, each arg is compared to null, then an appropriate action is taken (maybe the caller does not call the routine, maybe the callee returns null).

And of course, you must document whether your routine can return null. Don't surprise your caller/audience.

doug in Seattle

I was a lawyer before becoming a coder. Strunk and White always holds pride-of-place next to the Constitution on my bookshelf. But, I hadn't thought about how writing may have informed my coding until this article. Definitely food for thought.

By the way, many people don't seem to realize that E.B. White is the same E.B. White who wrote Charlotte's Web and Stuart Little. Read Charlotte's Web (to a child if you're too embarrassed)if you want to see Strunk and White brought to life.

There is a _huge_ difference between well written readable code and code ridden with documentation. In general, well written code should not need in-line documentation. Methods should be small and concise, surrounding a chunk of logic that can be easily expressed by its method name. Code within these methods should have descriptive well chosen variable names. With these two qualifiers, code is extremely easy to read and not bloated with unnecessary comments.

I also agree 100% on the non-native English speaking comments. I see a direct correlation between less readable code and non-native English speaking programmers. I am sure the same could be said for me if I moved to Europe or the like.

Good post. Yes we should write code so that other people understand it and also can see the structure easily. If someone applies some random custom design pattern, then how are we others supposed to know what is going on? Well, we need the design documents. Sure some things can be seen right from the code, but not everything. The more we see straight from the code, the better, but there should also be the design documents. The design documents can be simple too, but they should exist.

A similar classic: "Tutorial on Good Lisp Programming Style" by Norvig and Pitman.

https://norvig.com/luv-slides.ps

I dunno, I'm going to go with Language Log and a couple of other commenters here and say that Strunk and White is the last model a programmer ought to be using; it belongs in the rubbish bin of history. It's a really ridiculous book and Geoff Pullum nails the problem perfectly: "The Elements of Style offers prejudiced pronouncements on a rather small number of topics, frequently unsupported, and unsupportable, by evidence. It simply isn't true that the constructions they instruct you not to use are not used by good writers." (https://itre.cis.upenn.edu/~myl/languagelog/archives/001803.html) He also points out that the authors frequently break their own rules mere pages after those rules are defined. The premise of your post is good, but those who would follow Knuth's style of "Literate Programming" would be advised to have nothing to do with Strunk & White.

I think that the effort that goes into literate programming pays for itself many times over. I have found though that it is a fairly thankless endeavor. Well-crafted code organizes and simplifies the concepts, and is consequently taken for granted. Like a good lens, you see the subject more clearly, not the lens itself.

Then to add injury to insult, how often have you seen a colleague quickly grasp your concise, cohesive, and test covered code, and proceed to extend it by tossing in unrelated concerns and with junk variable names? Sigh.

I've seen that adhering to Spartan Programming principles yields not only more concise but also more readable code.

https://www.codinghorror.com/blog/archives/001148.html

There's one big difference between coding and writing, however.

If you're writing a book, and leave out a semicolon in the third paragraph on page 96, it usually doesn't make pages 217 through 231 disappear. ;)

brevity is the soul of wit.

And you're also (hopefully) writing code for customers, who want something useful.

Geez, i do agree that programming and writing have some correlation, but i disagree that it lies in "making yourself understood". I think it has to do with making your ideas better. Because it is very easy to have crappy ideas and believe them to be perfect, just like in a dream you are in a house that is and is not yours, things like that. And i do not mean logic, only, but full, consistent, mature ideas. Just because a big-calculator can churn out your ideas does not mean that they are good ideas. Good ideas have to be measured by some other metrics. And the thing is, when you write, you are not only "expressing" ideas that were previously in your head, you are actually forming the ideas. You are giving those ideas a "body", so to say, and it is in this process that the ideas really come to life, not on your idle and selfish wondering inside your head for yourself. So, being understood by your fellows is definitely correlated to good code, but it is not a cause. Or something like it.

Chris Noe has an excellent point; that's what I came here to say.

To add to that, the most frustrating part of my job as a developer is that after taking the time to write simple and well-crafted code a "musical chairs" event often comes along and I end up taking over code from a developer who absolutely thrives on creating complexity. They never think to rewrite, revise, edit, and simplify; once they get the first draft working, it's done.

The result is that the developers who inherit my code are suddenly very productive, while I'm left wallowing in a pit of unnecessary complexity. The productivity inversion is even worse once you factor in the extra time I took to craft my code instead of just going with the first thing that worked. Fortunately I work for a good company so this is seen for what it is.

Over time I've found that the developers who write the worst code also have a tendency to move on to another team or project as quickly as they can so they don't have to stick around and maintain or extend what they've written.

Well, this topic cannot be discussed without mentioning the recent book Clean Code by uncle bob. Well worth the read!

E.g. consider a class as a newspaper article.. headlines, intro and increasing detail. The class should read as a story. One of many wonderful propositions in the book :)

Ironically, I agree with the sentiment that this article suggests, with the possible exception of brevity. Brevity suggest that the "one liner" is the ideal form, when the opposite is probably true. Java encourages "Literate programming" in a way that say, perl doesn't.

Maybe that's why more things are not open-source, people are just too embarrased of their writing abilities and poor spelling hence the world is not perfect

Can someone (kindly) explain to me why 'IF NOT SomeBooleanVariable' is better than 'IF SomeBooleanVariable = FALSE'? I personally find '= False' easier to understand. And in keeping with the theme of Jeff's post, that should make it better. Right?

I absolutely agree, but this shouldn't be news to anyone. Brian Kernighan (perhaps you've heard of him), wrote "The Elements of Programming Style" 34 years ago. Maybe each generation of programmers gets to discover this anew.

https://www.amazon.com/Elements-Programming-Style-Brian-Kernighan/dp/0070342075

Feature request:
New feed - 1 random archived post daily.
kthxbye ;)

Matthew (commenter #2): It's spelled "embarrassed." ;)

Long Live COBOL!

Agree with the post

From what I can tell, I hope some of the posters on this blog are not writing code...

While I agree with the post, something I've always wondered about is the relationship of diagrams and code. Often I want to comment my code with a diagram, not a paragraph, but I've never found a good way to do this.

I've even tried writing code in MS Word (which has a reasonable editor for graphics) and shipping it out to the compiler. It worked surprisingly well.

I'e had a copy of Strunk and White on my, physical, desktop for years. To some degree it's why I'm employed. And I'm 60+.

The comments are interesting. I think that about 20 - 30 % get it. For example

"I was a lawyer before becoming a coder. Strunk and White always holds pride-of-place next to the Constitution on my bookshelf. But, I hadn't thought about how writing may have informed my coding until this article. Definitely food for thought.

"By the way, many people don't seem to realize that E.B. White is the same E.B. White who wrote Charlotte's Web and Stuart Little. Read Charlotte's Web (to a child if you're too embarrassed)if you want to see Strunk and White brought to life.
Eo Raptor on November 10, 2008 10:11 AM

I got an A in my Fortran 4 class. I wrote brute force programs, but as my instructor told me, yea you got it right and it worked, but it wasn't elegant.

Strunk and Write, a 40 -50 pqge tiny book will teach you elegance.

> Is it me or Jeff's blog has the WORST FONT ever?

99.99% of the time this means you have the "C" fonts from Office 2007 (or Vista) installed, but you have ClearType disabled. Enable ClearType, or delete the "C" fonts from your system -- they'll never look good until ClearType is enabled.

> Slavishly following their advice will make your writing obscure and pedantic, not clear and communicative.

Isn't this true of slavishly following *any* advice? I would hope readers are self-reliant enough to take the things from the book that make sense to them, and leave the rest. Sure, not every "rule" is that essential, but there's a core of excellent advice there that I see most neophyte writers struggling with, and mostly failing.

> Is anyone else tired of Jeff reviewing a book and including a referral link to Amazon?

I've been including referral links on any books I talk about for almost five years -- and you've just *now* noticed this?

https://www.codinghorror.com/blog/archives/000020.html

"I also don't know what American schools you went to, but vocabulary tests were only done in elementary school and a little in middle school in my area. You have to be able to read first in order to understand later :p The tests I took with the exception of foreign language tests had little to nothing to do with memorization during high school and quite a bit more to due with critical thinking and application of knowledge."

California public school. 1990s. Really lousy education. Teach to the tests for the tracked students, no idea what they taught to to the untracked ones but that wasn't positive either. After four years of "advanced" English and Math classes I came out not knowing the first thing about grammar or math.

(Since then I have excelled quite well in other areas, so I don't think it was just me being stubborn. Seriously, 90% of what we did in English classes was talk about how people "felt." Incredibly pointless work, no intellectual content at all.)

(And just to note, as someone who has now teaches kids of all backgrounds at an Ivy League institution and has to grade their essays. Most of them out of high school cannot write and do not know basic grammar. Many are painfully inarticulate in their speech and written work. It is pretty sad stuff. Even with the "best of the best" I end up sending half of my students to writing tutors.)

enter ruby, the concise programming language...

"I saw your code. It looked easy. It's just a bunch of typing. And don't get me started on your overuse of semicolons."

Is it not why we ask our programmers to put in their inline comments to note what each function is doing? that makes it more readable, certainly.

Excellent book. I've heard programmers say good programs read like books many times, but when I see their code....let's just say that we probably read different books. ;) IMHO here is what it doesn't mean:
Write your code anyway you like and litter it with comments explaining everything, it's clear just read the comments. This would be like a book littered with footnotes explaining what's going on.
Clear != Simple. I sometimes get these confused myself. Clear code is easily understandable but could express a fairly complex idea, E=MC2 comes to mind. Simple code expresses a simple idea, Hello world is an example.
It shouldn't be applied to just the syntax/grammar but it should also be applied to the overall structure of the program/book. ie. Removing duplicate code (even if it's clear) and putting it in one place.

hmm, in my view, the quote from EoS had poorly constructed sentences.

When I was younger I always had trouble with writing clear prose, but I enjoyed reading and at one point wanted to be a video games journalist. Anyway, I never made any headway towards journalism, but have endeavoured in the past few years to improve my writing. I like to read political opininion columns and film reviews, so that's the basis of my own blog. I made a rule, which I usually break, but I try to have no more than 500 words in a post. This was partly a response to reading Yegge.

My Data Structures and Algorithms lecturer told us in our first lecture that we should strive for elegance.

Flowing, flowery prose soaring to majestic heights, that if recited would be rhetoric to stir the soul of man or even beast, can be as enjoyable as the finest music. Thus the connection holds only so far. I have yet to see code I would want to read if I didn't have to.

"Coding: It's Just Writing" - reminds me of a true "Dilbert moment" a few years ago, when my (obviously non-technical) boss commented that he never understood why it took months to develop software. "After all", he said, "it's just typing." Uh, Yeah.

I learned a lot from both "The Elements of Style" and "The Elements of Programming Style" (Kernighan and Plauger). The second is inspired by the first. Many of the rules are truly timeless. Recommended reading (if you're not too allergic to Fortran).

I think the trouble with the font has to do with browsers that don't anti-alias fonts.

It looks great in IE 7 and Firefox 3 (who AA fonts), but I've also noticed that it's pretty muddled in IE 6 and Firefox 2. Unfortunately they're still quite popular browsers.

I truly understand how difficult it is to write, I've been keeping a blog for about a year, and only now am I starting to realize just how bad I am at writing!

I have a soft spot for Strunk & White (despite also being a reader of "Language Log"), but even I was struck by your picking as an example one of the most obviously self-contradictory passages in the book:

13. Omit needless words.

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell. Yea, verily, verily, I say unto you, omit needless words and cast out all forms of redundancy.

What White should have written, of course, was either:

13. Omit needless words.

A writer should use no unnecessary words just as an artist should draw no unnecessary lines. Concise writing is vigorous; make every word tell.

or:

13. Omit needless words.

Vigorous writing has a rhythm. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts; at the same time, however, a redundant word or overly ornate clause may be just the counterweight needed to restore balance to an otherwise dense mass of words. Vigor requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that he weigh every sentence thoughtfully and make every word tell.

I'm sending a link to a blog post I made about Strunk and White this past October. It's mainly about web writing but it might be applicable to writing code. Others above are alluding to the same points I make:

https://staff.washington.edu/jtate/blog/?p=50

I've been thinking this for years. Having done an English degree before one in Computer Science, I was quick to notice that problem solving skills weren't the only ones that went into making a good programmer.

Along these lines, when being harassed by people I meet to solve their computer (virus) woes when they learn I'm a programmer, I like to point out their computer is like a bookstore, and I'm just an author. For the trouble they're having they probably need a carpenter (to build a door, or patch a leak) or someone to clean up the mess in the aisles, but definitely not an author. ;)

Great blog, bad font. Is that concise enough?

Loved the "Deleting code" link at the end of your post.

I wonder if there's a direct relationship between the people who can't delete code and those who multi-compulsively back up their digital life?

I'm glad you said writing. I find it hard to talk but I can write. The certificate that makes me most proud is my A at English O Level.

I had to make a change to software written using the nuweb literate programming tool. It was harder than it should have been (and I don't think the document was badly written). And then the person after me modified the generated code directly. Sigh.

@Doug. "Methinks"? Hi, I'm English too! No-ones uses that word anymore (outside of Blackadder). And embarassing your coworkers is bad form dude. Good software is a team sport.

I blogged about the same thing a while back: https://mitch-wheat.blogspot.com/2006/09/elements-of-composition.html

The posts on this website are fun reads but illustrate man's greatest strength and weakness. Take any person (who is not completely retarded) and give them a monotonous task for an extended period of time. Every single one will adapt and create some kind of system that makes doing the task more efficient.

Without jumping into my distaste for economic systems, the same thing becomes ridiculously apparent when you put rewards into the mix. So now, instead of having programmers programming, they're using the majority of their time coming up with better ways to program. Now I won't act like a complete idiot and neglect the benefit of performance analysis or the significance of efficiency indices but at what point do we actually stop?

Is it ok for genres to cross-over till the lines that delineate them become indistinguishable? Is it possible to determine diminishing returns for our perpetual ponderances? Apparently it is, as the proliferation of specialized fields nest to infinity sprouting self sufficing support mechanisms for every field, justifying the bureaucracy that gives rise to suspiciously nondescript positions.

Again, I won't ignore the fact that most advances made my man comes from individuals who specialize in specializing. But now, in our modern age, as we are able to look across the globe and accurately compare ourselves with others there seems to be some desperate grasping and knawing going on. Everyone seems to be going to the ends of preposterous to define themselves. In the absence of fiscal systems or rewards, there will always be currency - some way to seperate one man from another and hence create or maintain stratification.

This post is such a product. As the economic systems continue to fail and the majority of the world gradually accepts that it was never sustainable, mediums such as the internet will make it clearer that man's greatest desire is validation. And that desire will drive him to say the blatanly obvious so long as he continues to get satisfaction fromt he droves who may clamour around his work.

Yes, I did have a small spat with punctuation, kept getting in the way of my diatribes.

hey, the quality of your posts are detiriorating Jeff

that you know a good time to share information

Flowing, flowery prose soaring to majestic heights, that if recited would be rhetoric to stir the soul of man or even beast, can be as enjoyable as the finest music. Thus the connection holds only so far. I have yet to see code I would want to read if I didn't have to.
https://zalpstroy.ru/

Geoffrey K. Pullum writes in The Chronicle of Higher Education and is not impressed with S&W:

50 Years of Stupid Grammar Advice
====================================
https://chronicle.com/free/v55/i32/32b01501.htm