Surprisingly, third party libraries have ended up being fairly predictable as well. Not perfectly, but enough that I am usually not too concerned about it. Tend to RTFM at least once, though.
Try reading the manual for Boto3 and writing code blind without being sure of the response format without just calling it first and looking at the response.
This may surprise you, but I don't use Python or boto3. Last time I used either of those was nearly half a decade ago. Software I use nowadays generally has much better documentation, not to mention is written in a language where I can get code completions and accurate typings.
Also, I never said that I don't read the source code of third party libraries. In fact, I do. I like to embed third party libraries directly so that I can inspect them inside of my workspace. For almost any library that I use, though, it hardly requires much familiarity to get basic operations working. Since a good amount of the libraries I use at my day job are proprietary, I can't just google for Stack Overflow questions and sometimes documentation isn't always available, so it would be pretty debilitating if I needed a debugger just for the simple task of utilizing a library.
This is also part of why I stopped using Python. MyPy shows promise, but without typings at least on par with TypeScript, my productivity in Python was surprisingly poor despite amazing frameworks like Django and DRF. Simply put, there was almost always too much futzing around, and even with many debugging techniques I sometimes never fully figured out what was wrong with my code.
I used Boto3 as a large complex library that you aren’t going to inspect every line of code. But you mentioned web development, so you inspect every single line of every third party dependency? Every library?
So I just showed you a massive API could you use your intuition,comments, etc to figure out the response? Are you claiming that any API that you can’t understand through “intuition” is by definition not well defined?
Have you ever integrated with something like Workday?
Hell yeah I'm claiming APIs I have trouble understanding with intuition are not well designed. You might even call them... unintuitive. The entire point of an API is for it to be consumed; A nice uniform API like Stripe or Qt is easy even with minimal docs. If a user has trouble with your application, you don’t immediately blame them, you have a UX problem. If your API is hard to use? That’s a problem. This only becomes more true as the stakes get higher. How do you feel about unintuitive cryptography APIs?
Have I ever used an API that is hard to use and confusing? Yes. JIRA, Workfusion come to mind. The latter was a SOAP API. Thankfully, I don’t really need to deal with SOAP anymore, and good riddance. In case of bad APIs, my approach has always been to strongly isolate them from my code with an abstraction; most dramatically by actually putting a service up that just interfaces with the API I don’t like and provides a minimal interface to the functionality I need. At work, I usually have to do that, for security reasons, even if the API is good.
Anyways, I really, genuinely don’t have any clue what you’re trying to prove here. You’ve gone on and on about how bad APIs exist and imply this means I must be lying. So what do I have to do, link to some docs and say “Hey, check out how usable this API is”? I won't bother but the two aforementioned (Qt, Stripe) are great examples in two completely different categories.
And I have literally not even the smallest clue how this ties back to debuggers. I can’t recall a single time my reaction to a confusing API was pulling out a debugging tool other than printf; more likely I’d play around in a sandbox or REPL instead.
For the most part, C++, Go, TypeScript. At work I mostly write (micro) services or web UIs, and at home I do whatever (Tetris clones, small studying apps, utilities for reverse engineering, I’ve even done a couple Gameboy emulators in Go.)
https://boto3.amazonaws.com/v1/documentation/api/latest/inde...