Slashdot Mirror

← Back to Stories (view on slashdot.org)

How Experienced And Novice Programmers See Code

Posted by Unknown on from the m-x-run-direct-neural-interface dept.

Esther Schindler writes "We always talk about how programmers improve their skill by reading others' code. But the newbies aren't going to be as good at even doing that, when they start. There's some cool research underway, using eye tracking to compare how an experienced programmer looks at code compared to a novice. Seems to be early days, but worth a nod and a smile." Reader Necroman points out that if the above link is unreachable, try this one. The videos are also available on YouTube: Expert, Novice.

12 of 238 comments (clear)

  1. Code? by Anonymous Coward · · Score: 5, Funny

    I see Blonde, Brunette,...

    1. Re:Code? by Beardo+the+Bearded · · Score: 5, Funny

      I see lack of comments, lack of comments, and god damned polish notation.

      Hungarian notation? I assume because of the "lack of comments".

      aHungarian nnotation? nI vassume abecause cof cthe alack cof ncomments

      FTFY

      --

      ---
      ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
    2. Re:Code? by Anonymous Coward · · Score: 5, Insightful

      An inexperienced coder sees code they have written, and everything else is unintelligible crap that only a moron would have written.

      An experienced coder just sees everything as unintelligible crap that only a moron would write.

  2. Contacting Server... by localman57 · · Score: 5, Funny

    At this moment, novice programmers think the network is down. Experienced programmers know the site from TFA has been slashdotted.

    1. Re:Contacting Server... by Ibiwan · · Score: 5, Funny

      Experienced programmers know the ENEMY'S network is down.

      --
      -- //no comment
    2. Re:Contacting Server... by tool462 · · Score: 5, Funny

      We read the article, just not before we comment. Usually I middle-click to open the article in a new tab, then read the comments. That way I know which parts of the article to indignant about when I get to them.

    3. Re:Contacting Server... by schlachter · · Score: 5, Funny

      TFA? I usually say FTA and comment away...

      --
      My God can beat up your God. Just kidding...don't take offense. I know there's no God.
  3. Comments by JesseMcDonald · · Score: 5, Interesting

    I imagine one of the first things a programmer learns about reading code, if they're going to be any good at it, is to skip over the inline comments. Reading them will only prejudice your interpretation of the code in favor of the original authors expectations, preventing you from seeing what the code is actually doing.

    Comments are useful when you come across a block of code you can't otherwise understand, but the rest of the time they tend to either duplicate information which is already in the code, or confuse matters by being vague, misleading, or just plain wrong.

    High-level documentation of modules and functions is invaluable, of course, but those comments should be in a block of their own, or even a separate file, and not be mixed in with the rest of the code.

    --
    "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
    1. Re:Comments by Anonymous Coward · · Score: 5, Insightful

      Comments that describe what the code is doing are useless. Comments that describe why the code does what it does are invaluable.

    2. Re:Comments by Trepidity · · Score: 5, Insightful

      If I'm reviewing untrusted third-party code, or code which is suspected to be buggy, I agree, but it really slows things down, even at an expert level, to completely ignore comments, if it's a setting where I'm working with people I know to be good engineers, and am not actively debugging/auditing their code. There has to be some amount of trust to make large projects work, and trusting that my colleagues are writing sane and reasonably accurate comments is one form of it. If it turns out to be wrong in a certain case, well, that's what tests are there to discover.

      --
      10 PRINT CHR$(205.5+RND(1)); : GOTO 10
    3. Re:Comments by Sperbels · · Score: 5, Funny

      You don't find this useful?

      //if Foos is empty don't do anything
      if (Foos != null)
      //let's go through the collection and increment the counter
      foreach (Foo foo in Foos)
      //increment the count
      foo.count++;

  4. Motivation and experience make the difference by davidwr · · Score: 5, Interesting

    My personal story:

    When I was but but a wee lad skill-wise, I read other people's code so I could figure out how it worked. I knew WHAT it was doing, just not HOW.

    Now when I read other's code it's usually either to figure out what it's doing or, more likely, what it's NOT doing that it's supposed to be doing.

    There's another difference:

    Now I can skip over the code that isn't "interesting" and zero in on where I think the bug is or where I think the "undocumented feature" is. My younger self had the luxury of time to study every line and learn as he did so.

    By the way, when I'm trying to learn something totally new, I do revert to "the way of the young learner." Why? Because it works when I'm starting nearly from scratch.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.