Many programmers don't like to write. They think of it as the dreaded "documentation". They just want to write code. But what is writing code? It is a form of writing. I maintain that good programmers are good writers. The problem is that writing that is not coding does not appeal to them. But if you approach a writing task like you do a programming task, you'll notice a definite rise in the quality of your writing (to match the quality of your code). I am sure you'll challenge someone to the death if they dare imply that your code is not the greatest!
So what ideas can we bring to writing from the world of programming?
1. Test Driven Writing. If your coding can be test driven, why not "test drive" your writing? The "unit"
test for a written paragraph is your eyes and ears. Does it sound right? Does it look right? The "acceptance" test for a written piece, is someone else's eyes and ears.
2. Refactoring. You develop code by successive little refactorings till you are pleased with it, have removed all the redundancies, and "it works". Why not "refactor" your writing until "it works"? Look at your sentences and paragraphs and ask, "does this smell right"? In refactoring we go by "code smells". We have a catalog of things that "smell bad", and we attempt to remove them. Do the same with your English prose. Writers have practiced refactoring for centuries. They call it "editing".
If you're a fan of pair programming, there is a parallel there too. But if you're a solo developer, you'll be a solo writer also.So we'll leave pairing aside.
Some resources that can help with the writing task:
- BUGS in writing, A Guide to Debugging Your Prose. A delightful book by Lyn Dupre.
Follows the theme that writing may contain bugs, just like coding. Her main premise is, "the simplest way to improve your writing is to learn to avoid a limited set of common errors". Her main intent, as she states in a "Read Me" (instead of a Forward!), is "My intention is to convey to you the basic principles of good writing, and thus help you to develop ear ....". That is a key skill, "Ear" - a sensitivity to what good prose sounds like. Not different from detecting bad smells in code. The author develops a series of examples and presents them in a BUGS system: Bad, Ugly, Good, and Splendid. A Bad construction contains obvious mistakes and would be embarrassing. An Ugly construction is technically correct, but is not acceptable for one reason or other - well, it is just ugly. A Good construction is acceptable and correct, and would be fine - but you will want to do better. A Splendid construction demonstrates an improvement over a given good solution. The author's contention is that, "once you have developed ear, you will be able to tell without hesitation what constitutes correct syntax, style, and semantics, and will be equipped to communicate effectively with your fellow humans".
- Technically - Write! By Ron S. Blicq.
Good manual for technical writing. A little dated by now, but still a very helpful guide to technical writing with focus, brevity, and clarity. It goes over various forms of technical writing (technical correspondence, informal reports, formal reports, technical description, scientific papers, technical papers, etc.). It has a good section on technical speaking (briefing, papers, meetings, etc.).
- Line by Line - How to Edit Your Own Writing. By Claire Cook.
A good manual on editing.
- The Elements of Style, William Strunk, and E.B. White.
Strunk and White is the granddaddy of style manuals. A masterpiece of concise writing itself. A little book that is a must have, if you're serious about your writing.