These are the notes I made not so much of what Ade was saying, although some of the following was said by Ade, but also of my thoughts as he spoke. Really great talk, thank you Ade.
Apprenticeship patterns: acquisition, transmission, growth.
We are all API designers, we all write functions we ourselves use later or that others use. Typically the response is “what the hell was he smoking?”.
Every move in Google needs UX research, nothing happens without it. A new API needs nothing. What about Developer Experience (DX)? DeveloperExperience.org: good examples of things that work.
At Google they try new APIs out in Hackathons. Good in term of trying out, listening. Bad in that the internal Google Hackathon devs have gone through the same interview and training processes; this audience is too homogenous with the developers of the APIs.
In UX there are personas, but how does this apply to development? Think about: What kind of developers are being targeted by this API? What is the “out of the box” experience for your API? Is it like Christmas? Can you use it straight away? Are the batteries included?
Convention over configuration: the first time you open it up, someone has made a bunch of smart decisions for you.
Designing away common problems: for example, almost everyone using Google’s oAuth APIs had one of six problems. People would stream into forums, and Google would reply “you have one of these six problems” … “ah, problem three, thanks”. “Hey, why don’t we document this problem!”
So how do you open the Google London doors? Ade isn’t telling. (Push the button on the side and pull/push, dependent on the colour of the side of the door your are on. Niiiiiice.)
Affordances, or Zuhanden (“ready to hand”). Focus on the thing your trying to do, not the tools to do it. Vorhanden (“present at hand”), sounds by similar to yak shaving… the requirements of DOING the thing take over from the original intent of WHY you want to do it. Focus on the intent of the API user. When you design APIs, focus on the users; they aren’t “just” developers, they’re people too!
DeveloperExperience.org collects examples of good APIs and good DX. Not necessarily looking for why they’re good (immediately), but instead looking to assemble a corpus of evidence and then look for patterns. (See also James Bridle’s New Aesthetic blog, similarly not imposing ideas before the evidence is in place.)
What is a repair? The Senate approach is that a repair makes a thing better for what it is being actually used for. So repairing a screwdriver used as a hammer might involve giving the person a hammer instead. Is this similar to paving the cow paths?
Legacy in the real world is good. Legacy in the code world just has an awful reputation. Legacy is viewed as a constriction by developers. Legacy in the real world is an accumulation of knowledge and experience.
Stradivari attempted to pass down his knowledge and experience, but he did not know the extent or depth of his knowledge or experience. Because he didn’t know it, he didn’t pass it on even with all of his attempts to do so. Worse, it didn’t become clear he wasn’t passing this on until after he’d died.
Empathy is a key skill for API designers. You have to understand the context of the person who will use what you are producing. Watch what people do, accept that those observations should drive change to what you are producing.
Favour: make one small change. Take one thing. Think about the person in the future who will use this? What will they expect? Will they be able to understand this thing I am confronting them with, what does it afford and what does it facilitate or bury their intent.
The only valid response to feedback is “thank you”. Not “yes but if you only read…”. No. The only response is “thank you”, then go away and think about what that feedback means about the people using what you produce. Fix it. Don’t explain it.