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.
I see Blonde, Brunette,...
At this moment, novice programmers think the network is down. Experienced programmers know the site from TFA has been slashdotted.
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
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.
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.
A Novice sees it done wrong
A Master sees it done differently
Join the Slashcott! Feb 10 thru Feb 17!
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.
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.
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.
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.
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...
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.
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.
> 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.