Cart
[Home] [By Thread] [By Date] [Recent Entries]
tpassin@h... wrote: > > Yes, I know, but better writing/editing makes the result stronger and > (potentially, at least) more useful to those same companies. I'd remove the "potentially". The result is always more useful. The schema spec is a good example. Once I finally waded through it, I found I liked most of what it offerred. Contrast that with the fact that even now, whenever I pick it up, I get really p----d off at the fact I can't understand anything it says. I can't help but wonder how much of the controversy over schemas was due simply to frustration. Never underestimate human factors in getting specs accepted in the marketplace ... > Terseness can be fine, and writing for the experienced practitioner is too. > But have you noticed, when you try to refine and improve the communication > of the concepts, it helps you understand or even discover what they really > are? Or it may help you find assumptions you didn't realize were there. Writing is actually my first and strongest line of defense for debugging code. If I can't write a simple comment explaining the code, then it's time to start redesigning and recoding. Almost all of the bugs that survive are typos (e.g. = instead of ==) and the few design bugs that survive are ones where I never really was able to write a simple comment. -- Ronald Bourret Programming, Writing, and Training XML, Databases, and Schemas http://www.rpbourret.com
|
