Preface: There are many, many dimensions that go into being a good software engineer; writing code is only one part of it. In this post though, I’ll focus exclusively on how to write better code.

This is the closest thing I can find to a “silver bullet” to level up and write better code. I can guarantee that if you start doing this regularly, you’ll almost certainly level up and get better at writing code faster than you would by reading books or taking courses.

Okay, so what is it?

The answer: build a habit out of reading source code.

Just read more source code. If you’re using a library and can’t explain how it works, read the code and learn.

How?

With most IDEs, it’s really easy to jump in and start writing code, but much harder to jump into a library and learn from it.

So, how to do this?

• Step 1. Make it very easy to jump into library source code.
• Step 2. Read a lot of library source code.
• Step 3. Level up and repeat.

Step-by-step:

Step 1: Make it very easy to jump into library source code.

Figure out how to make your IDE/editor take one-click to jump into a library source code. For example, if you’re using VSCode, make sure it’s configured so you can use the “Go To Definition” feature.

Seriously, this might take an hour to figure out how to do (and might vary based on the language you’re using), but this is a very wise time investment. If you can’t figure out how to do it, ask someone on your team for help. If they don’t know, figure out how to do it and then write a blog post about how you got it to work.

Example: I was working on something a little while ago and wanted to see how PyCrypto implemented AES.

Watch this:

Two clicks and boom, I’m deep in the PyCrypto source code, inside the module definition I wanted to learn about.

I can’t over-state the importance of making it a one or two clicks. Sure, you could open up a terminal and fuddle around site-packages to find the relevant file that’s 30 directories nested deep in a hidden directory, but the problem with that is you’ll do it way less often.

Make it really easy and you’ll do it more often.

Step 2: Read a lot of library source code

My general rule of thumb: if something I’m using seems magical (and I can’t explain it succinctly to myself), then I’ll hop in to the source code to understand what’s going on beneath the hood.

You’ll start to form opinions, and more importantly, you’ll realize that a lot of the things that seem magical aren’t magical - it’s maybe one or two abstractions you didn’t know. Now that you know them, things that previously seemed like black magic, now make sense. So much of software engineering is having the right abstractions (and there aren’t all that many).

The same thing applies to frontend packages. I found an excellent tool called sourcemapper that lets you download a bundled asset pack and split it up into its individual files. I started picking webapps that had source maps enabled in production, and read through a lot of source code.

Step 3: Level up and repeat

Start using the patterns you’ve learned from reading source code.

Remember, something isn’t by definition good because it’s packaged into a library. There are lots of packages out there that you/your company relies on, but it’s up to you to decide if a piece of code/library is good or not.

Some questions to ask yourself to figure out if a piece of code is good or not:

1. Is it readable? If I make a reasonable effort, can I understand it?
2. Is it well-commented? Does it read well?
3. Is it performant and secure?

But then again, this is all up to you.

Only you can decide what’s good and what isn’t, and that’s pretty liberating.