New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How does one read codebases? #249

alayek opened this Issue Feb 10, 2017 · 3 comments


None yet
2 participants

alayek commented Feb 10, 2017

I think this is the hallmark of an engineer. To be able to know the relevant codebases inside out. Be it codebases at work, or open source example apps' repos.

I like to read codebases. I have learned a lot from reading code on GitHub. I like the Octotree extension that allows me to navigate easily, without having to clone it locally.

I have formed a mental map of sort - where to start, what to look for in each file, what order to follow etc. For instance, I start with package.json, to check the deps and scripts. Then I check the eslint setup, then the tests. After I have an idea of what to expect from the project, I start reading the source code.

But this is where I usually lose attention, or just lose interest in general.

What should I do after this?
How much of the codebase I should know in detail, how much of it I should keep in my head at a higher level?
What strategy do you follow?

I have noticed that it's easier to read parts of codebases, if you are trying to understand something specific from it, or modifying a small part of it.


This comment has been minimized.


kentcdodds commented Feb 10, 2017

Here's your answer in 3 minute audio form!

@kentcdodds kentcdodds closed this Feb 10, 2017


This comment has been minimized.

alayek commented Feb 11, 2017

Thanks a bunch for the detailed reply!

I asked a similar question to Jan Orvadko, lead maintainer of Firebug, about 3 years ago. Back then, I was just trying to understand the Firebug net panel (I didn't even know call(), bind(), apply() etc.).

He also provided a similar reply - because the code is version controlled, checkout a new branch and test your hypothesis. If you think a part of the code does something, put that to test by altering that part of the code. Basically his suggestion was to instead of passively reading the code, experiment with it.

One other technique I followed was to go through commit history. I took the 2048 codebase, and checked out each commit in reverse chronological order. This was not only showing me the code, but also the author's mind at work.

For instance, in case of 2048, the author first added the SCSS styles, then the HTML markup, and about 20 commits after that - the actual JS logic started to take shape. This gives me confidence when I am trying to build any app - because I know this approach worked for someone else.

But again, for codebases with more than 200 commits, it won't be manageable.

Recently, I am learning React Native with Redux using the GitHub compare feature, like this.

I liked the part about your reply that you don't read the code always - at least if you can help it. I think that's also what I have realized so far; that there has to be an end goal to read the codebase. Don't read code just for the sake of reading!

P.S.: My name is pronounced as Or-i-jit (Or as in Oregon, i as in Chilli's, jit as in Ve-get-a)


This comment has been minimized.


kentcdodds commented Feb 12, 2017

Thanks for sharing!

P.S.: My name is pronounced as Or-i-jit (Or as in Oregon, i as in Chilli's, jit as in Ve-get-a)

I'm still unsure of how to pronounce your name! Chilli's has two is in it, and I'm not sure I've heard the word "Vegeta" before! Haha

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment