Slashdot Mirror


Modeling How Programmers Read Code

An anonymous reader writes "Following up on an experiment from December, Michael Hansen has recorded video of programmers of varying skill levels as the read and evaluate short programs written in Python. An eye tracker checks 300 times per second to show what they look at as they mentally digest the script. You can see some interesting differences between experts and beginners: 'First, Eric's eye movements are precise and directed from the beginning. He quickly finds the first print statement and jumps back to comprehend the between function. The novice, on the other hand, spends time skimming the whole program first before tackling the first print. This is in line with expectations, of course, but it's cool to see it come out in the data. Another thing that stands out is the pronounced effect of learning in both videos. As Eric pointed out, it appears that he "compiled" the between function in his head, since his second encounter with it doesn't require a lengthy stop back at the definition. The novice received an inline version of the same program, where the functions were not present. Nevertheless, we can see a sharp transition in reading style around 1:30 when the pattern has been recognized.'"

19 of 115 comments (clear)

  1. Re:Slashdot is dead by grub · · Score: 2

    All we need is confirmation from Netcraft.

    --
    Trolling is a art,
  2. Different code == invalid results by phizi0n · · Score: 5, Informative

    This article is complete garbage. They tested 2 people with different code that produces the same results and then make up a narrative of how novice and expert coders think in different ways. Use the same code to test a much larger pool of programers and then the results might actually be interesting.

    1. Re:Different code == invalid results by Nerdfest · · Score: 3, Funny

      You may have Python confused with Perl.

    2. Re:Different code == invalid results by tricorn · · Score: 2

      It might help if you actually read the articles linked to. It's an ongoing study, and results are "very preliminary".

      It looks like they have various code samples. The same functionality is coded in different styles. They're studying both how novice vs. experts read code, as well as how coding styles/language features affect comprehension.

    3. Re: Different code == invalid results by Anonymous Coward · · Score: 3, Informative

      Your stick man needs to see a chiropractor STAT!

    4. Re:Different code == invalid results by maxwell+demon · · Score: 2

      Distinguishing perl code from a stream of random data is one of the undecidable problems of computation.

      Interestingly the Perl interpreter seems to solve it quite well. Maybe I should try if it can also solve the halting problem? ;-)

      --
      The Tao of math: The numbers you can count are not the real numbers.
    5. Re:Different code == invalid results by synesthesiam · · Score: 2

      We tested a total of 29 people in the eye-tracker. Here are some more videos: https://www.youtube.com/user/synesthesiam/videos?sort=dd&view=0&tag_id=&shelf_index=0

  3. Video Speed? by Psychotria · · Score: 4, Interesting

    Is that video real time (adjusted for the 300Hz sample rate)? I ask because I'm not a Python programmer (I do know C, C++, asm) but about 10 seconds into the video I knew what the program would print and yet the video went on for 3 minutes. Something does not add up.

    1. Re:Video Speed? by Psychotria · · Score: 3, Insightful

      Although I don't necessarily agree with your Python joke (pretty funny, though) your comment does provoke me to wonder if Eric really is an "expert" programmer. His eyes go all over the place even when they don't have to. There's only 2 conditions to remember and one "function" (set intersection). His eyes skip all over the place. Further, after the two sets are formed (he's written them in the box and he's already determined what common() does) why is he even looking at the function common() again? Maybe it's to double check, but surely remembering two conditions and a set intersection (3 operations) is well within the grasp of human short-term memory and surely you'd only look at the function name (what it does was verified earlier). Personally after I'd glanced at between() and common() to confirm they did what they suggest they do, I'd never look at them again. But his "expert" eyes keep going back to them while he is forming his output.

  4. Bad link by Anonymous Coward · · Score: 5, Informative

    They should link to the follow up post that talks about the experiment with 162 programmers http://synesthesiam.com/posts/what-makes-code-hard-to-understand.html. It also links to the paper that has even more information.

  5. Invalid results? by flimflammer · · Score: 3, Insightful

    The code between these two individuals is completely different, even if it produces the same results. How do you discern any meaningful results out of two people reading two different sets of code?

  6. don't give PHB's any ideas we don't need metrics by Joe_Dragon · · Score: 2

    Some call centers / help desks suck with BS metrics and scripts.

    We need less BS metrics as people just game them and people who do a good job have poor metric scores and some with lines and lines of bloated code gets a good score.

  7. Dupe? by dohzer · · Score: 3, Interesting
  8. Re:don't give PHB's any ideas we don't need metric by PolygamousRanchKid+ · · Score: 4, Insightful

    Unfortunately, this thing seems to be en vogue in the computer fashion industry. I just attended a conference where this phrase could some up a bunch of the presentations:

    "We are modeling, tapping into the power of social networks, and doing visual analytics!"

    I happen to be reading The Psychology of Computer Programming, Silver Anniversary Edition" right now. An interesting quote:

    The only thing that's changed here in twenty-five years is the fact that the funds dedicated by executive to eliminating programmers from their payrolls have become far more staggering than I imagined back then. And, now, I finally recognize in this executive desire a pattern so strong, so emotional, that it has blinded these executives to two facts:

    1. None of these schemes has succeeded in eliminating programmers . (We have now at least ten times as many as we did then.)

    2. Every one of these schemes has been concocted by programmers themselves, the very people the executives want so passionately to eliminate.

    So, although people say that programmers lack interpersonal skills, they evidently have a skill at persuasion that surpasses that of the late, great P:T: Barum, famous for his theory: "There's a sucker born every minute."

    I guess if I need some money for something from executive, I'll tell them that I need it to model, tap into the power of social networks and do visual analytics. That ought to get me my funds.

    --
    Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
  9. Re:Interesting. by davester666 · · Score: 2

    Obviously, you haven't progressed past the 'beginner' stage...

    --
    Sleep your way to a whiter smile...date a dentist!
  10. Re:This must be a taxpayer-funded experiment by K.+S.+Kyosuke · · Score: 3, Insightful

    when confronted with a situation falling within their specialized field, experts can process information in large chunks. Whereas laymen and novices tend to process things one small piece at a time; and on top of that, they flail around a lot.

    Actually, that's a load of nonsense:

    1) With programs that are *actually* large, you won't find "experts" that consume them in "large" chunks, unless they use very small fonts.

    2) With programs that are new to the readers, you might have to read in toto them anyway. There's no guarantee that the *actual* dependencies in the code will allow you to read it in a limited or strictly hierarchical fashion. You gotta read what you gotta read. It's not like people will only shove neat and pleasurable code on you in real life. If the code is messy, your reading of it will most likely be messy, too. Especially if you hit duplications and have "wait a minute, didn't I see this somewhere else? Lemme check" moments.

    --
    Ezekiel 23:20
  11. Re:300 Hz by ThreeKelvin · · Score: 4, Informative

    Human eyes "flicker" when they look at something. They will remain stationary for a time, then move quickly to another position. (See Saccade.)

    The time for one of the fast movements between positions is in the order of 20 ms when reading, giving us a frequency of about 25 Hz. (It's only half a sine wave, so the period is 40 ms.)

    Using the Nyquist-Shannon sampling theorem, we get that we must sample the eye movement with a frequency of at least 50 Hz, otherwise we'll get aliasing. Now, bring in the engineering rules of thumb, which say that it's no good riding on the Nyquist limit, but you'll need to oversample the signal a bit in order to get a useable result (It of course all depends on what you'll be using the signal for. In feedback control you usually oversample by a factor of 8-20, and in signal processing in the neighbourhood of 2-8) and you end up with a samping frequency of 100 - 400 Hz.

    So, in summary, 300 Hz sounds like a perfectly good sampling frequency, perhaps even a bit in the low end, depending on what you'll use the sampled signal for.

  12. Re:read code? by Livius · · Score: 2

    "With the blast shield down, I can't even see!"

    "Your eyes can deceive you - don't trust them."

  13. Re:300 Hz by Antique+Geekmeister · · Score: 2

    And _that_ is why so many A/D systems fail miserably: because people have been very, very confused by sampling theory.

    Just because it takes 100 msec to respond does not mean that the eye motion takes anywhere that time, and the motion is not "clocked" or linked to some discrete frequency. It's analog, and to measure its impulse driven movements properly you need to oversample temendously, or use some sort of triggered sensor that can record its triggers very accurately.