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! 👇