This is a really stellar article. I mean really fabulous. The article perfectly distills years of rumination into simple points and subpoints. If you expect to have to design an API at some point in your career (spoiler alert: you will), you absolutely need to give this article a read.
When using a poorly-designed API, I always find myself wondering why it was designed so poorly. Was the API just an afterthought which grew more popular than expected? Was it made by a first-time API designer? Is it a reflection of a poorly-designed existing system?
My pet theory is that in the back of our minds we don’t think about other developers as users. Of course, they’re not users in the traditional sense, but they are still users. We think they’ll just be able to handle whatever we throw at them, and to some extent we’re right—they will hem and haw and grumble and use the API. They’ve used kludgey APIs before, right?
What are some good examples for API that get this right? I feel like keygen.sh is on the right track, especially with the graphs and examples on the right, but I’d love some other examples.
It’s been a while since I did any Rust, but I remember the compiler giving similarly useful error messages. Bad error messages are easy to overlook until you experience how good they can be.
Between Rust, Keras, and Elm, I am hopeful that good error messages are becoming something that both users and designers expect of their languages.
Furthermore, I am of the opinion lobste.rs should have a UI/UX tag, or expand the design tag’s description.