A technique I like to use for creative insight is to map two concepts together using a metaphor, and then fill in the blanks where they don’t line up.
For instance, writing prose and writing a program have a few similarities and a few differences. When writing prose, we plan and arrange linearly since that is the main way our words will be read. In programming, however, we plan and arrange fractally since programs can make much more of reuse and referring to generic/abstract code.
Editing and proofing have the same similarities save one. For instance, both programming and prose can make use of static tools to some effect. Spell checkers and to an extent grammar checkers have made our lives easier and a red squiggly line under a misspelled word is as helpful as an immediate compiler warning from the line you just finished. Both these tools have their drawbacks too – they’re too focused, and can only catch ‘easy’ errors. A spell checker can’t tell you if your article is convincing, nor can a lint tool check your business logic.
The best means of improving quality of prose, and to an extent programming, is still the peer review and edit cycle. Due to the nature of our product, we have more tools in the chest besides peer review, however the nature of the review is almost exactly the same even though each product has drastically different uses and signs of quality.
Enough of similarities – how about differences? I can’t find, for example, an analogue to testing in writing. Testing seems to be completely derived from software (indeed, while it has some similarities to engineering tests, software style testing and debugging probably has the scientific method in its lineage rather than its suspected engineering heritage). This difference is interesting, but adds little to the discussion on the software side.
A more important difference is the editor role, and the general role of editing. It’s reasonably well established in literary disciplines that your first draft is, well, a first draft. You will be re-arranging it, slicing it up, adding here, taking away there, and fine tuning your diction before you’re done. I believe in software this is very similar to the practice of refactoring, but to a much larger degree. In software, refactoring is something we do if we have time, or something we’d like to do more of. In writing, editing is seen as just as value added as the original writing. Being an editor is a dedicated profession, while being a ‘refactor-er’ would be seen as skirting the important work of cranking out KLOC.
Maybe there is a lesson in here? Maybe software’s curse of reinventing the wheel even can be extended to re-discovering what other writers have known for centuries? Should we be spending as much as, if not more time rewriting and refactoring our programs as we do on our initial designs and prototypes?
No comments yet.