Principles of Developer Experience

Often we hear people talk about “great developer experience” but what does that mean? It seems to be like “beauty” – in the eye of the beholder. Yet, great developer experience (DX) is 100% about developer productivity and can be measured in terms of value and time. There are 4 key principles that help guide us to deliver value and reduce friction to increase productivity and thus deliver experiences which developers will love. These principles address the entire surface area of what developers interact with: the actual product, the documentation, and the tools.

Presented at 2020 DevRelCon Earth (https://2020.devrel.net/) with James Ward (@_jamesward)

Transcript

1. Principles of Developer Experience
   Ray Tsang
   @saturnism
   James Ward
   @_JamesWard
   

   View Slide

2. Proprietary + Confidential
   ex·pe·ri·ence
   /ˌikˈspirēəns/
   noun
   practical contact with and observation
   of facts or events
   

   View Slide

3. Setup / configure a service via command line or UI
   Use a library or API
   Read documentation / learn
   Troubleshoot problems
   Make something work. Anything!
   Developer Experiences
   

   View Slide

4. What is Good Developer Experience?
   

   View Slide

5. Bad
   

   View Slide

6. Good
   

   View Slide

7. node-v12.14.1-linux-x64.tar.xz
   How do I
   extract
   this??
   Frustrating
   

   View Slide

8. Easy
   

   View Slide

9. Proprietary + Confidential
   Developer Experience is...
   

   View Slide

10. It feels good
    It feels nice
    It feels horrible
    It feels difficult
    It feels ...
    

    View Slide

11. View Slide

12. "If your application starts up in 2 seconds locally,
    but it takes 21 seconds to start in the Cloud…"
    

    View Slide

13. "It depends"
    

    View Slide

14. "It depends on what is
    more productive"
    

    View Slide

15. Value
    I can reach my goals, e.g. finishing the
    project
    I can get more than I expected
    DX = Value / Time
    Time
    I can reach my goals in shorter time
    I can finish a tutorial with fewer
    steps
    

    View Slide

16. Low Fewer steps in tutorial, but didn't learn anything useful
    High More steps, but accomplished more goals than otherwise possible
    High Spend little time, and everything worked!
    ZERO Spend a lot of time, and nothing worked
    It's a Ratio!
    

    View Slide

17. Productivity is measurable
    (But not in loc)
    

    View Slide

18. Brainstormed a lot of things that
    we feel is good Developer Experience
    

    View Slide

19. - Accomplishing something in a reasonable amount of time.
    - Try your experience from scratch, just like a normal user would
    - Initial success in 5 minutes
    - Fail fast with meaningful directional error messages (i.e. how do I
    resolve this error)
    - Getting started docs paired with very detailed reference docs
    - Layered approach
    - If a how-to references a feature / function then it should link to the
    detailed reference doc for that
    - A workaround is a bug
    - Not personal taste, but measurable productivity
    - Implement the right pattern the first time, and peel back abstractions
    - Highest abstractions first,
    - Local dev first & local testing
    - Incremental learning / No forward references
    - Guarantee success
    - Users don't remember details, they remember how they felt
    - Aim for a positive emotional reaction
    - Abstractions should not prevent learning
    - Users goal is to learn
    - Magic is frustrating
    - "Do this because of this"
    - Each step should be meaningful
    - I can take this & apply it somewhere else
    - Am I doing this to learn something or to satisfy the system
    - The DX needs to be consistent with the industry best practices
    - For example: semver, repeatable build, dependency
    - Docs must be versioned
    - Bring the beginner's mind
    - Assume the mind of your target audience
    - Minimality Rule
    - Don't make things hard for no reason
    - Do the simplest thing possible to achieve a goal/purpose
    - Make every step is minimal of a change as possible
    - Every part of a step should be meaningful
    - DRY - Avoid redundant
    - Information architecture should be feature oriented
    - Content types are: Quickstart, Feature Docs, API Docs
    - Quickstart
    - Feature 1
    - Sample, tutorial, link to API Docs
    - Feature 2
    - Sample, tutorial, link to API Docs
    - API Docs
    - Don't label with "How-to Guides" / "Tutorials" / "Samples" instead just
    list the feature names
    - Product overview should list the headline features
    - Typography matters
    - Documentation should build trust
    - Reflect reality
    - Don't say do "x" to achieve "y" if it's not true
    - Docs should not be used to smooth over product gaps & oddities
    - You can't fix the confusing overlap between Cloud Run and GAE
    by saying one is for "services" and one is for "apps"
    

    View Slide

20. Proprietary + Confidential
    dx.reduce(toPrinciples).size == 4
    

    View Slide

21. Before
    Principle 1 - Respect developer knowledge and goals
    After
    

    View Slide

22. Principle 1 - Respect developer knowledge and goals
    

    View Slide

23. "Was this experience consistent with the way I do things? yes or no"
    "Did you learn something useful? yes or no?"
    "Did you solve your problem, accomplish your goal? yes or no"
    Respect developer knowledge and goals
    Measurements - Principle 1
    

    View Slide

24. Before
    Principle 2 - Do the simplest thing that could possibly work
    After
    

    View Slide

25. Principle 2 - Do the simplest thing that could possibly work
    

    View Slide

26. How many of these to accomplish a goal:
    ● unrelated tasks
    ● required prerequisites
    ● steps
    ● snippets copied
    ● Google searches
    ● docs
    Do the simplest thing that could possibly work
    Measurements - Principle 2
    ● CLI commands
    ● clicks
    ● context switches
    ● mistakes
    ● wasted effort
    ● decisions
    

    View Slide

27. Before
    Principle 3 - Learning should be incremental
    . . .
    After
    

    View Slide

28. Principle 3 - Learning should be incremental
    docs.docker.com/get-started
    

    View Slide

29. "Did you find the relevant information easily and quickly?"
    "Did you find what you were searching for in the first search result?"
    "Do you know where to go next to continue learning?"
    Learning should be incremental
    Measurements - Principle 3
    

    View Slide

30. Before
    Principle 4 - Wasted time is a waste
    After
    

    View Slide

31. "Did this take longer than it should have?"
    "How much time did you feel you needed vs how much time did you actually
    spend?"
    "How much time do you feel you've wasted?"
    "Which step prevented you from accomplishing the task?"
    Wasted time is a waste
    Measurements - Principle 4
    

    View Slide

32. Principle 4 - Wasted time is a waste
    Principle 3 - Learning should be incremental
    Principle 2 - Do the simplest thing that could
    possibly work
    Principle 1 - Respect developer knowledge and goals
    

    View Slide

33. But How?
    

    View Slide

34. Friction Logs
    

    View Slide

35. Subjective
    

    View Slide

36. Respect developer knowledge
    and goals
    The use/support of industry standard
    tools (Gradle, IntelliJ) is nice.
    There was some bespoke setup.
    Do the simplest thing that could
    possibly work
    There wasn't a good starter project that
    I could find / reference.
    Learning should be incremental
    Resolving my issues took significant
    time on StackOverflow and tinkering
    with the build.
    Wasted time is a waste
    It took much more time than it should
    have to get a simple build working.
    

    View Slide

37. Collecting Metrics
    

    View Slide

38. View Slide

39. What does it mean to be OK?
    Why isn't it excellent?
    

    View Slide

40. In addition to open feedback, ask the
    questions you want answers to.
    Make it easy for users to provide the
    feedback.
    

    View Slide

41. Other Ideas
    

    View Slide

42. Apply the principles from start
    Work with UX, PM, Docs, Libraries...
    

    View Slide

43. Proprietary + Confidential
    Questions?
    

    View Slide