Ask HN: Does reading code actually make you a better developer? I've been writing software for quite some time, and one piece of advice I hear a lot for improving is "read lots of code, write lots of code, repeat". I get writing lots of code-- but reading lots of code? I'm not so sure. What are your thoughts? |
For a new code base, I start off with a high level design and one feature which touches the important parts. May be there is more knowledgeable with codebase around to ask and also decent documentation.
If I am in a Lisp like editing language, this [1] tracer is fantastic. Otherwise in non-live languages, I am a dead duck in the circus of breakpoints/debugger to step through the code.
You may also have a look at this [2], the author of Coders at Work, Peter Siebel talking about decoding code and from the same book a very interesting discussion on reading code which I have reproduced here.
---
Seibel: I’m still curious about this split between what people say and what they actually do. Everyone says, “People should read code” but few people seem to actually do it. I’d be surprised if I interviewed a novelist and asked them what the last novel they had read was, and they said, “Oh, I haven’t really read a novel since I was in grad school.” Writers actually read other writers but it doesn’t seem that programmers really do, even though we say we should. Abelson: Yeah. You’re right. But remember, a lot of times you crud up a program to make it finally work and do all of the things that you need it to do, so there’s a lot of extraneous stuff around there that isn’t the core idea. Seibel: So basically you’re saying that in the end, most code isn’t worth reading? Abelson: Or it’s built from an initial plan or some kind of pseudocode. A lot of the code in books, they have some very cleaned-up version that doesn’t do all the stuff it needs to make it work. Seibel: I’m thinking of the preface to SICP, where it says, “programs must be written for people to read and only incidentally for machines to execute.” But it seems the reality you just described is that in fact, most programs are written for machines to execute and only incidentally, if at all, for people to read. Abelson: Well, I think they start out for people to read, because there’s some idea there. You explain stuff. That’s a little bit of what we have in the book. There are some fairly significant programs in the book, like the compiler. And that’s partly because we think the easiest way to explain what it’s doing is to express that in code.
---
Overall, I try to read in small pieces with some clear goal. Interestingly enough, I don't know if we can read code from start to end like a book, may be literate programming makes that possible; but yes reading code is hard and that is simply because we don't have good code reading tools, yet in the 21st century!
[1] https://www.cs.cmu.edu/~dst/Lisp/dtrace/dtrace.generic
[2] http://www.gigamonkeys.com/code-reading/
EDIT: link to the code is not literature article
There is an analogy to writing in a human language. If all you do is read for 10 years, and then start writing, you'll almost certainly be a bad writer. You learned to read and extract information (and get enjoyment), but you almost certainly didn't understand how writers achieved those goals. This is even more sure for programming. Writing code over and over again helps teach you when and why to apply certain rules, because code has to work, not just look pretty.
But unlike writing human languages, there is far more to learn about computer programming - it's not just grammar and style, there's all levels of design, and architecture. So you read articles and books, but those are usually very hand-wavy. By reading the code for very large programs and then trying to copy what you see, you learn.
Also unlike writing human languages, you start by writing code. Reading code before you've written any is nearly pointless - you just won't understand what you are looking at.
It also matters what code you are looking at, just like it matters what you are reading - but again, only once you get good. So until you think you are at the median level for software engineering, don't worry too much about what you read.
The cool thing is that there's so much code available to read now, as compared to 40 years ago when programming first started becoming a real thing. And especially with Google and a few others not just employing hordes of great engineers but releasing a lot of their source as open-source. Read the Chrome source, for example. Or the Linux source.
Moreover, reading code is a skill, and much of being a good developer involves working with other people code, which means being able to efficiently parse other people's code.
Of course we read a lot of people's code, but I'm not so sure it's something that needs to be actively practiced rather than done naturally over a career (which makes recommending people to read code pointless if it happens naturally).
But if all you do at work is line of business apps in VB6 for years on end, then I would recommend reading the source code for some games, database servers, your OS kernel, your favorite text editor, or something unrelated to your job. The point is to expand the scope of the projects that you're capable of undertaking.
-It lets you work effectively as part of a larger team or project
-Gives you a much larger surface area of material to learn from: you can learn new patterns and libraries by seeing how other people use them instead of having to find documentation or tutorials
-Sometimes there are bugs in libraries (open source or otherwise) that you depend on. You will find these much quicker if you are good at reading code.
If you are inclined towards self-motivated improvement and if you have a good internal monologue where you are able to be real honest with yourself and your own failings and limitations then reading good code opens up the possibility that you can apply the things you take away from it to your own code and become better.
Good code isn't a gold ticket, it's always on you.
I see one interpretation of better as "can copy, repeat, fix, comprehend, maintain." And the other as "comprehends and exceeds - often without explicitly 'reading' that which is comprehended in the first place"
The first group will argue that you have to read. The second will argue that it's optional.
I am in the second group but would argue in favor of the first. It never hurts to stand upon the shoulders of the giants who came before you.
That being said, I never read other's code unless its to fix it.
What does it mean to be a good developer? Do you simply want to write your own black-box undocumented software? Then there is a much lesser advantage to reading other projects' code. On the other hand, if you want to manipulate another codebase, or use another library, reading code is a necessity.
That leaves one final question: Is it beneficial to your own development skill to read others' code? Yes. Proficiently reading others' code is a very beneficial skill, even if you do not intend to write code to be read by someone else. Not only will you get better at reading your own code, you will learn idioms and practices that will improve your comprehension, and writing skill.
The way I like to do this is to think through how I would implement something. Then, reference code that does something similar to the problem I was trying to solve. Then, I compare their solution to mine.
You don't read it like a book, you read it to modify it and therefore you just understand it.
So reading other code can surely help. I have seen some Github projects where I would have loved to have used the project for personal use, but I just couldn't understand the coding style, or have had to incorporate my own coding style because I could not adopt the code as it was in the program.