How To Rapidly Improve At Any Programming Language

HN Comments 2021: https://news.ycombinator.com/item?id=28577371

Last year, I submitted a PR to the Clojure web request routing library, Compojure. Even though I was doing Clojure full time at work, there was still a lot for me to learn and always will be.

Opening a PR for an open source library I was familiar with and used all the time made me realize a few things:

  1. I didn’t know it as intimately as I thought I did.
  2. Code review from more knowledgable people in the community is extremely valuable. I deeply remember the lessons learned in my few open source PRs. Subtle nuances that I’d never would’ve picked up nearly as fast learning on my or in a work context.

Point 2 doesn’t mean that we didn’t do code reviews at work. We do. But the context of the review is different.

In internal libraries or services, we have deadlines and need to ship (corners will be cut in the name of shipping). In the open source world, you can generally take your time to get things right.

Your exposure to different techniques and ideas will be limited by your coworkers and peers over time. It’s different when the gate keeper is a well-known member of the community and maintainer of one of the most popular open source libraries in your language’s community.

Essentially, if you write code and contribute to open source projects, you’ll learn a lot from knowledgable people in your programming language’s community.

Everybody has heard this advice before.

Do open source to get better.

Of course, the downsides to doing open source are:

  1. You tend to not get paid or compensated for your work.
  2. You would have to find time outside of work to tack on more time at the computer and away from enjoying time with friends and family.
  3. There’s a lot of overhead in open source work. A popular project can have hundreds of issues and dozens of opened PRs that have not been reviewed yet. Not only that, you have to find an issue that you can work on and is an issue the maintainer would be willing to accept..

In other words, straight up contributing code to open source projects to get better at a new language just doesn’t scale.

But the lessons I learned from James Reeves in PR review are invaluable. I learned that using the collection functions on strings in Clojure is much less performant than using the java string methods or equivalent Clojure functions. I learned about precomputing and caching values by using a closure. All these concerns, idioms, ways to think about problems, and subtle nuances of a language can be picked up from having your code reviewed.

Then it hit me.

I learned so much from reading the comments and concerns on my PRs. But it doesn’t have to be my PR. It can be anybody’s.

That’s how you scale this up.

I don’t have to write new code for new features in an open source project and have the maintainer review it and tell me the same things he told somebody else 10 PRs ago. I could just read other people’s PRs and learn from the comments the maintainer and others leave.

Here’s how I’d approach it:

  1. Every morning, take your favorite open source library or one from a language you’re learning, go to the closed PRs on Github and start reading them from the beginning. Just a few a morning for warmup while you drink your morning coffee and catch up on email.
  2. When you want to level up, start reading the diff, and review the code and changes yourself before reading the comments.
  3. Finally, when you start feeling more confident, start leaving those comments on new PRs so that the maintainer doesn’t have to. You’re starting to contribute to open source!

Join the 80/20 DevOps Newsletter

If you're an engineering leader or developer, you should subscribe to my 80/20 DevOps Newsletter. Give me 1 minute of your day, and I'll teach you essential DevOps skills. I cover topics like Kubernetes, AWS, Infrastructure as Code, and more.

Not sure yet? Check out the archive.

Unsubscribe at any time.