This is great advice, but needs a caveat. I'd say it this way: The less battle-tested a part of the stack is, the more likely it is to contain a bug. Suppose

This is great advice, but needs a caveat. I'd say it this way: The less battle-tested a part of the stack is, the more likely it is to contain a bug. Suppose I'm using a database library written in Elixir to run a PostgreSQL query and I get a weird result. Where is the problem? PostgreSQL has executed billions of queries in thousands of projects for tens of years and has many contributors. The Elixir library is much newer and has many fewer contributors and has been used much less. My brand-new query has been executed a handful of times by me and has only been looked at by me. The chances are overwhelmingly high that the bug is in my code. If I can't find it there, the next candidate is the Elixir library. Only after exhaustive search in those two should I consider that PostgreSQL may have a bug. Or to include more of the stack: my code > Elixir lib > Elixir > Erlang > PostgreSQL The author's own anecdote with finding a bug in JavaScript's `sort()` illustrates this principle: it was not in (say) the Firefox or Chrome JS interpreter, but in a much less-used one: https://github.com/code-dot-org/JS-Interpreter/pull/23 https://github.com/code-dot-org/JS-Interpreter/pull/23