The Developer Experience

Editor's Notes

• #2: Hey everyone! It’s great to be here in New Zealand speaking to you guys - I’ve attended enough NZ conferences in the past to know the developers here are really top-notch.\nI’m also honored to be presenting first thing in the morning, but to tell the truth, I’m also a bit nervous that you all will fall asleep on me. I’ve devised a clever plan however - I’m going to teach you a dance. I’ve been practicing it in the hotel room, and I think it should be the official dance of WDCNZ. Okay, now, everyone stand up. \nAlright, this dance is to the tune of YMCA. First we do the W, D, C, N - this one’s tricky, then Z. Okay then we put it together with the melody. WDCNZ! dododood WDCNZ!\nOkay, good job everyone! I’m pretty sure you’re awake now, so you can sit down.\nFrom now on, that will also be our secret code dance, in case we meet outside the conference and want to confirm we’re in the WDCNZ cult.\nALright back to the topic at hand: Developer Experience.\nToday I’m going to talk about what it is, why it matters, and how to make it good- or in more technical terms, how to make it not suck.\n\n\n
• #3: Developer Experience is a new term that doesn’t get used much, so let’s start with discussing a term you probably hear all the time: user experience. There’s lots of fancy definitions for it, but it’s basically the experience that somebody goes through when using a product, and when we hear it, it’s usually in terms of a website user.\n
• #4: There are lots of websites out there, but for many of them, the experience can be broken into these stages - discovery, deciding whether to use it, signing up, getting started, actually using it continually, and getting help when something goes wrong.\n
• #5: For a concrete example, let’s look at the website for MailChimp. Have any of you used MailChimp? I actually hadn’t used it before last week and had no idea what it did, but I kept hearing that it had a great user experience, so I signed up just to check it out.\n(That’s a sign of a reallly good UX).\nWhen I first visit the site, I’m greeted with a huge adorable mail chimpanzee (bonus points because I love monkeys), a giant headline that tells me what it does, and an enticing button to sign up for free. So I continue on.\n
• #6: Then I go to the signup screen, expecting a long form, and all I have to do is enter my email username and password, and I get nice confirmations along the way that I’ve entered everything correctly.\n
• #7: Once I respond to an email confirming that address, I fill out a longer form. Okay, not as great, but atleast the form tells me along the way why it needs each bit of information.\n
• #8: After that, I’m brought to the user home screen and immediately see a step-by-step guide to getting started. I don’t have to search around, I know my first step: create a subscriber list.\n
• #9: Once I’m done that and want to explore other features, I get directed to watch videos explaining how the other features work.\nOh, and along the way, the monkey at the top says stuff..like right now, he’s not wearing any pants. This gets better and better.\n
• #10: When I do have a question, I can search help at the top, see forum questions, live chat, or email, whatever works for me.\n\nCertainly there are other aspects of the MailChimp experience, but that gives you a good idea for what it’d be like to be a MailChimp user -pretty good, from what I can tell.\n\nBut, I’m not an expert in user experience, and that’s not what we’re here to talk about.\n\n
• #11: We’re here to talk about developer experience. We can make up fancy definitions for DX as well, but really, it’s just user experience in the developer realm - the experience of a developer trying to use a tool, library, or API. \n\nAnd actually, we can break DX down into the same stages.\n
• #12: \n
• #13: For an example, we can look at Twilio, a dev tool known for a good experience. Anyone use it?\n\nWhen I first visit, I see a landing page a lot like MailChimp - cute relevant graphics (unfortunately no monkey), a big headline that explains what it does, and a signup for free button.\n\n
• #14: Signup is easy, and it tells me more features along the way.\n
• #15: I’m immediately greeted by a get started guide - which involves actually calling a phone number which sounds pretty fun.\n
• #16: I’m also prompted to start programming immediately, and hey look, monkey-themed tutorials!\n
• #17: Once I get past the hello monkeys, I can browse through their examples or API reference to do what I actually want to get done.\n
• #18: And if I run into any problems, I can post in the forum or contact Twilio directly.\n
• #19: so that’s one example of a positive developer experience\n\nbefore we talk in detail about what makes a good experience, i first want to make sure you actually care about making a good experience.\nto do that, i need to understand who you are,\nbefore figuring that out, i have to figure out who you are \n
• #20: When it comes to developer experience there are providers - the people who create the experience and provide the library, tool, or API - and there are consumers - the people who use that product. \nTo give you examples of people you already know, I checked out the speakers list. James Pearce works for Sencha as a developer evangelist for their platform, so he is very much on the provider side. Karl Van Randow creates iPhone apps using the Apple platform, so he is more of a consumer. Of course, many developers are in the middle - often when you’re doing it right, you also consume the tool you provide. Paul Irish uses HTML5 to create websites, but he now also works for Google Developer Relations, working with the Chrome team and teaching other people how to use it.\n\nNow what about you guys? \nLet’s start with the easy question: how many of you are consumers? Hopefully all of you.\n\nHow many of you are providers? That might mean you work for a developer facing product, but also could mean you work on an internal API for your company, or you are an open source maintainer in your free time.\n
• #21: java - API - dad told me, dont ask him, look online. probably my first developer experience.\nuniversity - started playing around with APIs. made a whopping $30 off amazon API, whee!\n\nso i cared because i was paid to do it but also because i started off as a developer, knew id be a developer in the future, and just wanted for developers what i would have wanted.\nbut maybe you need more of a reason than that..especially if youre spending money on making a developer experience.\n\n
• #22: For a consumer, obviously you want a good experience. But why does a provider care?\naka why should you care\nfacebook example (tried using it, dreaded it, phasing it out)\neveryone in survey hated it\nif google+ succeeds and has a good API, developers more willing to leave.\nfacebook has social graph API..buttt if it loses that..\n\n
• #23: developers will want to stay with it and get others to use it too - crowd-sourced advocacy effort. they’ll also use it for fun, even when they don’t have to, and come up with really cool things.\nmaps API..used it whenever i had the chance. developers did more with it than we ever imagined, and got great publicity out of the out there ones. there are competitors but..\n\n
• #24: \n
• #25: This question breaks down into a few questions.\n\nfirst question is one everyone asks- can this API help me accomplish what i want to do?\nto figure that out they need to understand the API feature set- if the docs are public (as they should be), they can read theirs, see the method they need and move on. even better, if there’s an interactive explorer, they can see for themselves the code that will do what they want- seeing IS believing! \nand then anyone who’s not just using a tool for shits and giggles will actually care if they can legally use it and afford it. they want to know the licensing, pricing. they want to feel it’s stable - dont want to build a business on top of something that will change or go away, especially if its not open source. they also want to think the team is committed to keeping it, so a general degree of polish and professionalism can help with it.\n\nsomething that can help answer both these questions are case studies -case studies show how a 3rd party developer has used something, and also prove that another developer trusts the tool enough to build on top of it. if you’re trying to attract non-hobbyist developers, case studies can be very useful. they also showcase the kind of apps you’re expecting developers to build.\n\n
• #26: This question breaks down into a few questions.\n\nfirst question is one everyone asks- can this API help me accomplish what i want to do?\nto figure that out they need to understand the API feature set- if the docs are public (as they should be), they can read theirs, see the method they need and move on. even better, if there’s an interactive explorer, they can see for themselves the code that will do what they want- seeing IS believing! \nand then anyone who’s not just using a tool for shits and giggles will actually care if they can legally use it and afford it. they want to know the licensing, pricing. they want to feel it’s stable - dont want to build a business on top of something that will change or go away, especially if its not open source. they also want to think the team is committed to keeping it, so a general degree of polish and professionalism can help with it.\n\nsomething that can help answer both these questions are case studies -case studies show how a 3rd party developer has used something, and also prove that another developer trusts the tool enough to build on top of it. if you’re trying to attract non-hobbyist developers, case studies can be very useful. they also showcase the kind of apps you’re expecting developers to build.\n\n
• #27: and then anyone who’s not just using a tool for shits and giggles will actually care if they can legally use it and afford it. they want to know the licensing, pricing. they want to feel it’s stable - dont want to build a business on top of something that will change or go away, especially if its not open source. they also want to think the team is committed to keeping it, so a general degree of polish and professionalism can help with it.\n\n
• #28: \nsomething that can help answer both these questions are case studies -case studies show how a 3rd party developer has used something, and also prove that another developer trusts the tool enough to build on top of it. if you’re trying to attract non-hobbyist developers, case studies can be very useful. they also showcase the kind of apps you’re expecting developers to build.\n\n
• #29: \n
• #30: \n
• #31: automated key signup. \n\nmaps API - multiple domains - \n\nwont name names, but one i had to fill out a form, wait 3 days, and then got emailed with the addresses all CCed. dont make developers wait.\n\n
• #32: \n
• #33: \n
• #34: For each language, environment, and IDE.\nCommon dev environments - mac linux yes even windows, with customized launcher utilities for each of them.\nPLus, some languages are associated with IDEs- like java and eclipse - so they also provide an eclipse plugin.\nDevelopers dont want to spend their time setting your thing up, they want to spend it actually using it. If it takes too long before they get their first whoa moment, then you might be discarded.\n
• #35: If it’s an HTTP library, provide client libraries for each language.\nYes, they can construct the HTTP requests themselves, but particularly if there’s anything sort of authentication involved, it’s much easier if they can use a library.\nAnd make them open-source so they can just see how the library does it and adapt it to their needs.\n\nYou don’t have to write all the client libraries yourself - you can encourage 3rd party developers to do it, and link to them. Just be careful about deprecations and upgrades.\n
• #36: Some people hate on hello worlds, but here’s the thing: humans like to see output. It makes us feel good, and motivates us to keep going. If we can follow a tutorial that will get us running with our first project that uses something- even if it’s simple- that will give us the confidence to keep going.\nNot everyone will use them, but you should always have a getting started tutorial that will step explicitly through the basics.\nBonus points if they can then base their actual code on the starter code.\nPhoneGap provides a tutorial for each environment.\n
• #37: Once you actually get something minimal running, you want to figure out how to use it to accomplish your actual goal - which is probably more complicated. \nAt this point, developers will look for documentation to learn about the interface for the tool or API.\n
• #38: first rule of documentation is to have it be thorough. if something isn’t documented, it basically doesn’t exist. even if your documentation has to say this is buggy, document it. better that you document what you know than have developers out there each spending hours to figure it out.\n\n
• #39: first rule of documentation is to have it be thorough. if something isn’t documented, it basically doesn’t exist. even if your documentation has to say this is buggy, document it. better that you document what you know than have developers out there each spending hours to figure it out.\nmethods, params, error codes, defaults, return values\n\n
• #40: dev guide, reference, videos - both narrative and technical breakdown. people learn in different ways.\n
• #41: in the reference, every class/method comes with example code below the definition, and sometimes that code can even be run in the browser. (Or for HTTP APIs, sample request and responses in every data format are offered).\n\nhicharts atleast one example jsfiddle for every option, which is both runnable and editable. and they have 100s of options. its made it a lot easier for me to use their API over the past few weeks, cuz i can test stuff out without touching my code and figure out what option i need.\n\n
• #42: Good documentation also has several features - they may seem obvious but they’re suprisingly rare to find them all.\n\nEasy to find, subnav, different versions. Everything has its own page, so it can be found, linked to, and searched for online.\ntable of contents, so people who are link to individual pages find everything.\n \nNot intimidating, even for newbies.\n\n
• #43: amazon APIs takes too many clicks. get list of different versions, have to figure out right one, then i get this metadata on the doc and choose what i want, and finally i get the page and realize it wasnt what i was looking for and start over. \n\nwhat not to do: be careful of wikis\n
• #44: Search for methods, search for methods inside a class.\nAlso needs normal SEO - many people will try to search in google.com. It’s popular like that.\nSo don’t mistake of a purely AJAX accessible doc set.\n\n
• #45: Search for methods, search for methods inside a class.\nAlso needs normal SEO - many people will try to search in google.com. It’s popular like that.\nSo don’t mistake of a purely AJAX accessible doc set.\n\n
• #46: first rule of documentation is to have it be thorough. if something isn’t documented, it basically doesn’t exist. even if your documentation has to say this is buggy, document it. better that you document what you know than have developers out there each spending hours to figure it out.\n\n
• #47: \n
• #48: \n
• #49: usually a forum. could also be email support, if you’re daring..\n
• #50: \n
• #51: \n
• #52: \n
• #53: main places to get feedback are docs and API itself\n
• #54: If it’s an open or open-source technology, you might want to make your docs editable by the community at large. You’ll want moderators to make sure people don’t spread inaccurate information, but it can be a way to scale out documentation. Sometimes there are super-users out there just waiting for a way to share their knowledge.\n\nMozilla Dev Network uses a wiki for its popular HTML/CSS/JS docs, and anyone can login and edit the docs.\n\n
• #55: Comments aren’t for everyone - jquery had comments on each of their pages, with the hope of getting user contributed examples. They eventually closed the comments as it led to fragmentation of the community and weren’t bringing enough value. Now they direct people elsewhere.\n
• #56: \n
• #57: If it’s an open or open-source technology, you might want to make your docs editable by the community at large. You’ll want moderators to make sure people don’t spread inaccurate information, but it can be a way to scale out documentation. Sometimes there are super-users out there just waiting for a way to share their knowledge.\n\nMozilla Dev Network uses a wiki for its popular HTML/CSS/JS docs, and anyone can login and edit the docs.\n\n
• #58: Or you can make the docs forkable and editable, like SammyJS does.\n
• #59: simple! easy to use..low barrier..tho maybe not tooo low.\n
• #60: \n
• #61: \n
• #62: \n
• #63: \n
• #64: \n
• #65: just smile\n\ntake notes!\n\n
• #66: So now that I’ve filled your head with ideas on what makes a good developer experience (and doesn’t), what can you do with that information?\n
• #67: you have to care/love/give a shit - be attuned to what they need, serve\nmaps api: stayed awake with adrenalin\nmaps api: woke up in morning thinking of devs\n\nmaybe thats extreme but the point is this- if you dont genuinely care, it will be hard for you to know how to make it better.\nMaps API - support, features, new API\nWave API - new API (both features + design - the common things were too hard, some things weren't possible at all), then docs, then we got killed\n\n
• #68: you guys also need to care-care enough about what youre using to want it to be better\n\neven if youve made it better for just 5 other developers, thats a good thing.\n
• #69: conference attendee: most likely sessions you attend are for tech you consume. think how you'd improve, what constructive feedback you can give. talk to the speakers after, let them know.\nif they dont appreciate the feedback, then blame me - but i bet they’re happy to hear it, especially from live developers in person.\n\n\n
• #70: https://sites.google.com/site/googdevreljobs/\nhttp://apigee.com/about/jobs\n
• #71: https://sites.google.com/site/googdevreljobs/\nhttp://apigee.com/about/jobs\n
• #72: developer experience is a unique subset of user experience that deserves attention,\nproviding a positive experience is something everyone should strive for for the bettermint of developerkind.\nEveryone’s experience is different though, so I’d love to hear about yours - chat with me in the hallways or online.\nThanks and have a great day at WDCNZ!\n