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.
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.
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.
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.
It's efficient. It's concise. It's easy for you to understand and modify. It's easy for others to understand and modify. Over the long term, it proves to have a low defect rate. It's declarative, and lends itself to automatic optimization.
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.
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.
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 :)
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.)
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.)
I've worked in corporate software environments (though only two years as an employee, thank god), and I think you've expressed it well. It's noticeable that your description is largely without bitterness, presumably because you've mostly evaded the experience.
It's why I left. The alternatives were: start my own thing, or get out of the industry. Of course now I wonder why it took me so long. One reason is the time I spent wishfully thinking that the problem could be addressed by agile processes and "organizational change" (the latter being a genuine fiction as far as I can tell) before concluding that they were incapable of delivering even the minimum I needed not to go crazy.
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.