Most of the stuff I've done has had little documentation because programmers hate to document, so we just don't bother. Not that that's necessarily a good thing, but at the moment we have a couple of BSAs and they do most of the documentation, leaving us to the more enjoyable activitiesOriginally posted by: Nitemare
Originally posted by: Skoorb
Oh man documentation can be such a pain in the ass!Not to mention the fact that I end up writing 20 pages of documentation for every 10 lines of code.
Yet another reason not to program. I used to get dings all the time from my C++ instructer about not writing documentation with my source file.
My response..Does it work?
Then go stick your documentation up your :Q. What's the point of programming if you are going to spend 2/3 of your key strokes writing up an explanation of how every line of programming works? I'm a programmer dammit not a teacher.
Originally posted by: NogginBoink
Originally posted by: alkemyst
To get a job in the IT field seems to be certs and experience....in general though most I have met have no real skills, look up most solutions in previous tickets or google them.
Actually, I would argue those are valuable IT skills.
I guess I'm a hybrid I will remember enough keywords that I can search for how to do the thing again Damnit though there is one thing I can never remember. There is a math function that uses a % during divison: like 10%3 = 3, because you divide by 3 and kill the remainder. I can never remember the syntax for that buggar. I only use it about every 18 months though...Other than the fact you just love to jump into threads with a half-cocked statement....when someone knows nothing but how to search and doesn't retain the previous solution, it's a problem.
Originally posted by: Skoorb
I guess I'm a hybrid I will remember enough keywords that I can search for how to do the thing again Damnit though there is one thing I can never remember. There is a math function that uses a % during divison: like 10%3 = 3, because you divide by 3 and kill the remainder. I can never remember the syntax for that buggar. I only use it about every 18 months though...Other than the fact you just love to jump into threads with a half-cocked statement....when someone knows nothing but how to search and doesn't retain the previous solution, it's a problem.
Originally posted by: dabuddha
Unfortunately yes. And it frustrates me to no end because I have so many friends that are unemployed.
Documentation = bad job security. If nobody else can read it they need you when it breaks! I hate documentation, and in terms of commenting...well I just don't do it unless what I'm doing is a very complex function or it seems very weird, so I may give a few lines in case somebody is reading it so that they can see why the hell I did it that way. Otherwise, no comments for you!Originally posted by: BoberFett
If you don't document your code and I ever have to work on it, I will hunt you down and kill you.
Documentation is extremely important in a large development project, or even in a small one that somebody else will have to maintain.
Originally posted by: Nitemare
.... And besides all those jobs will be in India soon anyways
Originally posted by: Skoorb
Documentation = bad job security. If nobody else can read it they need you when it breaks! I hate documentation, and in terms of commenting...well I just don't do it unless what I'm doing is a very complex function or it seems very weird, so I may give a few lines in case somebody is reading it so that they can see why the hell I did it that way. Otherwise, no comments for you!Originally posted by: BoberFett
If you don't document your code and I ever have to work on it, I will hunt you down and kill you.
Documentation is extremely important in a large development project, or even in a small one that somebody else will have to maintain.
Originally posted by: alkemyst
Originally posted by: Skoorb
I guess I'm a hybrid I will remember enough keywords that I can search for how to do the thing again Damnit though there is one thing I can never remember. There is a math function that uses a % during divison: like 10%3 = 3, because you divide by 3 and kill the remainder. I can never remember the syntax for that buggar. I only use it about every 18 months though...Other than the fact you just love to jump into threads with a half-cocked statement....when someone knows nothing but how to search and doesn't retain the previous solution, it's a problem.
it's the mode/modal function....knowing the name of what you are doing may be half the battle.
I use google for a lot, almost everything I will do a quick check to verify what I am about to do....it's not that google or searching is a bad solution...it's just when that's the only thing one knows how to do that it's bad.
Originally posted by: gopunk
Originally posted by: Skoorb
Documentation = bad job security. If nobody else can read it they need you when it breaks! I hate documentation, and in terms of commenting...well I just don't do it unless what I'm doing is a very complex function or it seems very weird, so I may give a few lines in case somebody is reading it so that they can see why the hell I did it that way. Otherwise, no comments for you!Originally posted by: BoberFett
If you don't document your code and I ever have to work on it, I will hunt you down and kill you.
Documentation is extremely important in a large development project, or even in a small one that somebody else will have to maintain.
and what happens when they give you code that you wrote 2 years ago and ask you to fix it? at the very least, save a documented version for yourself, if you're worried about job security. it's simply shoddy workmanship not to comment your code.
Originally posted by: Descartes
Originally posted by: gopunk
Originally posted by: Skoorb
Documentation = bad job security. If nobody else can read it they need you when it breaks! I hate documentation, and in terms of commenting...well I just don't do it unless what I'm doing is a very complex function or it seems very weird, so I may give a few lines in case somebody is reading it so that they can see why the hell I did it that way. Otherwise, no comments for you!Originally posted by: BoberFett
If you don't document your code and I ever have to work on it, I will hunt you down and kill you.
Documentation is extremely important in a large development project, or even in a small one that somebody else will have to maintain.
and what happens when they give you code that you wrote 2 years ago and ask you to fix it? at the very least, save a documented version for yourself, if you're worried about job security. it's simply shoddy workmanship not to comment your code.
I've always disagreed with the "always comment" mentality quite simply because they are almost always misused:
- The comments are either way too granular or too coarse; never seems to be an acceptable middle ground. e.g.:
// Calculates tax total, transacts a deposit, does a bunch of other things that should be refactored into their own functions, etc.
void SomeFunction()
// Add tax total
runningTotal += taxTotal;
Contrived examples, yes, but they happen all the time in the wild. The point is that comments are often used to supplement the fact that the code isn't readable, and that naming conventions were not used. If SomeFunction() were properly refactored using lucid names, no comments as to its function would be needed. The second comment was entirely superfluous, and the abstraction was not that much higher than the actual code itself. I just want to see the code.
- The comments are decoupled from the code and thus do not reflect what the code actually does. People often change code and not the comments, so what you're left with are invalid comments. A single invalid comment makes me distrust any other, so it renders them completely useless at this point. This is ameliorated slightly by the inclusion of comment facilities in the language itself (e.g. JavaDoc, C# XML Comments, other preprocessors for C or C++, etc.). To maintain comments AND code means you have two changes for every one; this violates basic development principles such as DRY and OAOO.
Ok, I'm typing too much, so those should be enough. I'm not at all against documentation; however, I am against using them to supplement an inherent problem in the codebase. I am also against them when they are superfluously used, as heavy commenting makes code much harder to read. It's my opinion that quality code is MUCH easier to read than trying to understand what the programmer is saying (code is unambiguous, the semantic value of language is entirely ambiguous).
IMO.
Originally posted by: gopunk
Originally posted by: Descartes
Originally posted by: gopunk
Originally posted by: Skoorb
Documentation = bad job security. If nobody else can read it they need you when it breaks! I hate documentation, and in terms of commenting...well I just don't do it unless what I'm doing is a very complex function or it seems very weird, so I may give a few lines in case somebody is reading it so that they can see why the hell I did it that way. Otherwise, no comments for you!Originally posted by: BoberFett
If you don't document your code and I ever have to work on it, I will hunt you down and kill you.
Documentation is extremely important in a large development project, or even in a small one that somebody else will have to maintain.
and what happens when they give you code that you wrote 2 years ago and ask you to fix it? at the very least, save a documented version for yourself, if you're worried about job security. it's simply shoddy workmanship not to comment your code.
I've always disagreed with the "always comment" mentality quite simply because they are almost always misused:
- The comments are either way too granular or too coarse; never seems to be an acceptable middle ground. e.g.:
// Calculates tax total, transacts a deposit, does a bunch of other things that should be refactored into their own functions, etc.
void SomeFunction()
// Add tax total
runningTotal += taxTotal;
Contrived examples, yes, but they happen all the time in the wild. The point is that comments are often used to supplement the fact that the code isn't readable, and that naming conventions were not used. If SomeFunction() were properly refactored using lucid names, no comments as to its function would be needed. The second comment was entirely superfluous, and the abstraction was not that much higher than the actual code itself. I just want to see the code.
- The comments are decoupled from the code and thus do not reflect what the code actually does. People often change code and not the comments, so what you're left with are invalid comments. A single invalid comment makes me distrust any other, so it renders them completely useless at this point. This is ameliorated slightly by the inclusion of comment facilities in the language itself (e.g. JavaDoc, C# XML Comments, other preprocessors for C or C++, etc.). To maintain comments AND code means you have two changes for every one; this violates basic development principles such as DRY and OAOO.
Ok, I'm typing too much, so those should be enough. I'm not at all against documentation; however, I am against using them to supplement an inherent problem in the codebase. I am also against them when they are superfluously used, as heavy commenting makes code much harder to read. It's my opinion that quality code is MUCH easier to read than trying to understand what the programmer is saying (code is unambiguous, the semantic value of language is entirely ambiguous).
IMO.
yes, well you should also practice good documentation too... i didn't mean to imply that people should blindly comment every single println or something... sorry if it came across that way. i just think that somebody reading the code (with programming knowledge) should be able to quickly and easily see what it's doing. i suppose there are some programs where you don't need to comment because the code is so blatantly obvious, but these are pretty scarce in my limited experience.
Originally posted by: NogginBoink
Yes, it is becoming more noticeable.
I work in tech support. My customers are generally IT staff and not end users.
The biggest thing I've noticed is the field of consultants. It seems the only prerequisite for becoming a consultant is to have a pulse. I've occasionally wanted to ask incredulously, "They PAID YOU MONEY to tell them that!?" or on the flip side, "you PAID SOMEONE to screw your company up like that!?"
Of course, I don't say that.
I've also found (and it pains me to admit this) that when a caller has one of a few certain accents, he's more likely not to know his stuff, to lie to me about what he did/didn't do before the problem started, and blame me for his mistakes.
Originally posted by: Descartes
Originally posted by: Tiles2Tech
Originally posted by: dabuddha
Unfortunately yes. And it frustrates me to no end because I have so many friends that are unemployed.
Same here. This is very frustrating to see -- but, the ones that can talk are those who make the big $$. They B.S. their way into positions even though their skill levels are not up to par. Also, you have plenty of people who get into I.T. because of the money --- not because the work is in their hearts --- which is a big mistake in my opinion. I love I.T. -- worked in it before it paid very well and then went on to get my bachelor's degree in that area, too. However, the dry market has left me a bit disappointed and I don't want to have to move 3,000 miles to work -- especially when I live in a heavily "technical corridor" of Northern Virginia.
Obviously you're underestimating the power of social abilities. As I've said in many IT-related threads, so many ITers absconded to their cubes and had little involvement in any business aspects of their work. I always called them "cube monkies", and a monkey's work can be commoditized.
Don't assume that everyone who "can talk" bullsh1tes their way into positions. Most of the extremely high-quality IT people I know are extremely affable and very talented. They know how to communicate to those who consider details to be a nuisance. They know how to sell their abilities and to acquire new projects. These people are the ones that succeed, and it's certainly not for lack of technical ability.
Understand that there exist two values of IT: business, and technical. A technically palatable solution does not a business value make, and vice versa. IT people need to learn to appreciate that there is a distinct business value completely independent of a technical one. I am at times frustrated by the kinds of solutions used, but the fact is that they fulfill the business value; indeed, the very value that allows you to keep your job and further your career.
Inconceivable. My code is perfect and thus requires no fixing.and what happens when they give you code that you wrote 2 years ago and ask you to fix it? at the very least, save a documented version for yourself, if you're worried about job security. it's simply shoddy workmanship not to comment your code.
Originally posted by: Skoorb
Inconceivable. My code is perfect and thus requires no fixing.and what happens when they give you code that you wrote 2 years ago and ask you to fix it? at the very least, save a documented version for yourself, if you're worried about job security. it's simply shoddy workmanship not to comment your code.
Actually I do comment sometimes, but as always Descartes's articulations are more precise than mine heavy commenting makes code much harder to read. It's my opinion that quality code is MUCH easier to read than trying to understand what the programmer is saying (code is unambiguous, the semantic value of language is entirely ambiguous).
.
In truth most of what I write, and most of what I come upon, is fairly obvious as to what it's doing. Now, if I came upon a dll that was responsible for a lot of functionality and the writer before me was using it all over the place without so much as a hint as to what it did, well that would be annoying. But, most of the time it's fairly apparent understanding what a person did, since as Descartes said, it's unambiguous, even though different people will go about things in different ways. And we all know that a poor approach can make reading the code later particularly difficult (like in the application I mentioned).
Yet I bet he could code circles around you in Cobol or Fortran