Yes. If you don't understand one layer below the code you wrote (a rung below on the ladder of abstraction) then you cannot understand if you are even using the correct abstraction (if the library is doing the thing it says it does when you call x). You literally have no idea what your code does, or even should do.

A linked list is a perfect example. If you use a linked list, you should know the basic properties of a linked list. When given one from an unfamiliar library, you should go read its code. You should run some basic performance tests on it. You should separate it from your code via some basic delegating api, so that you can replace it with another implementation in the future.

And concurrency is another example - do you need, and does, your chosen library give you parallel execution, or merely asynchronous execution.

This isn't as onerous as it sounds -- you do it all the time. But blindly trusting any software without a proof of its correctness (encryption is an example of where you might not understand ecen the interface layet of the software, but use it directly anyway) is a dangerous habit.

If there's magic there that you don't understand and you choose the library, when that magic fails to satisfy some goal you need to understand why so that you can fix it, implement your own workaround, or swap it out with a library that does what you want.

If you use a concurrency library, and don't understand threadpools, block in a thread and threadlock your application, you are in trouble.

If you use IEnumerable, and don't filter out the results before you toList, you are in trouble.

If you use monads and think flatmap is stack safe, always, you are in trouble.

Note you don't need to know ALL the tricks. Just the ones employed by the functions you call.

I don't think you are making the point you think you are making, or you being unclear. Take the concurrency example. The is a big difference in understanding the high-level concept of parallelism vs serial execution, which you suggest any library user understand, vs. understanding the C++ techniques and raw code that interacts with low-level threads to provide the library functionality. A good library does not require its users to understand its implementation in order to use its API -- that would be ridiculous most of the time. The burden falls on library authors to provide a good API abstraction that does not require users to understand the implementation; though some bad APIs may in fact require this of the users due to poor design.

Yes, I think that I'm being unclear.

As a user, I need to understand the top level abstraction of the library I am using - the api. I need to read that api's code and understand what it does, (not any deeper) in order to use it.

If it is a low-level api that directly implements a thread-pool, I need to understand that. If it is a high-level template that implements the async continuation monad[1], I need to understand the api surface that I call, and just the body of that surface and type signature.

1: https://www.fpcomplete.com/blog/2012/06/asynchronous-api-in-...