Skip to content

codebases-we-love/codebases-we-love

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

19 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Codebases We Love ❤️📜

We've all heard the advice: spend more time reading code. And yet, there's some taboo on peeking inside a popular library or framework.

In a way, it makes sense: you should rely on abstractions and ignore implementations. But there are good reasons to look under the hood:

  • A tried and tested codebase has lessons that you may not get to see in your usual application code.
  • Abstractions leak. Some more than others, but sooner or later you'll need to jump to the code.
  • Even if the abstraction isn't leaky, reading the code will give you a better mental model about how it works and it'll improve the way you use it.
  • Having some idea about how a project works may be the first step toward contributing to it.

You may still be intimidated by the idea of looking inside React or Rails, but the good news is that just doing it once will demystify the whole thing. After all, it's just code written by other humans.


The goal of Codebases We Love is to get more people to read code. And not only that, but to share the experience. The reason for this is that "read" is not actually the best word: a much better choice is explore. So this is our proposal: form an exploration party with some friends, choose a project and get to it.

More specifically, our goal is to:

  • Generate a community of code readers explorers.
  • Curate, for different languages, lists of codebases that are worth reading.
  • Build guidelines on how to organize an exploration party.
  • Give tips on reading code, both general and language-specific.

Organizing an exploration party

If this sounds like fun to you, here's what you need to do. (For more detailed information, go here)

  1. Get some friends that are also interested. We think that between 3 and 5 is a good number, but your mileage may vary.
  2. Pick a codebase that you all are interested in.
  3. Set a date for a meeting. One week in the future should be enough, especially the first time.
  4. Before the meeting, each one on their own will explore the codebase
  5. Meet on the planned date and talk about what you found. Even more important: talk about the questions you found and couldn't answer.

After this, if everyone is interested in repeating it, go back to step 3. If not, that's fine! And remember, if you used a codebase that's not in the list, open a pull request to add it.