Lessons I Learned From Reading Other People's Code

Nobody really tells you to read other people’s code. Every learning resource is about writing code. Tutorials, courses, bootcamps, they all focus on output. Build this. Code that. Ship something.

But some of the biggest improvements in how I write code came from reading code that other people wrote. Open source projects, coworkers' pull requests, even random repos I found on GitHub while trying to solve a problem.

It’s uncomfortable at first. Someone else’s code always looks weird. But that’s kind of the point.

You realize there’s no single “right way”

When you only read your own code, you start thinking your way is the way. Then you open a well-maintained open source project and the structure is completely different from what you’d do. Different naming conventions, different file organization, different patterns.

And it works perfectly fine.

That was humbling for me. I used to be opinionated about stuff like folder structure and naming. Now I care more about consistency than convention. If the codebase is consistent with itself, it’s fine. There’s no universal “correct” way to organize a React app or name your functions.

Good code reads like a story

The best codebases I’ve read have one thing in common: you can follow the logic without needing comments everywhere. The function names tell you what they do. The variables make sense. The flow from one function to the next feels natural.

I remember reading through a small open source CLI tool and being impressed by how obvious everything was. No comments, no docs, but I understood the entire thing in 20 minutes. That stuck with me. Now when I write code I ask myself: would someone else understand this without me explaining it?

If the answer is no, I rename things until it’s clearer. Not add comments. Rename.

Most real-world code isn’t pretty

This was actually reassuring. When you’re learning, you see perfectly clean examples in tutorials and think that’s how production code looks. It’s not.

Real codebases have workarounds. They have TODO comments from two years ago. They have functions that are too long because someone was in a hurry and never came back to refactor. They have inconsistencies between old and new code because patterns changed over time.

And that’s okay. It made me less hard on myself about my own messy code. Shipping something imperfect is normal. Everyone does it.

You pick up patterns without even trying

After reading enough code, you start noticing patterns that repeat across different projects. How people handle errors. How they structure their middleware. How they organize their types. How they name their test files.

I didn’t learn most of these patterns from a blog post or course. I just saw them enough times in real code that they became natural. It’s like learning vocabulary by reading books instead of memorizing flashcards. You absorb it over time.

You learn what NOT to do

Some code teaches you through bad examples. I’ve read code where a single function was 400 lines long. Code where variable names were single letters. Code where the same logic was copy-pasted in 6 different files with tiny variations.

That’s just as valuable. You see the pain it causes and you avoid doing it yourself. I’m more careful about function length now because I’ve felt the frustration of trying to understand a function that does 15 things.

How I actually do it

I don’t set aside a specific time to “read code” or anything structured like that. It happens naturally:

When I use a library and something behaves unexpectedly, I go read the source instead of just Googling.
When I review pull requests, I don’t just check if it works. I read it slowly and try to understand the decisions.
When I find a project I like on GitHub, I clone it and read through the main files just to see how they set things up.
When I’m stuck on how to implement something, I search GitHub for how other people solved the same problem.

It doesn’t take extra time really. It’s just being curious instead of skipping over things.