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.

Comments

[JesseMcDonald]

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.

Motivation and experience make the difference

[davidwr]

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.

Matter of perspective

[sl4shd0rk]

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

Gimme a break...

[Elminster Aumar]

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

Re:Comments

[Anrego]

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.