Ask HN: Does reading code actually make you a better developer?

Short answer, yes. Long answer: Learning how to read other people's code will help your literacy of the language and you may even learn a new trick along the way. It might seem like an arduous task now, but as you get into the habit of reading more code, you'll be able to recognize patterns and processes much faster thereby improving your velocity.

The very short answer is - writing code makes you a better developer. But it's incredibly rare for you to be able to invent every pattern, every useful trick, every readable style, so you read others' code. Your ability to understand what you see in others' code (and to judge it) goes up as you get better. So you write lots of code, read lots of code, write lots of code...

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.

Reading code without judging is a superpower, because it breaks your mental blocks and makes you versatile. You can work on others code comfortably, fix things, and learn the good parts quickly without getting frustrated. My biggest issue was that - I was expecting everyone to think like me :)

If you don't read other people's code, you are stuck understanding things in terms of the idioms of your own comprehension.

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.

I think you are much more likely to get stuck in a local minima if you don't get good at reading code.

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

It's far too simplistic to say, yes or no.

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.

Being able to read someone else's code is an essential skill. If enough time has elapsed it can even be a useful skill for code you wrote some time ago. It can make you a more effective developer because, for example, you will be able to read through open source code to understand what it does (since some have poor docs) as well as allow you to contribute fixes and enhancements. You can also find new techniques in code that you can add to your own 'arsenal'. Another reason is it is a great way to learn a new language: you can start reading examples and mapping patterns from languages you know into the new one. So yeah, this is an essential skill.

Yes, just like reading research papers will expand your horizon and build your cognitive map, the more code you read, the more you'll see concepts and patterns repeating. You'll start to identity what's important and how things are related in sometimes subtle ways. You'll encounter the same idea expressed in different forms, in different languages. This will help reveal the essence of an idea as you begin to identify its invariants that persist from language to language and form to form. You'll see contrasts between good code and bad code. Beautiful code and ugly code. Readable vs cryptic code. Clean lines vs nesting. Your sense of style and aesthetics will refine. But don't just read code in your preferred language or domain of expertise. Learn to read code in multiple languages, in multiple paradigms. High level and low level, up and down the stack. Read to refine your thinking. You'll develop fluency, and your code will evolve.

The answer to this question will fall sharply upon two lines depending on how you interpret the definition of "better" developer.

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.

I wouldn't say reading lots of code is necessary. Reading some code can definitely be beneficial though. If you've just moved to an existing code base, it would be helpful to familiarize yourself with the existing structure, idioms, and patterns. If you're working on something new but don't know how to approach the task, looking at code solving a similar problem or using a similar methodology can help. As with most advice, take it within reason. Don't go to the extreme.

No, at least not just "reading code". You need to understand and identify the patterns that underly there... so debugging other people's code and lear how other's strategies are solving their problems should be the actual reason behind "read code".

Does reading make you a better writer? Yes.

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.

Yes, that's how I mostly improved my codes but learning how other people coded the function I wanted to do. And then write the code itself on how I understood it. By that, I also learn new things I haven't tried before.

Like books: as one reads more one gets to know what is written better. Overtime, reading code has helped me in inculcating good practices of others in my own writing. But having said that, writing code is like playing sport. More we code - better we get atuned to (developer) environment - no amount of reading will help!

After learning a language enough to have an intermediate understanding of how it works, both conceptually and syntactically, I'd argue you learn more reading other people's code than you do writing your own.

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.

Very much YES! Being able to read the code is a required skill for working on enterprise applications. Fixing bugs and adding features will have to play nicely with the old code. If you don't understand the old code, your new code will make matters worse. You may accomplish your short term goal, but without the ability to read and understand the old code you will create a very brittle solution.

I am a C# (mostly WPF) developer at work. Most of the applications I write communicate with an API written by another developer in PHP. As much as I dread PHP I learned to read his code(which is poorly documentation) and it has helped me learn quite a bit. Reading code that isn't yours opens your mind to a different style of thinking, it's very powerful; I would recommend it.

Working on code makes you better.

You don't read it like a book, you read it to modify it and therefore you just understand it.

For me, reading code, and then trying to implement my own version while resisting the urge to look at it again is the best way. I actually learn by doing, but reading other people's code, either in a blog or at work is a good place to figure out what I want to learn.

Certainly yes! The chief reason is that you'll learn the difference between code you like and code you don't like. You'll learn what makes up that difference, so you can build it into your own code in the future. You will develop taste, so to speak. Taste is important.

The better I learn to read, the better I write. Applies to coding as well, because the real world has so much more refactoring of code than always starting fresh to make a new mess. Love admitting you can get better and faster with practice and time

Having worked and still working for years fixing other people's code... it definitely teaches you how to code and how not to code. I've seen things that made me question the competency of the programmer, but I've also seen many codes doing the same thing, but written in different ways. There are also those times where you think: "Wow, this code is so poetic!"

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.

Understanding other people's code (for better or worse) makes you a better developer.

Reading crap code should give you inspiration to rewrite it in a better more understandable way.

If you read code with the goals set in mind it can make you a better developer.

I read with a specific context/goal in mind.

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