

Reading Code is Key to Writing Good Code - edw519
http://stevenharman.net/blog/archive/2009/11/18/reading-code-is-key-to-writing-good-code.aspx

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

~~~
jordyhoyt
Wow, I can't imagine working like that. At my workplace, when working out
problems, I almost always go to others' code first to see how they solved
similar (or identical) problems.

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

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

~~~
bumblebird
You should at the very least be reading your own code.

It's the feedback loop to improvement.

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

If your goal is "It works", then sure. But some of us aspire to something more
than that.

~~~
mdemare
Of course you should read your own code. How can you not read your own code?

This is about whether it makes sense to pick an open source project and start
reading.

~~~
bumblebird
You'd be surprised.

People using IDEs for a start, code folding, hiding from the cruft.

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

~~~
jonskulski
I found drupal's architecture to be pretty good. Core, not contributed
modules!

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

~~~
GavinB
Many artists have a requriement for what their art should do. For instance, a
film composer has to create a soundtrack that enhances the emotional content
of a film. They may have broad discretion, but ultimately their goals are
largely defined by the existing narrative and pacing of the movie.

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

~~~
tumult
Absolutely it's true. Programmers in most corporate environments are treated
like assembly line workers. Work for X hours, Y amount of work gets done.
Programmers should be interchangeable units that can be continuously
reorganized to optimize productivity.

In reality, of course, programming is not like manufacturing at all. It's more
like creative writing, or painting, or composing. It's difficult to tell how
long something will take, what problems you might face along the way, etc.
Business people typically do not understand this; getting an MBA will usually
teach you about organization, supply, resources, large teams, and other things
that are irrelevant for software development (not to mention business
connections along the way, which is just as important.)

But software is clearly necessary if you're going to be competitive in almost
any field, which is why programmers are needed. Business people usually don't
like you; you're just a necessary evil. They'd rather not have to deal with
programmers at all. They would rather buy some software package that comes in
a carton. A person who works on something all day that they can't understand
and can't easily measure the productivity of scares them. "Why are these
programmers all so fiddly? Can't they just do their work like everyone else?"

This is one of the reasons most corporate software sucks.

(I've never worked for any extended period in a large corporate/enterprise
environment, thank god, this is just the general story I hear from people who
have.)

~~~
alttab
I work at _IBM_. You can't get more corporate than that.

I had a co-worker say this to me last week - "I just feel like [our manager]
treats people like resources, batteries if you will."

He complains a lot and his department transfer is going poorly, but I couldn't
help but agree with him here.

To say that its creative writing, painting, or composing is frankly dead on. I
don't have to convince our audience here that is true, especially anyone who
has seen a _truly elegant solution_ to a problem.

Corporate software definitely sucks as a rule, I believe, because the passion
and motivation for excellence has been sucked out of them. I was discussing
design philosophy (as related to a structure/organization question) with my
_technical team lead_ and he said something to the effect of (not far from
verbatim), _"Yeah, I'm not really passionate about [design philosophy], I
usually follow whats there."_

This is a guy that supposed to be leading a group of developers. Over a year
and a half I have determined that taking a diplomatic approach to design and
programming issues isn't always the best solution. It leads to disconnected
and mangled code.

Apple is different in this regard because the CEO was, and at heart
(hopefully), still is a programmer (despite app store mayhem - everyone makes
mistakes). The market has noticed and felt the difference. _(Also notice how
Apple doesn't do a lot - if any - corporate level development.)_

I agree with your stance completely and am willing to make the bold statement
that the only person that should lead an organization that produces software
as a direct product for consumers should be someone that has developed before
and still has the passion about the _art_.

 _(Edit: a quick side note to all of this - I have friends that are in the
Silicon Valley area and quit IBM way before I contemplated it. At first I
thought they were whiny because they didn't get to write python code but what
it comes down to is they understood and accepted the fundamental breakdown
between organizational behavior and the art of computer science.)_

~~~
gnaritas
I'm not aware of Jobs ever being a programmer, what are you talking about?

