Jerod Santo

You should be ready, willing, and able to read the source code of your dependencies

On our Lessons from 10k hours of programming episode with Matt Rickard, we were discussing Matt’s reflection on source code vs Stack Overflow, where he says:

Browsing the source is almost always faster than finding an answer on StackOverflow.

I asked him to elaborate on that and provide some context, since I agree in some contexts and disagree in others. To that, he said:

Yeah… I mean, this is one that I’ve found super-helpful, just because the code can never lie, and the documentation can be out of date, the blog post you’re reading could be out of date, the Stack Overflow answer could be out of date… But if you’re looking at the right commit, then the code necessarily can’t be out of date.

The code can never lie. So true. This brought to mind something I’ve believed for awhile, but never really put into words. (I said pretty much this on the show, but why not write it down?)

If you have a library dependency that your application relies upon, and you’re afraid to (or for whatever reason will not) peek under the covers and grok its source code… you should not be using that piece of software.

You should be ready, willing, and able to read the source code of your dependencies.

Sometimes the authors of those dependencies are better at writing software than you are. I’ve learned tons of things this way. Other times you’ll be like, “What the heck is going on?

And like Matt says in his reflections:

If it looks ugly, it is most likely a terrible mistake.

Here’s some virtuous things that happen as a result of reading your dependent library code:

  1. You will level up as a developer
  2. You will better maintain your application code
  3. You will better own and operate your application
  4. You will get better at vetting dependencies

Matt’s advice really pays dividends. Not only are you getting at what is true, but you’re also getting familiar with your entire stack, versus just the parts that you wrote and you’re used to maintaining.

The “black box” rarely lives up to its reputation. There are some things which can be a black box for a while, but at the end of the day that’s just somebody else’s abstraction. It’s gonna leak eventually.

So, be willing to dive in there and look at that code. You will be better off for it.

I will humbly submit that the entire episode is worth your time and consideration. This was just one of the many development topics we discussed in-depth. Take a listen! 👇


Sign in or Join to comment or subscribe

2021-10-24T10:43:07Z ago

So, how’s webpack? 🤓

Jerod Santo

Jerod Santo

Omaha, Nebraska

Jerod co-hosts The Changelog, crashes JS Party, and takes out the trash (his old code) once in awhile.

2021-10-26T13:35:18Z ago

Hah, good one!

There is a useful distinction to be drawn between runtime dependencies and build-time dependencies. That being said, I’d 💯 dive into webpack if the opportunity/need arises.

2021-10-26T13:48:28Z ago

How’s the Linux TCP stack, then? Or maybe your lang’s stdlib? Or PostgreSQL’s persistency layer? 🤓

I’m totally goading you, yes. 😜 However, as much as I indulge in this approach as well, there’s a lot of value in being able to distinguish between working knowledge of a tool and contributor knowledge of a tool. I don’t think it’d reasonable to expect to be able to contribute to all the projects you use as runtime dependencies.

Adam Stacoviak

Adam Stacoviak

Houston, TX

Founder and Editor-in-Chief of Changelog. Hacker to the heart.

2021-10-26T14:25:44Z ago

I think it breaks down to use what you can understand. If you don’t understand it, then you should be ready, willing, and able to read the source code as needed.

If you are unwilling or unable to read the source code you depend on, then you are taking on risk you might not be able to mitigate when an issue occurs.

0:00 / 0:00