March 10, 2017 at 6:29 pm
Comments posted to this topic are about the item The Details are in the Small Print
Best wishes,
Phil Factor
March 11, 2017 at 1:17 pm
I once had to update an ancient Visual Basic 4 (yes, that is not a typo) application. The code had gone through many versions and was littered with comments about what each function did and much more besides. There were way more comments than actual code. Very daunting to read for the first time.
***BUT*** when it came to doing the update, those comments made all the difference and helped enormously. I learned a lot from that ancient programmer. And that project is the reason that these days, when I spend more than(say) 10 minutes struggling to get a statement just right I often add a comment so that the next person won't have to figure it out all over again (that person could well be me a few months later). Clever one-liners are fine for a one-off throw-away situation (and oh so satisfying), but for code that must run over and over again, comments are more important than elegance.
March 13, 2017 at 12:58 pm
I think one of the problems is that we all know good documentation when we see it but the definition of good documentation is elusive.
The art of writing documentation is an unrecognised skill. The skill is in boiling something complicated down into an easily digested piece of information. If you have the skill then your output will be so simple as to underrepresent the effort required to write it
March 13, 2017 at 3:35 pm
I assume we're talking about the need for the developers to create technical and operational documentation here, since the business should be exclusively providing the requirements documentation, at least collaborating with the developer on functional specifications, and then the business exclusively provides the end user documentation.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 14, 2017 at 12:53 pm
"Sure, there are many more exciting activities in life,but if you can master the art of writing the whole range of documentation thatunderlies the development and upkeep of modern business systems in the typical enterprise, then you are greatly empowered."
Some of my best documents that I still refer to on occasion are functional specs I've written for contract developers. Those must be exact and nearly perfect or you won't get the system you want without, typically, more $$.
March 15, 2017 at 8:56 am
Phil Factor - Friday, March 10, 2017 6:29 PM...Others delude themselves with the belief that their code is 'self-documenting'...
Is it coincidence that these people are often not the best communicators anyway? In my experience the majority of people who believe their code is self-documenting will, when asked a question, repeatedly suggest that you read their code. Even if they already know that you have.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 15, 2017 at 10:11 am
Gary Varga - Wednesday, March 15, 2017 8:56 AMPhil Factor - Friday, March 10, 2017 6:29 PM...Others delude themselves with the belief that their code is 'self-documenting'...Is it coincidence that these people are often not the best communicators anyway? In my experience the majority of people who believe their code is self-documenting will, when asked a question, repeatedly suggest that you read their code. Even if they already know that you have.
Pairing up two developers who both believe their code is self-documenting; that is poetic justice.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply