I think the idea here is to look at the code for the libraries you're using. The documentation might lead you to believe it behaves in a certain way, but the actual code is the true source of truth. Open it up and have a look instead of wondering.
Something I liked about working at Google is that I never had to wonder what the lifecycle of a certain request looked like. I could always open up the code for the server I was trying to talk to, and piece together what "internal error" really meant, or what "optional" fields were actually required to make the request succeed.
That's excellent point. When I digged into express source I understood several things like how it extends the response object via prototype to add methods like send etc. Also you will understand how exactly next function is implemented and then you can literally understand anything about the library.
A great viewpoint, but not what I think the objective was. Code needs to inform humans first, inform computers second. Because of the human cant understand the code, they can't change it, and being able to change code is what decones maintainable and "good".
To figure out how to write code that informs humans well, you have to read code. See what works and what doesn't for someone who is not the original author.
Being usable without changes (what you describe) is nice, but not what most people mean when calling code "clean" or "maintainable", or even "good" (that might imply a good API, but not the code itself.
Something I liked about working at Google is that I never had to wonder what the lifecycle of a certain request looked like. I could always open up the code for the server I was trying to talk to, and piece together what "internal error" really meant, or what "optional" fields were actually required to make the request succeed.