Slashdot Mirror
Spring into Technical Writing
Who's it for?
The book's full title pretty much nails the intended audience; it is absolutely for engineers and scientists. Unlike most works on literary skills, this book treats you like a geek and realizes that you don't want to write prose, but you do want to communicate through a written medium. If you read Slashdot on a regular basis, know what Linux is or the majority of your books have diagrams, figures and tables instead of pictures, then you are a candidate for this book. If you can name more than one type of verb, then you may well be better sticking with your copy of The Elements of Style.
The "Spring into ..." series of books is based around the idea of transferring concepts quickly and efficiently. Barry, editor of the series as well as the author of this book, recounts his experience of a few years ago, when he had to learn a number of new skills quickly and could not find books that would meet that need. In his own words, "I didn't have time to become an instant expert, but I did have to become instantly competent."
The StructureThe book is split into four sections, each building upon the output generated in the previous section. The first section introduces the reader to the concept of technical writing, including how it varies from the other sorts, and then covers how to plan your documentation. Section two covers the actual writing. It starts with words, moves to sentences and progresses to paragraphs, before bringing in lists, tables and graphics. Section three looks at specific types of documents that are meaningful to engineers and scientists including manuals, web sites, proposals, lab reports, PowerPoint presentations and emails. The fourth section teaches basic editing skills, core concepts of typography and a discussion of practical punctuation.
Chunky, and I don't mean soup.The series explains its topics in one or two page units that it calls chunks. The individual chunks in a chapter build on previous chunks. Delightfully, there are plenty of good examples throughout the book and each chunk has at least one example in it.
What's to like?I found much to like about this book, and if any of these points ring true with you, then there's a good chance that you'll like it too. The first thing to note is hopefully obvious, and that is the quality of the writing. Or at least I'd hope that it would be obvious that the writing was excellent in a book about writing! There is an upbeat and cheerful tone that, even with a few corny jokes in the footnotes, doesn't cross the line into being either saccharine or condescending.
After the quality of the writing, the thoughtful division into chunks pretty much make the book for me. The information within the chunks is excellent, well indexed and easy to locate through the table of contents. The chunks cover task-sized activities; for example, you might wonder if a semicolon would work at a certain juncture. So you turn to chapter 20, the chapter on punctuation, and then to page 286, where a straightforward explanation of the correct usage of semicolons (with five good examples) awaits you.
While there are many depths to be explored in writing, this book stays close to the surface, giving enough help and guidance without turning the reader into an expert on composition. All advice is targeted for the concept, in the context of the likely circumstances that an engineer or scientist would need it.
The book stays on target all the way through. The stated audience of the book is engineers and scientists, and that remains the focus throughout. This makes a delightful change from books that claim to cover advanced topics, but start out trying to teach you the basics; Java books seem to be especially guilty of this.
The third section of the book covers many of the types of written material that a reader may be called upon to produce and not only gives examples, but it also shares tips and lessons learned from experience for each of the document types. Examples include pacing a PowerPoint presentation and writing a book proposal.
Oddly enough, for a book written about writing, for a technical audience, by a professional technical writer who also teaches occasionally at MIT, there is nothing to complain about in the writing department. So, switching to scraping the bottom of the barrel mode: I didn't like the ragged-right text justification and a few of the jokes were very corny. That's it.
ConclusionThis book does what it sets out to do, that is to equip engineers and scientists with the skills to communicate clearly and effectively through a written medium; whether that be a website, an email or a report. I recommend this book to everyone, from organizers to doers. Organizers like to write about what should be happening, and doers, while they may tend to shy away from writing, are often asked to write about what they've done for the organizers. This book covers that full circle.
You can purchase Spring into Technical Writing for Engineers and Scientists from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I think a book of this type is desperately needed, and I applaud the author. I for one am so tired of going to meetings where you get the "ass-kisser" type who can talk like a bigshot (yet does NONE of the work) taking all the credit. I work alongside some of the most brilliant engineers who are always overlooked for promotions or new opportunities simply because they aren't good at presenting or adding the burecratic fluff for managers who don't know a damn about what's involved behind the scenes.
"Simplify, simplify, simplify!" Thoreau
What the hell was he just talking about?
I sig, therefore I was.
This is why we are re-doing the software on all of our servers. We had 2 bozos building servers that were really bad at documentation. Policys scattered everywhere. We are also having to configure all of our switched from scratch, too.
Write it down and when you are gone we will speak nicely of you.
... Technical Writing Hacks for Engineers and Scientists?
I took a Technical Writing course last semester in college. I didn't even buy the book, and I passed with an easy A.
It's easier than English 101 or English 102.
You mean, like 99% of every other non-reference book out there?
Drag n' Drop DVD Recommendations
There's a mandatory course at my university in regards to technical writing. All engineers have to take it. It's much better than the standard 'college writing' class (think boring lit times 10). in fact, students can only take this course in their third year or later (NU is a 5 year school).
At that point, the student should have gone on a co-op, so the student should have some knowledge and insight into having something techinical to write about.
The courses are taught by professors who have experience in the workplace environment (not professors who came straight from academia).
all in all, the setup is wonderful for making a writing class useful and moderately enjoyable.
--mike
Of course, maybe that shouldn't be surprising, given the book you just read. Sounds good.
Have you read my blog lately?
In my experience, everyone who can't write worth a damn thinks they can.
When I went to Law School and Business School this book was praised: The Elements of Style by Strunk available here: http://www.bartleby.com/141/
Communication in language is as technical an achievement as communication in code. It takes a little learning and a lot of practice. It is far from "ass-kissing" or bureaucratic fluff. Almost EVERYONE has problems with the written and spoken word. This is not some downfall of geeks only. And your code is only as good as your communication skills if you are working on a team or anyone other than you will need to read the code. Geeks need to see good communication as a technical challenge, which it is.
"if you cannot explain what you've done, then what you did was worthless"
I get that feeling everytime I have a meeting with the big cheeses.
moo
My riting is just grate. I don't need there book to tell me how to rite better.
Now I goota get back to my tecnical documenteation for this project I'm dooing over hear.
BTW, wat excactly does a java inturfaice do again?
doesn't mean you deserved it. With colleges forcing grad students and junior faculty to meet quotas regarding grades, an "A" is very rarely the result of your hard work in a course like technical writing. In addition, technical writing courses rarely deal with things like specs and design documents in a realistic fashion. The teachers in these kind of courses are meant to analyze very basic elements that revolve around following instructions more than writing a spec that is easy to understand and use.
I am not saying you did not deserve your grade, but I am saying that good technical writing in context is not easy.
boing boing, boing boing boing boing-boing, boing boing-boing boing. Boing-boing boing boing boing boing boing.
A spring vividly and concisely summarizing a technical spec.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
I was going to say something mean about technical report writing, but I can't really describe correctly exactly how I feel about this subject.
Never buy a book from an author teaching written skills. The author clearly needs to work on his writing skills.
-A12
While I applaud the author too, everyone needs to recognize that there is no substitute for "caring about the reader," and quite frankly, most technical people don't have the time (or want to expend the time) to learn how to explain themselves to a non-technical audience. More specifically, we don't feel that the audience is worth this expenditure of time.
As a project manager, one of the greatest skills I can bring to the table is being able to communicate effectively with the technical people (TP) on my team, and then turn around and explain to the non-technical people (NTP) in our organization what the heck they were talking about, and why it's important. I'm able to do this, in large part, because I have respect for people on both sides of the equation, and take the time to understand what they're saying, and communicate in their terms.
Unfortunately, there is traditionally very little respect from either of these camps, going either way. As long as we TP assume that we're talking to PHB's, Boneheads, and Golden Parachute Weenies(tm), it's going to show in the way we write.
If instead, we presume NTP to be intelligent, with a different (but still valuable) skillset, and keep that mindset at the forefront, our consideration for their intelligence will come through and so will our message.
Here's a test. Take your last technical proposal, and consider how you would structure and word it for (insert name of close, non-technical relative such as Mom, Dad, etc.). Then, write it that way, but without the analogies to Mom's wonderful cooking, or Dad's "Viagra incident." I guarantee that if you respect the audience, and don't talk down to them, you will improve your writing and communication.
Add in the practical suggestions from a book like this, and you should be in good shape. However, neither one of these components is a substitute for the other.
Tim
A Guide to Writing as an Engineer?
If I have to support one more system written by folks like my father, who lived by that creed, the next time you'll see me will be in the evening news.
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
"There is a school of thought that if you cannot explain what you've done, then what you did was worthless. "
Blink: The power of thinking without thinking by Malcolm Gladwell would disagree with you.
There's a mandatory course at my high school [stlawrence.edu] in regards to technical writing. We all have to take it.It's much easier than the standard 'high school writing' class (think about literature, with the stupid old teacher, times 10). in fact, students can only take this course in their junior year or later, even through it so damn easy.
By this point, we've learned how to do stuff, and should have knowledge of writing.
The courses are taught by profs who have little experience in the workplace, after all they've been teaching forever. They come straight from college or something.
All in all, the courses are better than taking the standard literature (much easier!) but I'd rather stay home sick any day.
--tom
if you cannot explain what you've done, then what you did was worthless
If you can't understand what I've done by my source code, then you're worthless.
My friends and I have long known the power of explaining your code as a method of debugging.
:-)
I'm not talking about walkthroughs.
What I mean is, when you are stuck -- when you have been staring at your code for hours, but you just can't see where the problem is -- you go and explain how it works to someone else.
It doesn't even matter if the other person is understanding, because, after just a couple minutes, the explanation usually ends something like this:
"And in this line, we take the value that was stored up h-e-r-e... uh... wait a minute... [inaudible mumbling]... I gotta go, I'll see you later."
Knowing how to format a document is very important. It's good to know how to use even amounts of white-space, group like items, and differentiate unlike items. If you can do all that, and remember to use sans-serif (no strikes) fonts for headings, and serif (strikes) fonts for body text, then you just might make one sexy looking document.
None of that will help my coworkers. They need a reading class, followed by a book on how to construct a sentence.
I don't fvcking have issues communicating apples banana blue octopus! Different hands ordain opposite monkeys but fantasy microwaves and cell phone puppies. Seriously, fighting and screaming however, beer beer beer. Beer beer beer beer beer. Just remember this, beer.
--- We need more Ron Paul!
However, if they could just learn to write a decent paragraph or two explaining the way their newest brain-child REALLY works, I'd be a very happy writer.
I can name lots of types of verbs! English verbs, Spanish verbs, Mexican verbs, Japanese verbs, ...
Because you can't spell "slaughter" without "laughter"
Writing for Computer Science by Justin Zobel is also a very good book in this area. It focuses on academic writing but has a lot of detail on how to create good figures, graphs, tables and so on.
I should NOT have to reverse engineer your code to find out what it does. A competent technical writer can take a well-written software specification and have a draft user manual ready by the time the code is compilable.
Does your source code start with a clear software specification document, and are all your mudulkes accurately and completely commented? If not ... what the heck are you coding?
I'm disappointed with the lack of a 1337 speak chapter. How can I explain myself to my colleagues on IRC?
Here is another vote for "On Writing Well" to bookend your copy of Strunk & White.
Just as programmers compliment the "elegance" of code, Zinsser's focus on writing with economy is a lesson more should follow.
I'll create an amusing sig when I have something meaningful to post.
I think it's a bit of a wasted effort for engineers to try to learn to communicate in English past a certain level. A college freshman scientific writing/essay course should be sufficient. Unless, of course, they are career changers and *want* to move into technical documentation. Usually, though, the tendency is to move in the other direction.
Your time and their time is much better spent formulating some good process documents, so you can get busy herding them into producing functional specs, and getting them to review and to sign off on engineering requirement documents, and so on.
After all, nobody expects the tech writers to seriously produce good code, or the tech support people to go out there and do the marketing.
Da Blog
Maybe I'll use this book in Writ 1E in college. A special writing class desgined for illeterate engineers like me :-)
$sig$
The very best technical writers I've known were highly skilled writers with a rare ability to take highly complex and technical subject matter and communicate that information in simple (but not simplistic) and clear terms at the level appropriate to their audience.
Their most common complaint was that management (typically with engineering backgrounds) in the R&D operations that they were part of discounted or denigrated their role and contributions to products, instead of regarding them as the skilled usability professionals they are.
I don't know how many serious usability issues and critical bugs have been detected and resolved as a result of the work of those technical writers.
At a technical content review for an alpha-stage product line I saw one operations director who defined good documentation by the numbering system. Because the technical content was flawless, the only criticism he could come up with was, "Where's the numbering? Everyone knows that good documentation has to have good numbering!"
He followed that up with some comment about being short-staffed for developers on the team and "helping" the docs specialist by tasking some developers to take on future technical writing tasks. In other words, he was trying to get his developers take over the technical writing tasks and get rid of the docs specialist altogether. The only reason he felt he could do this was because of the attitude that anyone can write, and any developer who can write can also write good technical documentation. Unfortunately that attitude tends to be typical of many engineers.
While a book like this is definitely a great help to developers and scientists who want to improve their ability to communicate their ideas, I wonder how many managers of the sort I've described will use it as a tool to devalue the work of professional technical writers.
Just because you can write, it doesn't mean you can write well.
I thought it would be apparent and maybe painfully obvious from the context that I wasn't serious. It's not like normal every day users ever get to see source code, and they're ostensibly the ones who need documentation.
While there are many books that teach written skills...
I'm pretty sure the submitter meant "writing skills."
That that is is that that that that is not is not.
http://www.netfunny.com/rhf/jokes/92q3/techwrite.h tml
It looks like there's at least one word the class didn't help you with :)
Most technical writers do not write as they speak, and they do not write in simple step 1,2,3 steps.
I wrote many maintenance manuals in the Air Force and my coworkers never had any problems following the procedures in my manuals. The secret to authoring an effective technical manual is not rocket science. Write as you would speak, and have simple 1,2,3, etc steps. The average reader will not have any problem understanding your writing. And yes, I did not run this through a grammar or spelling checker. I write as I speak.
Same thing is true of writing. More so. It's amazing how often companies think anyone can write. Why, it's only the language you speak so how hard could it be? Why I could whip out a manual in no time...if I could just get past this project...and then I need to clean my desk...ah, lunch time calls...etc. The manual never gets done. Or if it does get started, they quickly learn how intimidating a blank screen is when you are the one expected to come up with the next sentence.
Don't get me started on what managers write. Their emails are astounding. Astoundingly bad. But that's not atypical in the least. Most people know how to communicate, but not in writing. So enter the technical writer who can do all of the writing that needs to get done, on time, to spec, with good quality. As you said, I'm not in the least worried that some programmer is going to take my job. I can't even get them to write an email telling me what they want me to write. They are so afraid of writing, they would rather tell me on the phone what they want and let me take the notes!
We were discussing the need for technical writing skills on the part of programmers and engineers ... and unfortunately, the "read my code" attitude is alive and well in the OSS community.
This seems like an excellent book and subject.
The industry is in dire need for more people to write for the *need* of other people.
Two current examples.
My company employ one of the big development methods, aging back some 10-15 years. It contains templates for various (document) deliverables the company pitch as an advantage to customers. These documents (ranging from 80-500 depending on the project) are something each project spits out *just because* they have to (lousy project management). The decision of what document deliverables to produce is made something like 1-2 years ahead, which in reality means only 5-10% of them would be useful at the date of shipping.
Instead of having all these tens of thousands of useless crap pages being manufactured, junk which no-one will ever read, it would be much more appropriate if the right people could write about the right thing in a way suitable for the intended audience. Unfortunately this would mean a break from the *method* at various point which seems unlikely at present given the particular company culture. In short, Agility needs to enter the "document manufacturing" cycles as well.
The second example has to do with with doers vs. explainers (is that a word?).
I've run some projects in which we had some brilliant designers and coders, creating the most flexible and elegant designs and implementation. Unfortunately these people either didn't document them or documented them poorly. On each account I took the decision to simply yank the undocumented or poorly documented "elegant" stuff out of the system replacing it with something which average developers were able to explain and understand. The decision might have resulted in worse design, but who really knows. A customer who is going to maintain a solution deserves to be able to understand the architecture and design without having to hire A-grade coders and getting them to document the stuff (fat chance of getting A-grade coders who also document except for "Gamma or Beck"!).
This culture of *just read the code* isn't flying today and brilliant people who can't express themselves are finding themselves having a harder time getting new project contracts.
In a society that believes in nothing, fear becomes the only agenda ~ Bill Durodié
Many developers (not mine of course), especially in poorly managed and I mean both poorly tech and people managed departments treat Documentation as Chore and Necessary Evil, and Quite Honestly treat the Tech Writers like s#@t. The developers don't want to provide guidance, provide content and review docs. The managers are afraid to put thier foot down on thier "talented whiners" so it becomes OK. And then they throw in the Agile Manifesto, to try to justify it.. you know code over documentation... agghhhh it drives me crazy... not the Product Documentation you Moron! In the end it is the product that suffers.
These are the same developers that then turn around and complain about crappy documentation in the tools and platforms they use.
Finally I don't buy that "Engineers are poor writers by design". Step up to the plate Maynard! and learn to read and write!
As others said engineers that learn to write and communicate become much more valuable, and have a greater chance to effect the process. If you don't like what your manager is saying, learn to communicate your ideas effectively. Its up to you to be your own best advocate.
-Steve
but if your code work does not either cut expenses or add revenue to your employer/client by at least the cost of your labor, expect to be out of a job soon*. That's all "value added" really means.
Also, comments matter as much if not more than the code. I'm not talking about stupid crap like:
I've seen stuff like that, and it's worthless. But real comments stating what problem you're trying to solve, and how you're solving it. Without that, what's to say the code is right or wrong? It's so easy to duff up a complex condition with misplaced punctuation or an AND in place of an OR. Explaining this condition in the code will help yourself and others understand what you mean when the code isn't quite saying it. Meatspace is still the Real World(tm), no matter how much we might wish it were otherwise.
* - an obvious exception is basic research work where it's pretty hard to quantify the value of what's done. Another exception is stuff one writes for the pure joy of it.
This is a serious request for experienced technical writers willing to consider living and working in China. This means 5 years or more experience, with telecom industry experience preferred. Native English speakers only. No interns need apply, etc.
Please contact Ken at kmtkr@hotmail.com
Note there are currently three job openings at this level.
As for the book, I agree with those that see the value in the subject. I also agree with those pointing out that tech writers have little to fear from engineers suddenly becoming adept at writing for people outside their sphere. With most engineers believing that everyone speaks the way they do, good tech writers can look forward to long and prosperous careers.
Not just in the OSS community, and that's why I figured I'd make a joke about it. But judging from the overall responses and the late troll modifier, it wasn't taken that way.
Simon,
I think prose means the opposite of what you think it means.
-Peter
You can buy it here too: Spring into Technical Writing
I generally use this service when writing technical and other documentation for work. It's more slanted towards bulk documentation for commercial areas but it allows me to plan a document and get a quote very easily. You can also convert your existing paperbased manuals to online as well.
Comment removed based on user account deletion
I am likely to low to get in any way seen, but this is what I do as a college student. I am a dual major, Computer Engineer/Professional and Technical Writer, with personal training and coaching from a project management/teambuilding guru. What my team is currently working on, through an National Science Foundation Grant, is a way to introduce, team building and Technical Writing training seamlessly into the first two yearss of your college career.
We are publishing our findings in a book, which'll probably be sometime in the next 3 years, after we try a few more tests against some more control groups in more diverse courses.
In my opinion it's imperitive that todays engineer get training in Writing, and in teambuilding. No longer are engineers stuck into cubicles to work long hours in solitude. They are in small teams, bouncing ideas back and forth, really tackling problems in a diverse manner, and if they don't know how to handle the occasional sour grape in a team, their first few years as a professional will be hectic and stressful, even moreso than it already is.
Now, I happen to be a lucky person, the things I'm doing now more or less fell right into my lap. I'm only going into my Sphmore year of college, and already I have a hand in the design and implementation of a full-blown real curriculum. A curriculum for a class that I'll be taking as we implement the changes.
The thing is, more schools need to pay attention to their undergrads. Most big tech schools, where most engineers graduate from, don't have the enviroment I have being in my medium sized University. The school, and it's professors need to take the time to get these grants and pilot their own programs, or learn from the methods disseminated from pilots like my own. Otherwise the industry is just going to keep heaping barriers into the entryway of the engineering feild.
the book is US$4 cheaper at Amazon.com.
If you're interested in the book's subject, you might find the following links usefull:
Technical writing tips: http://www.docsymmetry.com/index.html
Plain English Campaign: http://www.plainenglish.co.uk/index.html
Get it write: http://www.getitwriteonline.com/archive/tips.htm
It is not wasted effort to learn to communicate effectively in spoken and written English
But how much effort might be required to raise the standards of written communication within people whose time might be better spent doing what it is that they do best? My point is that the effort might be too much, and too distracting, and ultimately futile because the tech writer is still going to have to rewrite it all anyway. There's a reason why "division of labour" works so well in a large enterprise.
Are you familiar with the story of the King's Horse and the man who promised he could get it to sing?
Da Blog
Heh, how you do that?
:-)
You use that word "mudulkes", which I enter into google looking for an explanation. Google says they never heard of it, but do I perhaps mean "modules"?
The word modules lets the sentence make sense. But how did the poster know google would interpret it that way, if google has "never seen" that word before??
Puzzlement here.
This paper is on the web and helped me to an amazing degree: "The Science of Scientific Writing" http://www.amstat.org/publications/jcgs/sci.pdf If you're looking for help on fixing little things: "Bugs in Writing"
S/he who writes the proposal, controls the money and the project. It's that simple folks.
And it's not just the *form* of the documents. It's the arguments why you're right, they're wrong, and you should get every dime they have. There's more to this than simply describing what you did with the belief that as soon as people see your description, of course they'll come flocking to your way of thinking.
Technical writing is more of a war of ideas than anything else. Not only do you have to show your audience you are correct, but you have to address all the hidden questions that they have to convince them that you are correct. Otherwise, what good has all your work been if you can't get others to believe in it?
This seems like a horrible "service." I can't tell what's going on or what I'll get or even vaguely how long it will take or what it will cost. I'm afraid that this service fails the basic rules of tech writing (and user interface) on so many levels.
And I hate it when writers use "commence" instead of the easier to understand "begin." Ugh. All of the prose seems overdone and yet not helpful.
While I generally agree with you, tech writing is about creating solid usable material (and removing the fluff) in user and reference materials, not about adding comments in code.
I think that commenting on code is a valuable skill, and I recognize that some developers do it like an artist while others do it like a stinky child, but commenting is very different than tech writing, which includes determining the audience for a document, outlining it, and then building it so that it can be used, updated, and re-used. (I'm purposely using programmer words that a developer might understand.)
Shameless Self-Promotion: If you're a programmer who needs to write a user manual, the book reviewed here sounds like a great fit. But if you need to write a training course for the application you've created, check out my book, User Training for Busy Programmers. It gives you step-by-step instructions for developing an instructor-led software class. It takes a practical, condensed approach for when you don't have time to learn training theory.
User Training for Busy Programmers
It's sort of like thinking that just because you know how to use Word, you should be able to write like Shakespear...
"Eye halve a spelling chequer, It came with my pea sea, It plainly marques four my revue, Miss steaks eye kin knot sea"
Once you have something to show a potential employer, start applying for jobs.
People say I'm crazy, I got diamonds on the soles of my shoes...
I am a technical writer. I can say, without a shadow of a doubt, that most of the elements of style are proscriptive bullshiite. Besides, writing for Law or business is not the same as writing for tech.
For me to hear you say that engineers don't need to communicate clearly is, frankly, scary.
Why don't you point out where I said that? Communication is a two-way process. It requires comprehension as well. I said "past a certain point". Implicit in my argument is that people are able to communicate in such a way as to obtain a passing grade in a college-level language composition class. With that skill, any reasonably able person should be able to learn to communicate effectively the systematics of their project as it grows in complexity. That is why I said that process, and process documents, and training convincing engineers to use process communication document templates, are more critical and more useful than spending time sending engineers to technical writing classes, or seminars.
The disasters you describe did not stem from a lack of language composition skills and probably could not have been avoided no matter how many skilled technical writers could have been deployed. They stemmed from classic structural problems and chokepoints within the organizations. The information was well composed and available, but its gamut, dissemination, and flow within the management hierarchy was impeded, and in many cases stifled, by political and personality issues. That is what is used in communication studies when you talk about "discourse": the power politics of communication. Who is saying what to whom, and why. All the well-structured sentences and beautifully coherent essays in the world can't prevail against emplaced, willfully ignorant managers with conflicting agendas. As an example, I refer you to the USian head of state, George W Bush. A woefully bad communicator against whose policies many, many well-reasoned arguments have been advanced, but have proved ultimately futile. It's all about creating a Reality Based Community, and that is done in deeds, not in words.
Da Blog
YES! People who can't write or speak well also don't have a good understanding of the concepts. It's just the way it is, and the way it has to be.