The API Dilemma

Interesting talk but a little higher level than I expected - I think the talk would benefit by adding a few examples to illustrate your points.

Nice talk and good points. World have liked examples or explanation on the real thing (like the progress in the joindin api you mentioned). Too much of a PPT with bulletpoint slides.

Very good lesson, nice overview on API. I knew most of stuff already, but you are good speaker.

And one point I like really: "Fix problems, don't build features!"

@Michiel and Anonymous - Thanks for the feedback, I wish I could have included examples but, as you saw, I had to rush through the last of my slides and still ran over. I'd love to be able to present it in the half-day timeslot to get more of the good stuff in there.

@Janči - Thank you for the kind words, I love that tip too...I even had a background on my machine that said that to remind me. It's too easy to fall into the "feature trap" and just keep on adding.

Great speaker, but I would have liked some more code and examples.

Great talk, but to heavy for my taste. The slides needs work. Needs examples.

Code examples would have been nice.

Expected a bit higher level here. A good talk however. Felt a bit repetitive sometimes.

Nice talk, but I guess this goes for all talks, more code examples please :)

This talk was mostly confirming my thoughts on building an API (but it also applies to web applications), so that was nice. Could have used some more technical talk / code.

Very complete, and I guess that's why everyone was lacking examples: too much theory to handle. I wasn't upset about that, but I've followed another two lectures on API's the same day. I can imagine that if all the API-info you're getting is from this course, you do miss practical examples and implementations.

Lots of useful reminders, new info to think over and a good presentation, although the slides are on the stale side.

Said the trivial, nothing to increment.

Ok talk. It was clear and but a bit too much on the higher level grasps on API functionality. Some clear cut examples on best practices might be a good idea.

I think this presentation gave some really good pointers, but the talk was so cluttered that as a listener you really had to work as well to distill the information that you wanted.

I feel this is due to the approach being from a rather academic viewpoint of wishing to discuss all aspects of a good API. The true art in a 45 minute presentation for me is the presenter being able to distill the main lines.

The slides looked very nice and it was clear that time was invested in creating them. However if you tend to utter more than three to four sentences about a bullet point, I would suggest to change the style so that only the bullet points that you have discussed are shown and the bullet point you're currently discussing is shown in some special layout (bold, other color). This makes it easier for the audience to concentrate on that specific point and see how it relates to the subject you're discussing at that specific moment.

I can somewhat relate to the request for more code examples, but I personally would suggest in a bit more general fashion for more examples, not necessarily code. For instance the 'common terms' pointer: you can talk about this, or show examples of APIs which are not consequent and suggest improvements.

Next time I'm in the process of designing an API, i'll be sure to have a look at this presentation again!

Nice talk.
Some added examples might have gotten the point across a bit faster, saving you some talking time

Not having developed an API there were some things I'll definitely keep in mind.

Like others mentioned, a few more examples would have been handy. Like you said as well, you were also already "rushing" a bit not to go over your 45 minute slot.

Good talk, although at times a bit "Powerpointy" and stating the obvious.

It was too high level for my taste. I expected something more practical, not just a series of "You should think about X" points. Examples would have definitely helped as to what differentiates a bad API from a good one.

Few examples and a little too general.
Also I would've expected some issues like SOAP vs REST or other API-related debates out there to be presented.
Good to keep in mind as a checklist when starting a new API

Extremely low velocity and dynamics.

Boring talk.