Slashdot Mirror


How Experienced And Novice Programmers See Code

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.

55 of 238 comments (clear)

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

    I see Blonde, Brunette,...

    1. Re:Code? by Rockoon · · Score: 4, Insightful

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

      --
      "His name was James Damore."
    2. Re:Code? by NeoMorphy · · Score: 2

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

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

    3. 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.
    4. 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.

    5. Re:Code? by boristdog · · Score: 3, Insightful

      Polish: Making wood shine at the beginning of a sentence.

    6. Re:Code? by t4ng* · · Score: 2

      CamelNotation ? IAssumeBecauseOfTheLackOfComments : '';

    7. Re:Code? by Anonymous Coward · · Score: 3, Insightful

      I feel immense shame, horror and bewilderment when I look at my old code. Did I really write this rubbish?

    8. Re:Code? by Hognoxious · · Score: 4, Informative

      Polish notation is the one where it looks like Yoda speaking. Hungarian is where it looks like R2D2 dictated it.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    9. Re:Code? by Dekker3D · · Score: 2

      DontYou_hateThose_nProgrammersWho_just_use_whats_con_feckin_venient?

  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 SirGarlon · · Score: 4, Funny

      So much for the idea that Slashdot readers never look at TFA. However, I remain undaunted, and will now proceed to discuss the article even though no one can read it! :-)

      --
      [Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
    2. Re:Contacting Server... by geophile · · Score: 2

      Heh heh heh.

      And then there are dumb programmers. I was working on a server product, which could be accessed by a browser. IE something.something used to put up a generic "... or contact Microsoft support" message when the server being contacted wasn't responsive. We were debugging a server, so of course it wasn't responsive. This dummy was seriously arguing with me that the right course of action was to call Microsoft support.

      (He wan't a novice. He was experienced, in the sense that he has been pressing buttons attached to a computer for many years. But a dummy.)

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

      Experienced programmers know the ENEMY'S network is down.

      --
      -- //no comment
    4. Re:Contacting Server... by N!k0N · · Score: 2

      which is also slashdotted apparently...

    5. Re:Contacting Server... by pep939 · · Score: 2

      Just for your reading pleasure, Google's cached version: http://webcache.googleusercontent.com/search?q=cache:http://synesthesiam.com/?p=218

    6. 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.

    7. Re:Contacting Server... by Chris+Mattern · · Score: 4, Funny

      You mean the enemy's gateway is down...

    8. Re:Contacting Server... by synesthesiam · · Score: 3, Informative

      I mirrored just this post on my University's servers: http://www.cs.indiana.edu/~mihansen/modeling-programmers.html
      My network admins were obviously not prepared for Slashdot.

    9. 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.

    3. Re:Comments by Anrego · · Score: 4, Insightful

      Those inline comments are good (when done properly) when trying to quickly grok through a large codebase. That "done properly" bit is important. Obviously a comment that just states what the following line does is pointless.. but a one liner generalizing a 9 or 10 line block of code means 9 or 10 lines of code you can skim over.

      Obviously if troubleshooting code or auditing you want to focus on the code, but then the comments still serve as a good tool to indicate potential problems by as you said, showing what the authors intention was. If the code doesn't match the comment.. the code might very wlel be wrong.

    4. Re:Comments by dgatwood · · Score: 4, Insightful

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

      Depends on the level of granularity. Comments that describe what a single line of code does (or even a small number of lines of code in many cases) are useless.

      Comments that describe the behavior of a suitably large block of code (e.g. a function or a block within a particularly complicated function) can help you quickly understand the structure of a program as a whole. This is critical when working with sufficiently large bodies of code, because you're unlikely to have time to read every line of code before you start hacking away at it. For sufficiently complex projects, they can also be pulled out by tools such as HeaderDoc or Doxygen and converted into documentation.

      At a semi-coarse granularity, comments that tell you what a block of code within a function does can make it much easier to find the code you need to change when something doesn't work. Thus, even those comments can be useful, so long as each comment covers at least a handful of lines of code and so long as the "what" isn't instantly obvious at a glance.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    5. 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++;

    6. Re:Comments by JesseMcDonald · · Score: 2

      It depends on how well structured the code is. If the functions are small and simple, then the function-level comments should be sufficient in most cases. It's OK to rely on a function doing what the comments claim it should do while reading higher-level code. I don't expect people to review the code for strcpy() every time it's used.

      On the other hand, if you're reviewing code with large, monolithic functions, it may need some comments inside the function (roughly where the function boundaries should be) to help readers keep track of what's going on. I would still look at such comments with a measure of distrust, however, since you don't have the benefit of each part being reviewed and tested in isolation.

      Descriptive function and variable names are also a form of commenting, and one which is much more effective when combined with tightly-scoped variables and small, single-purpose functions.

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
    7. Re:Comments by jellomizer · · Score: 2

      Comments Lie, Code Doesn't

      Every once in a while I see some well commented code, and it leads to to a massive blunder because the comments are wrong.

      Some of the ones have got me. /**
      Save Starts Here
      **/

      Which I figured would be a good part to add save my changes.
      After testing and realized it didn't work correctly I changed the comment to. /**
      Real time check to insure data is correct
      **/

      In an other function 500 lines down. I added /**
      Saves data after authenticated as formatted correctly
      **/

      Another good one was in essence saying this was part of such and such section. Where it wasn't.

      Comments don't help as much as people think they do. Unless you know the coder, comments cannot be trusted and you will normally need to go by what the code says far more than what the comments say.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    8. Re:Comments by bws111 · · Score: 2

      I think there are cases where a comment on a single line is very worthwhile. In particular, when it is not obvious why such a line would be there (eg This is here because sometimes device xxx produces incorrect input - don't mess with it).

    9. Re:Comments by purplie · · Score: 2

      Comments aren't supposed to (redundantly) tell you what the code does. They're to tell you why the code had to be written, or the reason one coding choice was made over another, or known issues and todos.

    10. Re:Comments by cdrudge · · Score: 4, Funny

      I see we had the same college TAs and professors.

    11. Re:Comments by Anonymous Coward · · Score: 3, Funny

      No, this is what I get to read // Add 2 seconds to the timer because 1 second is way too short for this situation
      timer.add(90);

    12. Re:Comments by Bomazi · · Score: 2

      This is comment on a single line of code taken from qemu/hw/ds1338.c:

      /* Attempting to write the OSF flag to logic 1 leaves the value unchanged. */
      data = (data & ~CTRL_OSF) | (data & s->nvram[s->ptr] & CTRL_OSF);

      Would you say that it is useless ?

    13. Re:Comments by Anrego · · Score: 3, Interesting

      I actually find in some cases this reduces readability.

      If it's a very encapsolated chunk of code or a chunk that can be reused elsewhere and has a very clear "x goes in, y comes out" feel then fine. At a certain point though you end up with a bunch of functions that are only called from one spot, are too specific for reuse, and the only thing you gain is a requirement for the programmer to do a lot of scrolling. You also add overhead, but I'm not one to mind a little overhead for maintainability.

      Much as it goes against a lot of traditional teaching and widely held rules, I tend to think that sometimes a large function actually ends up being more readable because the programmer can just read through step by step what is happening without the need to jump around.

    14. Re:Comments by Hognoxious · · Score: 2

      You think comments are useless because you write shit comments.

      Actually, that's harsh. Why single the comments out?

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    15. Re:Comments by Hognoxious · · Score: 3, Informative

      People who preach self-documenting code can't write good comments. They frequently don't write great code either.

      Code tells me what it does. It tells me jack-fuck-shit about why it does it that way.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    16. Re:Comments by semi-extrinsic · · Score: 2

      A snippet from the Linux kernel which goes the other way:

      /*
      * The EFI specification says that boot service code won't be called
      * after ExitBootServices(). This is, in fact, a lie.
      */

      --
      for i in `facebook friends "=bday" 2>/dev/null | cut -d " " -f 3-`; do facebook wallpost $i "Happy birthday!"; done
  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.
  5. Novice programmers overwhelmed by loufoque · · Score: 3, Insightful

    Novice programmers are simply overwhelmed by vast amounts of code, and have no idea how to do large-scale software development.
    When you teach them about tools that allow you to find your way through the code, they're all impressed.

    Universities simply aren't teaching these boys right.

    1. Re:Novice programmers overwhelmed by Anrego · · Score: 2

      I'll agree this is something I've seen.

      Even simple stuff like version control and bug tracking.. a lot of guys coming out of school who have never even heard the terms, much less learnt how to employ them effectively.

      But then it comes down to the whole "university isn't a trade school" thing, even though most people taking computer science are aiming to be coders.

    2. Re:Novice programmers overwhelmed by Ignacio · · Score: 4, Insightful

      Unfortunately if you give them the most advanced tools possible then they never actually *leave* the novice state since they're too used to their tools doing all the work for them.

    3. Re:Novice programmers overwhelmed by Quirkz · · Score: 2

      Worse, if you're like me and only had maybe a semester of programming at school while pursuing another degree, and then got into it as a hobby, you're VERY unlikely to even know you should go looking for things like official version control and bug tracking tools or systems. You learn enough to do what you want, but you don't know what you don't know, and some of those things can be critical.

  6. Matter of perspective by sl4shd0rk · · Score: 4, Interesting

    A Novice sees it done wrong
    A Master sees it done differently

    --
    Join the Slashcott! Feb 10 thru Feb 17!
    1. Re:Matter of perspective by Aaden42 · · Score: 2

      A veteran sees it done OMGWTF were you thinking you fskck343ing moron!???!???

  7. Alternate blog post by Necroman · · Score: 4, Informative

    The guy who was tested in the video has a blog post up (and his server actually works): http://blog.theincredibleholk.org/blog/2012/12/18/how-do-we-read-code/

    Direct youtube links to the videos:
    Video 1
    Video 2 (Novice)

    --
    Its not what it is, its something else.
    1. Re:Alternate blog post by Ibiwan · · Score: 2

      How weird. You'd think they'd use the same code for each category, in order to make a valid comparison...
      ...or if they did that, they'd post youtube videos properly reflecting that!

      --
      -- //no comment
  8. I'll hazard a guess: by obarthelemy · · Score: 3, Insightful

    Young programmers see code as a way to show how good they are

    Old programmers see code as something that puts money in the bank.

    What off topic ?

    --
    The Cloud - because you don't care if your apps and data are up in the air.
  9. Skipping by assertation · · Score: 4, Informative

    I don't know if this correct or PC, but when I first started I read code like a book. Every single word, left to right, down to the next line.

    Now I skip.

    I look where arguments go in, where they come out, where functions are called.

    If I go into a code block, I look where the result is first and back track as needed

    I look at the connections and only go deeper when I need to.

    If I have to read legacy procedural code, I do what I do when I read the web. I ignore sub levels of information until I finish a level. On a web page I read the content, ignore the side bars and I don't click on links until I am done with that page. In procedural code I read top down and ignore nested blocks until I see what is going on the first level.

    1. Re:Skipping by andy16666 · · Score: 3, Insightful

      I wouldn't trust anyone to know what they look at when they read code. Not because I think they're lying, but because other research shows that people often have no idea how they perform complex tasks. So I'd be very skeptical if even your most candid account of how you code or how you read code showed much correlation to how what you actually do when you perform these tasks.

      This is one of the things that makes teaching so difficult. If it were just a matter of explaining what you do, it would be simple, but for many tasks you don't actually know. You have to learn all over again when it comes time to teach it.

  10. The Inlined code is more difficult to read. by idealistw · · Score: 4, Funny

    Just a FYI, the test is really poorly done because the code that the novice and the expert are looking at are different. I can read the Expert's code and figure out what the output should read in no time. The inlined code, on the other hand, I have to do the full iteration for each loop. It's really a test fail.

    1. Re:The Inlined code is more difficult to read. by et764 · · Score: 2

      These are just two participant's answers. Each program in the test has several variants, and each participant gets one variant at random. The goal is to get enough people to gather meaningful statistics. This will include having both novices and experts doing each of the variants in the videos posted here.

  11. Gimme a break... by Elminster+Aumar · · Score: 3, Interesting

    Any tutorials or articles, etc. that start out referring to someone as "newbie", "newb", etc. should be automatically labeled as worthless. Every team of programmers--it doesn't matter if it's a team of 2, 10, 50...--always has someone that can be called a "weak link" simply because you're always going to have someone who just isn't as fast or efficient as everyone else. And if programming is more of an art form (which I personally believe it is due to having millions of ways to skin cats), then it's apt to claim that nobody can be as good as everybody. Everything depends on what exactly is being done, what technologies are being used, frameworks, functions, who's involved, what business logic is required, what data is being worked with, etc., etc., etc. I've seen people who sucked at back-end stuff rock it out with front-end and others, vice-versa. I've seen people excel with certain technologies turn around and completely blow with others but one reason some of these supposed GODS suddenly sucked has nothing to do with their understanding or capabilities but instead almost always had to do with how their resources were being used... There is no such thing as a newbie. It's an epiphany brought about by someone's nerby boner culture. Constantly using the phrase "newbie" and all that other juvenile bullshit is old news and something someone does when they're bored and looking to put people down just to make themselves feel better about their world. Stop referring to people like this because some of the most seasoned people could be painted with that brush depending on how you view things...

  12. such a shame by Dark$ide · · Score: 3, Funny

    An article that could have been astounding is on a site that got Slashdotted. Perhaps they need some experienced web programmers.

    --

    Sigs. We don't need no steenking sigs.

  13. Re:Back in the day .... by sexconker · · Score: 2

    The algorithms required to make a mainframe work vs. a distributed system are vastly different. Your failure to recognize this is probably why your thoughts are outdated.

    Mainframes are distributed systems in a big iron box. There's a reason you can hot swap CPUs and RAM in a mainframe. It's because everything is redundant, distributed, and aware of other components.

    The cloud is mainframe that sacrifices speed for physical separation (to prevent failures due to loss of power, or disasters). The algorithms are only "vastly different" if you're too dumb to see past IPv4 and understand what the damned thing is actually doing and why.

  14. Re:same as non-programming languages? by dvice_null · · Score: 2

    > I would say that this is similar to a chessmaster who has solved countless chess puzzles.

    Chess masters recognize patterns in chess like they recognize faces. Show them a realistic pattern for a few seconds and they can remember it. Show them a random pattern and they won't remember it.

    You can test this with programmers. Create a pattern, e.g. a common for loop:
    for( int i = 0; i 10; i++ )
    {
        print i;
    }

    Show this to a person for a couple of seconds and ask them to rewrite it out from their memory. If they can do it, they are more likely experienced. If they can't, they are more likely not experienced. To make the test more fool proof, you should also create a random pattern from those characters and test if the person can remember that. As some people actually have a very good memory even if they are not programmers.