Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Principles of Developer Experience

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)

5e0c801ac1a5d0512bb9774ab158d06d?s=128

Ray Tsang

July 21, 2020
Tweet

Transcript

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

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

    observation of facts or events
  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
  4. What is Good Developer Experience?

  5. Bad

  6. Good

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

  8. Easy

  9. Proprietary + Confidential Developer Experience is...

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

    feels difficult It feels ...
  11. None
  12. "If your application starts up in 2 seconds locally, but

    it takes 21 seconds to start in the Cloud…"
  13. "It depends"

  14. "It depends on what is more productive"

  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
  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!
  17. Productivity is measurable (But not in loc)

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

    Developer Experience
  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"
  20. Proprietary + Confidential dx.reduce(toPrinciples).size == 4

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

  22. Principle 1 - Respect developer knowledge and goals

  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
  24. Before Principle 2 - Do the simplest thing that could

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

    work
  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
  27. Before Principle 3 - Learning should be incremental . .

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

  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
  30. Before Principle 4 - Wasted time is a waste After

  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
  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
  33. But How?

  34. Friction Logs

  35. Subjective

  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.
  37. Collecting Metrics

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

    excellent?
  40. In addition to open feedback, ask the questions you want

    answers to. Make it easy for users to provide the feedback.
  41. Other Ideas

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

    Libraries...
  43. Proprietary + Confidential Questions?