Hacker News Reader

> This stuff about "reading code" is basically bullshit and nobody does it.

Some guy says in an interview it's bullshit, so it is?

You never read other people's code? Not when the documentation's lacking? Not when the documentation's fine, for a framework say, but you need to see an example of how it's actually used in the context of a real application?

The implication that I get from the quote is that people don't read code for the sake of reading code.

And that matches my experience: When I read code, it's precisely because the documentation is lacking, or because I want to match up an error message produced by the code with the logic preceding the error message's origin.

Or, quite often, you read it because you want to change it - to extend it or to fix a bug.

I think the best way to both read code and gain experience is to set a goal of at least weekly or monthly contributions to a couple of open codebases that benefit your life.

But if you look at the article you'll see what I think is a salient point -- looking at code and figuring out how it works often looks more like an "investigation" (like, set some breakpoints and step through it, for instance). It's nothing like sitting in front of a fireplace with a novel.

Choose your own adventure books are still reading though.

I think that there's also a much more similarity with analyzing a novel than reading one for pleasure. Reading code has a much greater mental tax than pleasure reading, it requires more focus to actually put together what's going on, and that's similar to analyzing a novel for a report, where you might read the same passage 4-5 times, taking notes. Or even better yet, analyzing a poem, which are often short (and often obey 80 char line width rules!) and analyzing them can require a great amount of focus and thought to decide why a poet used this word in this way, and what meaning they intended to convey and such. That's much more similar to reading code than reading a novel, and I expect also less common.

I wouldn't call Abelson just "some guy" but you obviously didn't click through and read what the article says.

Indeed...hardly human.

The thing is, reading code is hard. Even well written code is hard to read and grok, the other kind can take days to absorb.

But it is very effective as a way of spotting certain kinds of bugs, while at the same time gaining a much deeper understanding of a codebase.

Reading code in a non trivial way is a very special skill that not many developers have, but that is very worthwhile to attain.

Whenever I come to a new codebase, I start by grabbing a pretty random bug and reading the code in that area. just flicking through, forcing myself to ask questions about it and finding out the answers.

actively engaging with code like that is an amazingly effective way of absorbing a codebase.

Personally I find it easier to read code than to read an English explanation of the code. Obviously comments do help with reading code but in general it's the code that really explains things for me rather than the human description.

I suspect this might be a side effect of my dyslexia, but it's something which often works to my advantage.

I mean that's all definitely true but if you consider that you're trying to pick up new motifs, different ideas, and understand how people organize the thought and concept behind their code, reading another person's code is invaluable. I think the tricky part comes with looking for quality code. One should go in with an open eye looking to satisfy what you're trying to solve, and read enough to learn how to do that oneself. I don't think casual reading of code will ever be as entertaining as a novel, but if you want to get better by solving specific problems it is a great way to go.

Most novelists are bad. Most devs are bad. No one seems to know how to tell they are a bad one, but I think we have a good filter: do you voraciously read other people's work?

Code in books is dumb. The real code to read is other code you use or interact with. eg reading the jquery source or the Rails source or code reviewing a colleague.

Almost always one does this while answering a question about this source. Trying to understand what a library call is doing or tracing a bug.

You learn a lot this way including coding tricks and style points.

The single most important change I've made in how I learn new tools/frameworks/whatnot is Github code searches -- I spend far more time there than on StackOverflow. Maybe this is more important in Scala land, where there are far fewer books and talks and blog posts to work from, and the tool stack is evolving a lot more, but I've found answering many questions of structure / "How do people incorporate this concept into a larger application" to live largely in code.

The answer is never exact, though. Something will have 10 different solutions, and being able to look at them and discuss the tradeoffs that went into the decision is a definite skill.

I read others code in code reviews, and as necessity to get the job done. I very occasionally read others code say in GitHub, but not for any desire to get better, but out of curiosity. But when I do that I get bored quickly!

You've never thought "gee this is really cool software, I wonder how they implemented xyz..."?

I'm managing a side project with four devs and I read lots of code. Since It's all performance-oriented algorithmic code, reading is the only way to know what's going on. And none of the code is crudded up. It's actually pretty nice.

Looking at the code of a project you're working on or managing isn't really the same as just sitting down and reading code for the sake of it.

You'll end up reading code if you work on code. Find something to work on. (I don't know what you should work on.)

Just like you can't really learn math just by reading the book, you'll "learn good code" much more effectively if you're working on it and you have to make decisions and judgments to move forward.

> You'll end up reading code if you work on code.

This.

Also, you'll have a more goal-directed path through the code, which is usually more motivating than understanding code for the sake of understanding.

Of course, there's always the pitfall that people will start making changes willy-nilly, until the code does roughly what they want, without really understanding anything.

But this will vanish as soon as you put higher quality standards to your own work. (e.g. if you want to ensure that it does the correct thing in all edge cases, or if you produce something larger than a quick hack)

> e.g. if you want to ensure that it does the correct thing in all edge cases, or if you produce something larger than a quick hack)

... if you submit your code to the project's owner. :)

But you'll notice this is nothing like the idea of "reading code" for the sake of it.

I don't read code just to learn in general, but I read it to find specific undocumented details or to figure out how someone solved a particular problem. Of course, you've got to read a ton of code if you're working in a large project.

It is a great way to find new ways of doing things, and to gain experience-based opinions, but I certainly wouldn't be doing it if I didn't have a very specific goal in mind.

Spot on. Most of the time I can barely stand reading my own code, so how about I take a break and read some barely intelligible code written by someone else, using a different coding style and a different mindset? Wreck my brain trying to figure out what on Earth the other person was thinking when they wrote that abomination. You know, just for the kicks.

Wrecking your brain trying to figure out what another person was thinking is a pretty fascinating way to appreciate the incredible complexity of human beings and how other minds work differently than your own.

When you do it as a day job for prolonged periods of time (where the other people put little to no effort into writing code that doesn't resemble raw encryption), the fascination wears out real fast.

I disagree. Especially when switching from one framework or language to another, it's a great shortcut for picking up on idioms.

I wonder what Fabien Sanglard would think of this.

To me, the Quake 1/2 source code has been an invaluable source of insight, as much for small algorithmic stuff (like collision/sliding code) than for its architecture as a whole (like game/engine separation, the edict_t system) ...

Have you never asked yourself "how did they do this" ?

While he might make a few usable points, this article is drenched in non-recognized bias. He takes his (as I see it, heavily bottom-up leaning -> 'in order to grok it I have to essentially rewrite it.') cognitive style and applies it as universal.

Except that what led him to this point was interviewing multiple world-renowned programmers for his book "Coders at Work" and finding essentially none of them read code regularly either.

Still making it only anecdotal - and even more obviously biased (I'd hazard a guess that the interviewees are quite far from the norm in how they learn...)

OK, sure, the data set is small. Do you know anybody who actually does it? Have you seen them doing it?

Yep. I do it, for example. A few of my colleagues do it. Others work more like described in the article.

(But I know that I myself are somewhat of an outlier, since I'm a rather extreme top-down learner.)

Maybe not too many people read code just to read code, but you absolutely have to read code when working on a project that's not your own, and that experience is very valuable.