User Tag List

First 1234 Last

Results 11 to 20 of 57

  1. #11
    Senior Member Bushranger's Avatar
    Join Date
    Apr 2007
    MBTI
    INTP
    Posts
    169

    Default

    Your programmer personality type is:

    PHSB

    You're a Planner.

    You may be slow, but you'll usually find the best solution. If something's worth doing, it's worth doing right.


    You like coding at a High level.
    The world is made up of objects and components, you should create your programs in the same way.


    You work best in a Solo situation.
    The best way to program is by yourself. There's no communication problems, you know every part of the code allowing you to write the best programs possible.


    You are a liBeral programmer.
    Programming is a complex task and you should use white space and comments as freely as possible to help simplify the task. We're not writing on paper anymore so we can take up as much room as we need.


    For most of them I was looking at it thinking "It depends on the task"

    This test fails to identify pragmatists.
    I'll get you my pretty, and your little hermit crab too!

  2. #12

    Default

    Interesting, how long have you guys been programming. How long in a professional capacity.

    I've never actually met an experienced AND liBeral programmer. Comments can be a good thing (esp. in assembler), but most of the ones I saw were out of date and added to confusion. I call it the rule of documentation, it is always out of date and provides false information. Seems to be true in the hardware world also (but can't rely on "self-documenting" code, so it is a necessary evil).

    I was also surprised by the number of low-level programmers. But I was a pro. programmer back when Java was some-what of a novelty (just transitioned from 1.3 to 1.4 with new event model), and I loved not having to create a garbage collector for distributed applications. Performance slow down was negligible if it existed, and I figured with that having several times faster computers would make it even less noticeable. Also, with C#, XML, and .Net, the benefits seemed greater.

    As usual, it depends on the situation, what we'd chose, but I was still surprised by what people chose by default. meh.

    I hate computers and programs. The more I learn about them and how they are made, the more I hate them.

    Accept the past. Live for the present. Look forward to the future.
    Robot Fusion
    "As our island of knowledge grows, so does the shore of our ignorance." John Wheeler
    "[A] scientist looking at nonscientific problems is just as dumb as the next guy." Richard Feynman
    "[P]etabytes of [] data is not the same thing as understanding emergent mechanisms and structures." Jim Crutchfield

  3. #13
    only bites when provoked
    Join Date
    Apr 2007
    MBTI
    INTJ
    Posts
    2,127

    Default

    11 years professionally, 20 total.
    I 100%, N 88%, T 88%, J 75%

    Disclaimer: The above is my opinion and mine alone, it does not mean I cannot change my mind, nor does it guarantee that my comments are related to any deep-seated convictions. Take everything I say with a whole snowplow worth of salt and call me in the morning, if you can.

  4. #14
    Member
    Join Date
    Sep 2007
    MBTI
    INTP
    Posts
    35

    Default

    8 years as a hobbyist on various projects (open source, sourceforge, etc.) and 2 years professionally for corporate ..

    i comment for 2 main reasons ..

    1. if i don't comment and i have to revisit a project 2-3 months after i wrote the code then i spend approximately 20% of my time for the modifications on "re-reading and re-understanding" the code .. i try to use self-explanatory variables, etc. as much as possible but needless to say, proper documentation goes a long way in saving me tedious "study" time ..

    2. other programmers im required to work with do not read my mind ..


    As for low vs. high, I find low to be more challenging (fun) .. While high may get the job done quicker, it turns it into a "job" .. especially in a corporate setting ..

    Quote Originally Posted by ygolo View Post
    I hate computers and programs. The more I learn about them and how they are made, the more I hate them.
    why is that?

  5. #15

    Default

    Quote Originally Posted by Wolf View Post
    11 years professionally, 20 total.
    You were a conservative programmer as all experienced programmers I've met, in real life, have been. I've met a lot of liBeral "Script Kiddies", but that's a different thing I think from being a pro. programmer.

    But I suppose coding in any assembler would require a lot of commenting (unless macros are supported well). Mine tended to have close to every line commented.

    Quote Originally Posted by alexkreuz View Post
    8 years as a hobbyist on various projects (open source, sourceforge, etc.) and 2 years professionally for corporate ..

    i comment for 2 main reasons ..

    1. if i don't comment and i have to revisit a project 2-3 months after i wrote the code then i spend approximately 20% of my time for the modifications on "re-reading and re-understanding" the code .. i try to use self-explanatory variables, etc. as much as possible but needless to say, proper documentation goes a long way in saving me tedious "study" time ..

    2. other programmers im required to work with do not read my mind ..


    As for low vs. high, I find low to be more challenging (fun) .. While high may get the job done, it turns it into a "job" .. especially in a corporate setting ..
    I understand. I was just surprised.

    I was a big believer in self-documenting code, as being best, if possible. But I suppose you can get stuck in situations where it is not possible.

    I once had a running list saved of the funniest, most useless comments I ever came across.

    I saw this once:

    /*hack put in to fix issues*/
    and many similar comments. Most that I saw weren't much better.

    There were also a lot of:
    x+=3; /*add 3 to x */
    Something I thought you would only find in code written for school.

    Really, nothing better to improve code (and comments) than a peer-review process.

    The S-B combination I found weird. But I suppose you could work best alone, but prefer to be liBeral because you usually work in giant groups (like open source).

    Times have changed.

    Quote Originally Posted by alexkreuz View Post
    why is that?
    Because I know more and more how much potential is being wasted.

    Accept the past. Live for the present. Look forward to the future.
    Robot Fusion
    "As our island of knowledge grows, so does the shore of our ignorance." John Wheeler
    "[A] scientist looking at nonscientific problems is just as dumb as the next guy." Richard Feynman
    "[P]etabytes of [] data is not the same thing as understanding emergent mechanisms and structures." Jim Crutchfield

  6. #16
    Member
    Join Date
    Sep 2007
    MBTI
    INTP
    Posts
    35

    Default

    Quote Originally Posted by ygolo View Post
    /*hack put in to fix issues*/
    lol i had no idea you had it that bad .. yea ive seen things like that before as well but its unfair to call that "documentation" or calling the guy who wrote that a liberal programmer .. more like a lazy programmer ..

    liberal = don't be cheap with keystrokes (i.e. apply sunscreen lotion liberally)
    conservative = cheap (i.e. republicans lol)

    this is an example of my documenting / coding ..

    Code:
    // First step is to compare all the child nodes so that we can begin
    // the comparison of the child node's attributes. If all the attributes
    // of the child node check out, then the child node hasn't changed
    // and thus neither has the parent node. If any attributes in the child
    // node have changed, then the child node itself is set to HasChanged
    // and every parent node up the tree as well.
    for (int i = 0; i < this.ChildNode.Length; i++)
    {
        // Begin the process of comparing the current child node in the loop.
        this.ChildNode[i].CompareNode();
        // If the child node has changed, then set the parent node to HasChanged
        // as well.
        if (this.ChildNode[i].HasChanged)
        {
            this.HasChanged = true;
        }
    }
    i try to write my comments in complete sentences and proper english. the code is already in nerd-speak .. why should the documentation be?

    Quote Originally Posted by ygolo View Post
    Because I know more and more how much potential is being wasted.
    that is still too vague .. whose potential? why have you come to that conclusion?

  7. #17

    Default

    Quote Originally Posted by alexkreuz View Post
    lol i had no idea you had it that bad .. yea ive seen things like that before as well but its unfair to calling that "documentation" or calling the guy who wrote that a liberal programmer .. more like a lazy programmer ..

    liberal = don't be cheap with keystrokes (i.e. apply sunscreen lotion liberally)
    conservative = cheap (i.e. republicans lol)

    this is an example of my documenting / coding ..

    Code:
    // First step is to compare all the child nodes so that we can begin
    // the comparison of the child node's attributes. If all the attributes
    // of the child node check out, then the child node hasn't changed
    // and thus neither has the parent node. If any attributes in the child
    // node have changed, then the child node itself is set to HasChanged
    // and every parent node up the tree as well.
    for (int i = 0; i < this.ChildNode.Length; i++)
    {
        // Begin the process of comparing the current child node in the loop.
        this.ChildNode[i].CompareNode();
        // If the child node has changed, then set the parent node to HasChanged
        // as well.
        if (this.ChildNode[i].HasChanged)
        {
            this.HasChanged = true;
        }
    }

    This is very similar to

    Code:
    x+=3; /*Add 3 to x*/
    First thing I notice is that you seem to be writing C, essentially, in a C++ compiler and making use of the C++ style comments, and the this pointer. Not necessarily great for porting.

    If this is Java code, it probably shouldn't even exist, since it is barely object oriented. Who designed the over all system? No polymorphism? No predefined traversal pattern?

    Second, you used a lot of words in your comments to say the same thing your code already says (or at least attempts to say). This style of commenting is very conducive to hiding bugs, since people will read(or skip) over the code, and not scrutinize it, thinking that the code does what the comment says it does.

    Third, You could have used comments to clarify ambiguities. Pre-conditions, post-conditions, loop-invariants, structure/class invariants, other assumptions? What locking mechanism you are using? Are any of the function calls busy-waits?

    Quote Originally Posted by alexkreuz View Post
    i try to write my comments in complete sentences and proper english. the code is already in nerd-speak .. why should the documentation be?
    Because you have enough things to clarify to a professional that you ought not waste time and energy to clarify things to a amateurs. Commenting for amateurs also encourages managers to hire "warm bodies" for programming positions instead of discriminating for skill and experience.

    Quote Originally Posted by alexkreuz View Post
    that is still too vague .. whose potential? why have you come to that conclusion?
    I meant it about as generally as I said it, I hoped it would be obvious to those who work in the industry, and it is way off-topic.

    But some examples I hope are self-explanatory (unless you want to start another thread and wait for me to check in again).

    Society as a whole is not where it could be with the aid of computers.
    The computer tech. (software and hardware) is not where it could be.
    Programmer productivity is not where it could be.
    The productivity of you average office worker is not where it could be.
    .
    .
    .

    Accept the past. Live for the present. Look forward to the future.
    Robot Fusion
    "As our island of knowledge grows, so does the shore of our ignorance." John Wheeler
    "[A] scientist looking at nonscientific problems is just as dumb as the next guy." Richard Feynman
    "[P]etabytes of [] data is not the same thing as understanding emergent mechanisms and structures." Jim Crutchfield

  8. #18
    Member
    Join Date
    Sep 2007
    MBTI
    INTP
    Posts
    35

    Default

    well what can i say .. you've got a lot of critique about a project, the scope, time constraints, etc. of which you're unaware of .. no its not java, or c in a c++ compiler .. no its not a c++ compiler ..

    your suggestion that commenting will persuade programmers to "skip" over the actual code is ridiculous .. comments are meant to help developers understand the program's logic, not be a substitute for it .. programmers so lazy to skip over code simply because they are not forced to look at it due to liberal documenting shouldn't be programming anyway .. according to your logic we should remove all documenting and self-explanatory code altogether and effectively force the programmer to scrutizine the code to such a deep level that he might as well write it from the bottom up himself anyway .. it seems counterproductive to me ..

    finally, like i said .. the code does a nice job speaking "nerd" already .. i prefer to document in "english" .. if that means im documenting for "amateurs" then i suppose i don't have to document for "professionals" since they speak "code" anyway .. also you as a developer have little if any say in the matter of who is and is not hired .. you will only make the life of those who are hired more difficult by poorly documenting .. welcome to the corporate world .. and yes i've been there .. i've had to dissect a comment-less monstrosity ..

    i personally would rather make sure that the "amateurs" i work with understand the code properly and save myself the second trip of sitting down with them and explaining the code's logic verbally .. that would be a frustrating experience ..

    by the way, weeding out the "amateurs" isn't always a great thing to do .. some of the greatest programmers started out as "amateurs" .. and finally, i've always believed that those who do not or poorly comment / document are the real amateurs ..

  9. #19

    Default

    Please note that my critique of your code was not meant to be personal. This is the type of thing that comes up in code reviews. We debate the (de-)merits having code look a particular way.

    Quote Originally Posted by alexkreuz View Post
    well what can i say .. you've got a lot of critique about a project, the scope, time constraints, etc. of which you're unaware of .. no its not java, or c in a c++ compiler .. no its not a c++ compiler ..
    True. I don't know what language you are using. or what sort of time constraints you are dealing with, etc. It's been a while since I was in the software industry. It looked like C. C did not include "//" coments. C++ did. Maybe the standards have changed. I'm not writing the code.
    However, "laziness" would be indicated if I was writing it, and didn't submit it to peer-review or look at the language standard to see if my compiler is letting me get away with things not in the standard.

    Quote Originally Posted by alexkreuz View Post
    your suggestion that commenting will persuade programmers to "skip" over the actual code is ridiculous .. comments are meant to help developers understand the program's logic, not be a substitute for it .. programmers so lazy to skip over code simply because they are not forced to look at it due to liberal documenting shouldn't be programming anyway .. according to your logic we should remove all documenting and self-explanatory code altogether and effectively force the programmer to scrutizine the code to such a deep level that he might as well write it from the bottom up himself anyway .. it seems counterproductive to me ..
    That is not what I said.

    I said that comments that say the same thing as the code are not helpful. They are, infact, a maintenance problem. It is a psychological trick of "mindset". Again, in a code-review situations, when other people are scanning for bugs in your code, having comments like this tend to have people miss bugs. I don't know why it happens, but in my experience, it does.

    There are other resons why comments like that are maintainance issues.
    The same reasons having code copied-and-pasted in several places is a problem. It makes the code-review process (where others are given your code, so they can scan the code for bugs and clarifications) less helpful, due simply to the amout of reading each reviewer has to do. We are all human, it is not laziness to want to read less. When I submit code for review, I am asking for a favor, having people have less to read is a courtesy.


    Quote Originally Posted by alexkreuz View Post
    finally, like i said .. the code does a nice job speaking "nerd" already .. i prefer to document in "english" .. if that means im documenting for "amateurs" then i suppose i don't have to document for "professionals" since they speak "code" anyway .. also you as a developer have little if any say in the matter of who is and is not hired .. you will only make the life of those who are hired more difficult by poorly documenting .. welcome to the corporate world .. and yes i've been there .. i've had to dissect a comment-less monstrosity ..
    If you are calling your peers "nerds", you have other issues also. English is not my first language, and it is not the main language of many programmers. English is, in my opinion, one of the most inconsistent, and illogical laguages there is, but it happened to be the language of those who developed Computer Science. An accident of history.

    My point is, people who are hired to program in a language, or review the code, should either know the language or have access to enough reference matierial to know it well soon.

    No other engineering profession aims their documentation to other practitioners at the "layperson". They hire tech-writers to do that. If they are making schematics for technician to execute they make another type of documentation. For assembly, they make another.

    Comminication to do transfer info. from technical person to tech-writer should be done in several question and answer sessions. Not implicitly through code that gets chucked over the wall.

    My point is: you have an audience. Aim your comments at the appropriate audience (I would be surprised if comments to code actually had an audience of people who don't know the programming language, but I guess times really have changed).

    Quote Originally Posted by alexkreuz View Post
    i personally would rather make sure that the "amateurs" i work with understand the code properly and save myself the second trip of sitting down with them and explaining the code's logic verbally .. that would be a frustrating experience ..
    That seems to me, to be true "laziness". That "frustrating experience" is exactly what you need to have. Hand poeople printed out copies of your code, explain what it is you want it to, and have them scrutinize your code and comments for correctness and clarity. I learnt a lot from these experiences.

    Quote Originally Posted by alexkreuz View Post
    by the way, weeding out the "amateurs" isn't always a great thing to do .. some of the greatest programmers started out as "amateurs" .. and finally, i've always believed that those who do not or poorly comment / document are the real amateurs ..
    By "ameteur", I meant someone who didn't understand the language you are using. I think you are probably underestamiting your audience here.

    And yes comments are needed. Spend a lot of time reverse engineering other peoples code, and have a lot of code reviews, and you will know what type of comments are good, and what are bad. You will also get a feel for what is actually "self-documenting" code (code that doesn't need comments).

    Code reviews people, code reviews.

    Accept the past. Live for the present. Look forward to the future.
    Robot Fusion
    "As our island of knowledge grows, so does the shore of our ignorance." John Wheeler
    "[A] scientist looking at nonscientific problems is just as dumb as the next guy." Richard Feynman
    "[P]etabytes of [] data is not the same thing as understanding emergent mechanisms and structures." Jim Crutchfield

  10. #20
    Member
    Join Date
    Sep 2007
    MBTI
    INTP
    Posts
    35

    Default

    I think you are misunderstanding the point completely. I'll simply say .. Documentation isn't supposed to explain what the code does .. Documentation is supposed to explain the reasons why the programmer wrote what he did, when he did, and why he did .. Documentation should NEVER explain HOW he did, because the CODE is supposed to explain that part ..

    /*Add 3 to x*/ is a perfect example of bad documentation because it described exactly what the code does .. We both agree that anybody who is a programmer should be able to read the code, and figure that part out.

    Documentation is supposed to explain to the next person reading the code, WHY the previous programmer did what he did .. "If all the attributes of the child node check out, then the child node hasn't changed"

    You know I won't get into people of different languages, because I did work on a project which was 100&#37; commented in Japanese, but needless to say it didn't help that the "self-explanatory" variable names and such were also in Japanese. Yes it took a LOT of time reverse-engineering it and in those sort of cases its unavoidable. But that example is a worst case scenario in which case it really makes no difference whether or not you document at all.

    I never suggested that documentation is an alternative for proper coding .. However I'm not going to expect the next person who touches my code to expect to read my mind .. I don't document the programming language (C# in this case) .. I document my logic .. Why I wrote what I did ..

    I think expecting to be "verbally taught" by a former developer of the project is quite naive, since the case is more often than not that the former developer has quit the project. It tends to flow that way.

    My audience is composed of fellow or future programmers, and myself, who are incapable of reading my mind and figuring out the logic I used to write the code by simple telepathy, or in my case, am subject gaps in my own memory due to not caring enough about a project to remember why I wrote what I did ..

    An accident of history.
    What can I say .. I'm expected to program in the real world whether i like it or not .. And in the real world documentation is required to be in english since more often than not, the paycheck comes from somebody who signs it in english.

    By the way, I did google this subject since I was curious what the thought on this topic was and needless to say its a hot debate that isn't solved elsewhere ..

    Linux.com :: How to document your code

    However thanks to our discussion and my following "research" I found an amazing documenting resource called Doxygen which automatically generates external HTML documentation for your code. It will give summaries and such as well provided they were documented in the first place in the code. I think you should check it out cuz I found it pretty amazing.

    Doxygen

Similar Threads

  1. Jung Preference Exploration Personality Test (Similarminds)
    By MerkW in forum Online Personality Tests
    Replies: 140
    Last Post: 06-27-2014, 06:25 AM
  2. Philosophical personality test
    By SolitaryWalker in forum Online Personality Tests
    Replies: 323
    Last Post: 09-03-2013, 10:06 PM
  3. Magical Personality Test
    By surgery in forum Online Personality Tests
    Replies: 124
    Last Post: 07-14-2009, 10:49 AM
  4. The brutally honest personality test
    By Sahara in forum The Bonfire
    Replies: 64
    Last Post: 02-28-2009, 02:06 PM
  5. The Egoload Personality Test
    By UnitOfPopulation in forum Online Personality Tests
    Replies: 5
    Last Post: 12-16-2007, 04:46 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Single Sign On provided by vBSSO