Plain talk will not be easily achieved in corporate America. Too much vanity is on the line. Managers at every level are prisoners of the notion that a simple style reflects a simple mind. Actually, a simple style is the result of hard work and hard thinking; a muddled style reflects a muddled thinker or a person too arrogant, or too dumb, or too lazy to organize his thoughts. Remember that what you write is often the only chance you'll get to present yourself to someone whose business or money or good will you need. If what you write is ornate, or pompous, or fuzzy, that's how you'll be perceived. The reader has no other choice. William Zinsser (page 174)

the 2009 Berkshire Hathaway annual report is an example of plain talk in a business setting.
it's effective—to my surprise, I read the whole thing.

internal communications don't get enough attention from the writer either; the only reason it should be easier to write to your coworkers is because you don't have to worry about disclosure. while public-facing corporate writing tends to be pompous, impersonal, and verbose, messages on internal mailing lists tend to be filled with mistakes in spelling and grammar, incomplete thoughts, and ambiguous language.

this doesn't have to be the case. it's not difficult to write a few lines with a simple style and then use the spelling and grammar tool in your email client¹.

It's fairly clear that one cannot code from the ground up in bazaar style. One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode… Your nascent developer community needs to have something runnable and testable to play with.

When you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is convince potential co-developers that it can be evolved into something really neat in the forseeable future.Eric S. Raymond¹

there are a lot of projects that miss this critical point. it's disappointing when you find a promising-sounding project on the web and its latest release turns out to not even compile let alone run. being a good open source denizen, you look through the source with hopes of contributing a fix but there are problems at the most basic levels—this program doesn't need a patch, it needs a rewrite. you've just wasted the last hour.

this is damaging to open source. outside of a few well-populated categories, a person is more likely to find a broken or half-finished mess of code than even a half-useful library. it would be better to not waste their time and let them write their own solution that they can release once it fulfills their needs.

for the first time I'm reading a book with a highlighter and pen handy. after 25 pages of On Writing Well, it looks like every one will be marked by the time I finish.

it took me hours to get this far, not because the writing is inaccessible or full of metaphor, but because it is so simple and overthought. I find myself re-reading sentences, even paragraphs, marveling at the word choice, like the sentence “today [distractions] also include a galaxy of electronic devices for receiving entertainment and information” (page 8). as I read and re-read I wonder if Zinsser picked galaxy without a second thought or if it came from dozens of iterations, crafting the sentence into the final gem that was published.

for the next generation, where emails, IM, and SMS have already replaced voicemail, hallway meetings, and gossiping over tea, this book should be required reading. anyone who uses a keyboard or pen would benefit from it.