Reading Code is Key to Writing Good Code

After being on the inside, I am convinced this is (part of) the reason why Microsoft seems so disconnected from the rest of the industry: no one here reads anyone else's code.

Sure, you might look at other code in your (probably enormous) project. And if you can swing it, you might be able to look at another group's code. But in general you can't go look at, say, random third party open-sourced code similar to what you're working on, or even better, random code that has nothing to do with what you're working on. (The license, viral or not, usually has no effect on the prohibition.)

There are aspects of serendipity, and of feeling recharged by feeling connected to the greater constellation of developers and projects in the world, and those aspects are stripped away here. I wonder if the Microsoft "culture" attracts people who don't care about reading others' code, or if it creates those kinds of people.

I don't know if my code qualifies as good code, but well anyway I want to share that I never read code in my programmer life without the need to read code.

I read code when I've to modify it, or when I'm really curious about how something is working, or when I searched for bugs back in my "security researcher" past life. But it was either needed or fun. To read code as an exercise can be pretty boring I guess, this is not what programming should look like.

I can't see how there is so much value in reading a big codebase that expresses more or less the same style and patterns in many places. Maybe it's better to check for some interesting code in different projects. I bet that reading SICP or an algorithms book and to code a lot is a much better way to spend your time.

A good approach IMHO is to try to write some non trivial code, for instance an interpreter for a simple programming language, and if you have problems try to check what other code looks like and how it address the same problems you are facing. Then it will no longer be a pain to read parts of the implementation of Ruby or Python or Tcl, since you are discovering very interesting things, solutions to problems you encountered.

Another thing that's worth a lot more your time is to learn new programming languages. But there is no point in learning Python if you know Ruby, or the contrary. You should try to learn languages that are really different. For instance SmallTalk, FORTH, Lisp, C, Assembler, Haskell, Joy, Ruby, Tcl are different enough.

The only evidence that the author gives for the proposition that reading code is key to writing good code, is indirectly, by analogy to the arts. But music, painting and poetry are completely different subjects. There may be similarities between (say) poetry and code, but it is absurd to say that, since reading poetry is important for poets, reading code must be important to coders.

And there are plenty of reasons to believe otherwise. For one, extensively reading code is rare among coders. All good poets are very well-read in poetry, but there are many good programmers who rarely read code other than what they intend to modify, or as documentation.

Also, unlike a poem, a unit of code (say, a function) has a very well-defined goal. Coders don't need to develop an elaborate aesthetic sensitivity to judge whether their work passes their goals - unit tests and benchmarks will do just fine.

Nor do coders need to read code in order to learn about clever coding techniques. Partly, this is because code, unlike poetry, contains very few clever things per line. Partly, because there are simply better ways to get such information: books, blogs, articles, HN, proggit, stackoverflow, and so on.

It may well be that reading code is very helpful in becoming a better programmer. But I'd like to see some evidence first.

What open source code would you consider worth reading?

Lua is said to have a nice code base, djbdns is probably the most bug free code ever written and TeX is also legendary.

I think there is a fundamental difference between the creative acts of programming and producing artwork. The programmer has a requirement of what the program or piece of it should do, and the creative problem, is how to do express this in code. The problem with reading code, is that the original problem is not present in the code, and the purpose of the code is not to express something to a human viewer, but mainly for a machine to execute. In that way the creativity is a lot more like the mathematicians creativity than the artists. The difference to mathematics, is that in programming the resulting code is usually quite long. What one would need is to condense the code in a way similar to how a mathematician does with his formulas, so that only the most essential ideas remain. Some people are very good at that (Peter Norvig comes to mind), but most codebases for actual software are not at all like that.

Nice post, nothing really new there, but this caught my eye from the comments:

Despite this, some in the Lean camp are still trying to pretend that we can use an industrial metaphor to produce software. Why? Because just like in the 1960's that's what the Management classes want to hear :)

I wonder if that's really true...