
Ask HN: Does reading code actually make you a better developer? - saasinator
I&#x27;ve been writing software for quite some time, and one piece of advice I hear a lot for improving is &quot;read lots of code, write lots of code, repeat&quot;.<p>I get writing lots of code-- but reading lots of code? I&#x27;m not so sure.<p>What are your thoughts?
======
danyim
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.

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

------
mvpu
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 :)

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

~~~
saasinator
I'm not so sure that's a bad thing? If you understand and work well enough,
what's wrong with understanding through your own idioms, etc?

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

~~~
db48x
Sure, if you happen to be exposed to a wide variety of code as a result of
your work, then probably you'll be fine.

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.

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

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

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

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

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

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

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

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

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

------
samblr
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!

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

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

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

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

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

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

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

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

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

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

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

------
deepaksurti
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](https://www.cs.cmu.edu/~dst/Lisp/dtrace/dtrace.generic)

[2] [http://www.gigamonkeys.com/code-
reading/](http://www.gigamonkeys.com/code-reading/)

EDIT: link to the code is not literature article

