The lesson from this case might be to be suspicious of a 'smart' capability where you don't know enough, about what it is supposed to do, to be in a position to validate it.
- you fall into an undocumented corner case
- you use a dynamically typed language (the case in the article) which essentially makes it impossible to validate the client code, although the API code may be well validated.
That rings a bell in me, a time I wrote a signal processing library but people preferred using Numpy directly :,(
What matters is what you choose to keep under your control. If you use a black-box library you lose control over the semantics of the operations you invoke. When you are doing it yourself, you know way better what the semantics are.
Recyclable code is like throw-away code, except with some extra care to avoid making it write-only.
It is liberating in more than one way: you know the semantics because you defined them or you can in practice read their definition. Not having to care about reuse means you don't have to think about extra parameters or extra functions to satisfy a larger user base than you or your coworker(s). Recyclable code aims at staying small, simple and stupid. It does not need to scale.
And of course, just like portable code is not portable until it has been ported, reusable code is not reusable until it has been reused. It is not uncommon that the parts written for the sake of reuse do not work because the author actually was not interested in them, and as a result forgot to test them.
I think it is interesting to note that recyclable code goes straight against the open-closed principle: reusable library code is designed to be extended, built-upon, while recyclable code is made to be easily edited.
I have written a lot of throw-away scripts like many programmers. Some parts of them I actually kept and they became reusable parts that I keep in separate files to be included in other throw-away scripts.
Obviously, at some point some operations you do often (like reading a CSV files or whatever), you don't want to code again and test each time, and perhaps more importantly if you discover a bug in one script you don't want to update all of the other scripts that do exactly the same thing.
So the motivations for reusable code are still prevalent, but the mindset for creating it is slightly different than what the "API-first" paradigm promotes. Recyclable code can become reusable because of ad hoc reuse. This is what keeps code size and documentation size, human-sized.