As a developer trying to get results in the Scala world, the diversity in approaches of different libraries can be totally overwhelming, and the impedance mismatch between different libraries (and different developer preferences) often leads to confusion and inefficiency in development.

Among all of this, is what Dick feels to be the "lost art" of API design in the Scala community. Good APIs are small, focused and thoughtfully designed, isolating the developer using them from the underlying implementation whatever it is and however clever it might be. A good API should not require the user to care about the aspect they are using it for, after all, if they were really interested in that aspect, the chances are they would take control and write something themselves. Developers tend to get caught up in their enthusiasm and great ideas within their field of expertise and not consider that most people simply don't care about that and instead just want to get to their own area of interest.

In this talk Dick will examine advice from a number of sources, but primarily Josh Bloch, who has spent a great deal of time thinking about, designing and implementing APIs, APIs that we all still use to some degree even in Scala (e.g. the Java core libraries, Guava and many others). Josh writes APIs that everyone uses and most people don't notice. Dick will explore some of his advice, and some of his own and and you will learn from both about sound API design and its importance to the Scala ecosystem.

The primary mistakes Dick sees time and again are:

• Domain splurge, trying to solve every problem instead of focusing on the domain that really matters to your API
• Unintended usage, when the API is out in the wild, do people use it totally wrongly? People can be troublesome that way, but ultimately the problem is with your API
• Overemphasis on cleverness - just because you had a great idea, doesn't mean anyone else cares, or should care. If it makes things better, great, let people use it without beating them over the head with it
• Failing to consider how your solution will work in the bigger picture of the development space. Does your API play nice with others or are you creating a walled garden?
• Failing to update. An API is never "done" - it should live and evolve as you learn more (in a backwards compatible way whenever possible)