PyTexas 2014 Keynote - Developer Experience: Marketing Matter

1. Developer Experience: Marketing
Matters
JESSE NOLLER, SR.
MANAGER & PRINCIPAL
: : PyTexas 2014 - College
ENGINEER DEVELOPER
EXPERIENCE — RACKSPACE
Station
October 2014
version 0.1.0
BUY NOW OR YOU ARE NOT GOOD

2. version 0.1.0
Developer Experience: Marketing Matters
PyTexas 2014 - College Station
September 2014
Jesse Noller, Developer Experience — Rackspace
http://developer.rackspace.com
@jessenoller — http://jessenoller.com — jesse.noller@rackspace.com

3. “Marketing is the process of communicating
the value of a product or service to
customers, for the purpose of selling that
product or service.”

5. “The process of communicating the value of
a product or service to users, for the purpose
of selling or engaging a wider community in
the use of that product or service.”

6. … but Jesse, we’re developers…
… we’re not selling anything…

7. “engaging a community in the use &
contribution to a creation”

8. worse is better

9. so what do you do?

10. Developer Experience (DX)

11. “Developer Experience is the sum of all
interactions and events, both positive and
negative, between a developer and a library,
tool, or API.
– Pamela Fox
http://www.pamelafox.org/

12. “** for Humans”
– Kenneth Reitz (made Requests and some stuff)
http://www.kennethreitz.org/

13. Why do I care?
• I am a developer: consumer
• I am a developer that does OSS: producer
• I am a weapons dealer: seller
• I am human: short attention span
• I don’t want things that suck, because other people
don’t like things that suck and I want to get things
done.

14. Why do you care?
• You are a developer: consumer
• You are a developer that does OSS: producer
• You are a weapons dealer: seller
• You are human: short attention span
• You don’t want things that suck, because it slows
you down and confuses you and you want to get
things done.

15. Bad developer experience (DX) means that
people won’t use, contribute, buy, promote or
advocate for you.
Worse, they’ll flame you on twitter.
… Wicked annoying.

16. Bad developer experience means that as soon
as you or I smell something that might be
slightly better, we’re gone

17. Good developer experience means that people
are happy to use something, they feel
successful and empowered. They become
your advocates.

19. You hit them in the feels.

20. So what does good DX look like?

21. Do I want to use it?
Does it have the features I need?
Are other people using it?
How do I sign up?
How do I get started?
How do I use it?
How do I get help?
How do I contribute?

22. Do I want to use it?

23. What does it do?
Huh?
What?

24. What does it do?

25. Does it have the features I need?

26. Does it have the features I need?

27. Are other people (or companies) using it?

28. Are other people (or companies) using it?

29. How do I sign up?

30. Not awesome

31. Much Better

32. Best…?
Trickery! (Of the best kind)

33. How do I get started?

34. All the platforms!

35. All the languages!

36. All the languages!

37. MVA: Minimal Viable App

38. How do I use it?

39. Documentation

40. Comprehensive
• Every method, parameter, return value, defaults,
implementation notes, errors, side effects, depreciation
notes must be covered
• Especially true for the API Reference and Guide(s)
• Input & Output correctness trumps example curl usage
when documenting and API.
• You need API guides and Narrative guides.
or i will find you.

41. Empathetic
• List known bugs
• If in doubt document it!
• Includes runnable code
• Helpful error messages
• If there are bugs: document them!

43. Interactive
• Comments enabled
• Feedback form
• Easy to file a bug
• Easy to engage the product owner

45. Easy to find
• SEO optimized
• Ctrl + F efficient
• Web friendly - digital delivery is now the norm
• The dead-tree-book-but-online concept is out of date
• With digital delivery comes constant iteration

46. Do I enjoy using it?

47. Do I enjoy using it?

48. Keep the API clean
Look at requests et al: put the hard things /
uncommon cases “inside” or abstracted away.
Keep the user exposed functions clean, simple
and few.
Expose more when users ask but only when
it doesn’t violate the simplicity

49. Do I enjoy using it?
Under no circumstances should you not use
REST, or standard data interchange format.
e.g. JSON, XML, anything but NIH

50. DEBUGGING
ERROR 129: AN ERROR

51. How do I get help?

52. Forums, if they don’t suck*
* Discourse doesn’t suck (http://www.discourse.org/)

53. Async!
• Email / Mailing lists
• Prepare for the bike shed
• Forums (see prev.)
• Bug trackers
• Twitter
• also semi realtime depending on bathroom schedules

54. How do I contribute?

55. Simple to contribute to
• It must be publicly accessible
• Anyone should be empowered to “make a pull request”
• No one should have to learn custom “enterprise” tool
chains or your weirdo workflow
• The faster someone can contribute, the more engaged
& invested they will be

56. Assume Positive Intent

57. “Developer Experience (DX) involves a
developer’s behaviors, attitudes, and
emotions about using a thingie.”
Make them feel like a boss.

58. More to read:
• http://developer-evangelism.com/
• Pamela! - http://www.developer-support-handbook.org/
• Kenneth! - http://www.kennethreitz.org/talks/
• Idan! - http://gazit.me/

59. version 0.1.0
AMA: Ask me anything
PyTexas 2014 - College Station
September 2014
Jesse Noller, Developer Experience — Rackspace
http://developer.rackspace.com
@jessenoller — http://jessenoller.com — jesse.noller@rackspace.com