|
Almost 
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
PhilLenoir wrote: The Documentors - weren't that nasties in Harry Potter?
No, they had a different name and were just the end result of trying to document something.
|
|
|
|
|
Sander Rossel wrote: I hate documenting my code
One company I worked for, we had documentors that created the documentation in parallel with us.
We'd occasionally upset the documentors when we found we had to change something, but we tried to keep it to a minimum.
That worked fairly well. Particularly since English was no longer the primary language for the programmers.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
Sounds a bit like pair programming, but with one doing documentation.
That might actually work...
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
I really enjoyed it.
One case in particular, I had written what I called the "Custom Output Processor" for our database product. I had implemented an RPN style calculator so you could do math before displaying the results on the report. It also had commands for copying fields to the report. It was driven by a table of opcodes and arguments that were interpreted by the code. I had user opcodes like RCL, STO, PRT.
I was writing the next generation and wanted to make the processing orthogonal and was merrily adding new opcodes like INP, WRT, etc., and the documentor threw up her hands and declared it unteachable.
That caused me to pause and recognize she was correct. I redesigned it replacing all the different user opcodes with MOV and the arguments determined the internal opcode for processing.
I was particularly pleased because I made it code compatible with the earlier version. You may have written your processing in the earlier version with RCL and STO, but when you opened them in the newer version, you'd see them converted to MOV with the arguments indicating if you were reading a field, register, or an output field.
It really helped having a "non-technical" person commenting on what you were creating.
(BTW the database was The Data Factory published by Micro Lab, Inc for the Apple II)
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
BrainiacV wrote: It really helped having a "non-technical" person commenting on what you were creating.
Sounds useful.
BrainiacV wrote: The Data Factory
Haven't heard of it.
BrainiacV wrote: Micro Lab, Inc
Haven't heard of it...
BrainiacV wrote: Apple II
Haven... Oh wait, I know Apple! The Apple II was released about ten years before I was even born (not to make you feel old or anything, I guess I'm just young) 
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
No offense taken. It was a long time ago, in a ... (wait, are you too young to recognize the reference? )
Beseech the God Google for "The Data Factory" "Micro Lab" and you'll find reviews.
It was an old flatfile database program.
And no, I'm not Bill Passauer, I was hired to clean up his, uh, code and myself and another ended up rewriting it completely. But that's another story.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
BrainiacV wrote: It was a long time ago, in a ...
I believe that movie came out in the same year as the Apple II ('77) and it's one of my favourite movies ever 
So I guess there goes my excuse 
BrainiacV wrote: Beseech the God Google for "The Data Factory" "Micro Lab" and you'll find reviews.
I won't actually 
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Mike Hankey wrote: Why is it that we as programmers hate to document?
I must be some weird outlier because I actually quite enjoy documenting, everything from story boarding to code docs to architecture acceptance test procedures (probably nobody has heard of those things nowadays) to user manuals.
One thing that's fun about documentation is that I often have the experience "oh wow, I could have done that so much better this way."
I also find it interesting, in a sort of sad way, how little pre-code documentation is written, stuff like architecture, diagrams of component interactions, etc. To me, that stuff is like writing an outline to a book -- if you do it well, the book basically writes itself afterwards. Same with architecture / design docs -- do it well and the code "just happens." Sure, there are always sticky areas, but overall, that's been my experience.
Then again, we really don't have decent tools for a) documenting from code and b) coding from documentation. Even simple things like diagramming a state system or inter-module events, where are the tools to generate the code in a language agnostic way but still cognizant of the language features and framework the dev wants to work in? They don't exist. What I find tedious is not the documentation, but having a pretty diagram in Visio and then having to write the damn code, when I should have a tool to at least generate 90% of the code for me!
Anyways, enough of that soapbox. 
Marc
|
|
|
|
|
I agree documentation tools are pretty much non existent, pity would really help poor souls like me.
I think my biggest problem is my grasp of the English language. One tends to fear what one does not understand.
You, Sasha, Nish and others have a writing style that I envy.
I excel in other areas; trivia, kick the can, distance spitting, etc..
New version: WinHeist Version 2.1.0
There's a fine line between crazy and free spirited and it's usually a prescription.
I'm currently unsupervised, I know it freaks me out too but the possibilities are endless.
|
|
|
|
|
Self Documenting Code... I always thought it was a buzz word way to get out of using comments/documentation, I have hardware projects to take over that were self documenting apart from the input, power amp it wasn't! same with code 'Oh I see what is being done, but why?' is a common in my experience!
|
|
|
|
|
I'm finding that with hardware I need to document also but in a different way; I keep notes, schematics, images of the final product, etc. then when I go back some time later it is a lot easier to remember seeing that I have the CRS syndrome.
New version: WinHeist Version 2.1.0
There's a fine line between crazy and free spirited and it's usually a prescription.
I'm currently unsupervised, I know it freaks me out too but the possibilities are endless.
|
|
|
|
|
Quote: kick the can, distance spitting
Ow! you got me TWICE
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
|
|
|
|
|
You don't get paid enough to document code.
I'm looking at very sparse data array of informative statistics about contacts from my landlord warning me of imminent water shut offs. I see four notices over a years' time, and only two of them in which the water was indeed shut off.
How is this data? It's uninteresting PLUS it's only pseudo valuable in that it contains only partial information about what it's entitled to contain.
Perhaps if the water really did get shut off, I'd be happier about being notified.
|
|
|
|
|
RedDk wrote: You don't get paid enough to document code.
I don't get paid anything for writing code, I do it for the fun of it.
New version: WinHeist Version 2.1.0
There's a fine line between crazy and free spirited and it's usually a prescription.
I'm currently unsupervised, I know it freaks me out too but the possibilities are endless.
|
|
|
|
|
Mike Hankey wrote: I don't get paid anything for writing code, I do it for the fun of it.
Right, they pay me to do it for them.
Although, most of what they have me doing is SSIS and that's not code.  There has been some coding fun this week as I have been working with the TFS API.
|
|
|
|
|
I have enjoyed writing doco precisely once in my entire life, in the early 90s I got paid approx $5k to build an app. In the late 90s they wanted to rewrite it into Delphi, when I refused they asked me to write the technical spec so their coders could work from it, I charged $20k and laughed all the way to the bank.
It is the only time I think I have actually done a good job of doco, they got their moneys worth.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mike Hankey wrote: Why is it that we as programmers hate to document?
I wonder if there is a correlation between the dislike for wanting to write documentation and writing research papers. I don't care for writing documentation and I never cared much for writing research papers in college. I had to do it, but I didn't like it.
Thus, my hypothesis is, if you like writing in general, you will not mind writing documentation.
|
|
|
|
|
When I first started in the industry, the standard was that documentation was to be completed before the first line of code. Some refer to that method as the waterfall method. Today, you seldom see documentation; or, what little there is seldom reflects the product for which it is written.
As a basic rule of thumb, write your documentation for an eight-year-old. (I used to have my daughter do the final edit of my documentation until she was eleven.)
|
|
|
|
|
Member 10707677 wrote: documentation was to be completed before the first line of code
That's just a specification. I've seen a few of those, read them, said "OK here's a better way to do that", and wrote something that actually made sense instead.
Where I am now I just keep saying "documentation is out of date as soon as it's published".
|
|
|
|
|
I've once read some self documenting code. I hit a point where I said to myself "that is just plain wrong logic". When I brought it to the attention of my manager, we couldn't change it because it was written per the spec document. I asked to see the spec document. I conceded the code did exactly what the spec said it should. She thought the matter was closed when I added "It's too bad it isn't doing what it is intended to do." We spent another hour going though the code to prove that what I saw in fifteen seconds was true. (fixed by changing "<" to ">" or vice versa)
|
|
|
|
|
Your mention of self-documenting code reminds me of my university days. One of my professors threatened to fail us if we didn't include comments in the source code. This was in the age when punch cards were still being used, so comments were a nuisance. One of the students turned in a final project with a single comment "RUN PROGRAM" as the first card of the deck. The result, when run, was a listing of the source code with accompaning commentary. Needless to say, he passed.
|
|
|
|
|
Member 10707677 wrote: documentation was to be completed before the first line of code. Some refer to that method as the waterfall method.
There seems to be different definitions for that method. Some studies have found the most successful projects used a combination of waterfall and agile methods combined. Waterfall starts with an overall plan and relationships. Those ideas are then documented separately breaking it into more plans and relationships. If you keep going like that you can easily get bogged down. Once you get down to about two-three levels, I can see the benefits of abandoning waterfall at that point and going to agile to get early results of the pieces documented to that point.
|
|
|
|
|
Early on I spent a great deal of time on documentation only to have it never referenced. I don't mind doing training materials because they are used, but developer docs are a waste of time because devs don't look at it.
|
|
|
|
|
For one thing, managers generally don't factor documentation time into coding deadlines, so if you spend time documenting it can look like you aren't getting your "real" work done fast enough.
But the larger problem is keeping it up-to-date. You may have time to do the initial documentation, but are you going to have time to update it with every change? What about when another team member ninja-edits the code, are you going to regularly check and make sure the documentation still matches the code?
I used to try very hard to have good documentation, but I found it to be hopeless. You end up with outdated documentation, which is often worse than no documentation at all. I don't buy the "code should document itself" argument, but for practical purposes that's where we're at, even if you have documentation you still have to go through the code and make sure the documentation isn't lying to you.
Edit: There's one time when documentation should be mandatory: when you are leaving a job. You likely aren't going to be needed to meet a coding deadline during your last two weeks, so spend that time documenting the systems you've been responsible for so the next person has something to go by when they pick up those systems. It's good karma, and that's when documentation is really needed and will get read.
modified 19-Dec-14 12:14pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
