Once in a while, I like to pick a random NPM package that I'm using in my projects, and go read the source code on GitHub.
When I was first learning JavaScript, I read some of the source code for jQuery and Express. It was a positive experience. I was surprised that I could understand a lot more of the code than I expected. There were definitely a lot of terms and concepts that I had to look up as I went along, but that helped me learn a lot of new things.
I expected it to be much more intimidating, it was actually very readable. That's probably in large part because I was lucky that jQuery and Express are well-written and documented projects.
I've also read some really messy codebases (and written a lot of messy code myself), and it showed me that there's a lot of variability in the software world. No two projects as alike.
But here's what reading source code doesn't show you:
You don't see what paths development took and how the code got to where it is today. (unless you go digging through git commits, which I recommend as well).
When you read the source code of a fully-formed, well-maintained and well-documented project, you might get the impression that the developers really knew what they were doing. When you look at the finished product, it might seem like the authors had everything figured out, and they just sat down and wrote it.
The reality is: they probably threw away more code than they wrote, before arriving at the current state.
In fact the code probably went through a lot more iterations that it might seem.
So when you're learning and working on your own projets, don't be afraid to throw away code.
Code is free to write, so write lots of it. Code is also free to delete, so delete at will.
As long as you keep producing, you'll keep getting better at it.
By having the mindset that it's okay to throw away your code, you're going to write more and that's how you improve.
Do you agree? Should you throw away code more code than you keep?
Top comments (3)
I feel you. I think reading code from good and well-organized projects can cause Imposter Syndrome in many people, at least it was for me at first.
But working in my own projects I've come to realize, as you say, that your code can become as good, you just need time to polish and evolve it. Maybe at first it won't be very elegant, but with time you'll arrive at better ways of how a class or a method should be.
Mfw I compare a repo I made last week to a project with 50k commits and has been going for 3 years
ProTip: If you're not under the gun of an urgent deadline. It doesn't hurt to take a few weeks to marinate on how the API should be structured.
IMO, the mark of a really well-written project is one where the API rarely -- if ever -- changes.
Historically, JS has been pretty bad about this b/c there was no way to define public vs private API endpoints prior to ES modules. Either way, the 'best' projects were those that seemed to 'just work' despite constant improvements and frequent feature releases.