If you asked most people to explain a random codebase written by someone else, they’d probably stare at the screen for hours (half understanding, half pretending).
And I used to be no different :)
Reading other people’s code always felt like trying to read a novel in a foreign language.
You could recognize the words, but not the intent behind them xD
But over time, I realized that being a good developer isn’t just about writing elegant code. It’s about reading and understanding it (especially when you’re working in a team or contributing to open source projects)
Story Time!
The First Time I Opened an Open-Source Repository
I still remember my first dive into open source.
I opened a GitHub repository with thousands of stars, thinking I’d quickly “fix a bug” or “add a feature.”
Ten minutes later, I was lost in layers of imports, modules, and helper functions that all seemed to call each other.
So I did what every beginner does: I closed the tab and told myself, “I’ll come back later.”
I didn’t.
A few months later, I forced myself to try again, but this time differently.
I started small . Reading just one file a day, taking notes like a detective trying to solve a mystery. This was much better than before.
Butttt, Instead of focusing on what the code did, I started asking why it was written that way.
So, I gave up on open source [True Story Guys]
Very luckily,
Around the same time, my workplace introduced mandatory peer reviews.
At first, I saw them as a formality xD
Just approving or rejecting pull requests.
But then, something clicked.
Reviewing someone else’s code forced me to slow down.
It made me think:
- What’s the intention behind this logic?
- Could it be done simpler?
- How would I explain this line to a new hire?
That’s when I realized that reading code is a form of communication.
Every function, variable name, and comment reflects how someone else thinks.
And once you learn to understand their thinking, your own thinking and reading improves drastically.
And this is it, folks. After doing code reviews for six months, when I went back to open source once again, I was much much better!
3 Tricks That Helped Me Get Better
Over time, I developed a small system to make reading others’ code less painful and more insightful:
- Start with the README and tests.
The README tells you why the project exists; the tests tell you how it behaves. They’re the perfect compass before diving into the actual implementation. - Trace one path, not the entire codebase.
Pick one function or API endpoint, and follow the flow. Imports, function calls, returns. Don’t try to understand everything in one go. And give more time to it. Like, sit with it for hours. - Explain it out loud (or in notes).
Pretend you’re teaching it to someone. Writing or speaking explanations helps you identify what you actually understand — and what you’re only skimming.
You know, once I got comfortable reading code, I noticed an unexpected side effect
my own code became cleaner.
I also became faster at debugging.
When something breaks, I can now navigate through a teammate’s codebase confidently [understanding context, patterns, and hidden assumptions]
I am a better collaborator, now.
Wanna Read More of My Python Articles?
In case we are meeting for the first time, come over here, it’ll be worth the roller coaster of articles that are gonna come up in the next few weeks. Enjoyed the read? You can support my writing journey here — Buy me a coffee?