Developer Experience, API design and craft skills

We define Developer Experience as applying the tools and techniques of User Experience professionals to the design of artefacts for developers. What does that mean for you? What changes if you start thinking about and testing the usability of the APIs you design and build? In this talk I’ll explain how thinking about Developer Experience as a craft skill (something honed through iteration, heuristics and the transmission of tacit knowledge) should affect your day job.

This was the keynote at PHP Northwest 2012 in Manchester.

Transcript

1. DEVELOPER EXPERIENCE,
   API DESIGN
   AND
   CRAFT SKILLS
   

   View Slide

2. www.oshineye.com/+
   

   View Slide

3. www.oshineye.com/+
   

   View Slide

4. ACQUISITION
   TRANSMISSION
   GROWTH
   SKILL
   

   View Slide

5. API DESIGNERS IN THE ROOM?
   

   View Slide

6. View Slide

7. View Slide

8. 1 UX techniques for developer-facing products
   2 Focus on the OOB experience
   3 Use convention over configuration
   4 Design away common problems
   

   View Slide

9. UX TECHNIQUES FOR
   DEVELOPERS
   

   View Slide

10. FOCUS ON THE OUT-OF-BOX
    EXPERIENCE
    

    View Slide

11. View Slide

12. CONVENTION
    OVER
    CONFIGURATION
    

    View Slide

13. DESIGN AWAY
    COMMON PROBLEMS
    

    View Slide

14. View Slide

15. View Slide

16. View Slide

17. AFFORDANCES
    

    View Slide

18. ZUHANDEN
    READY-TO-HAND
    

    View Slide

19. VORHANDEN
    PRESENT-AT-HAND
    

    View Slide

20. API DESIGN
    &
    API USE
    

    View Slide

21. ASPIRATIONAL
    

    View Slide

22. EXAMPLES
    PATTERNS
    HEURISTICS
    

    View Slide

23. DEVELOPEREXPERIENCE.ORG
    @DEVEXPFTW
    +DEVELOPER EXPERIENCE
    #devexp
    

    View Slide

24. RICHARD SENNETT AND
    THE SKILL OF REPAIR
    http://www.flickr.com/photos/arselectronica/4953202301
    

    View Slide

25. REPAIR
    “making and repairing form a single whole”
    “it is by fixing things that we often get to understand how
    they work”
    

    View Slide

26. STATIC REPAIR
    “the simplest way to make a repair is to take something
    apart, find and fix what’s wrong, then restore the object to
    its former state”
    

    View Slide

27. DYNAMIC REPAIR
    “a dynamic repair will change the object’s current form or
    function once it is reassembled”
    “the dynamic repair may involve a jump of domains, as
    when a mathematical formula corrects a defect in observed
    data. Or the dynamic repair may invite new tools for
    working with objects”
    

    View Slide

28. CONTINUUM OF MAKING
    AND REPAIRING
    1 New code
    2 Refactoring
    3 Legacy code
    

    View Slide

29. SKILL AND COMMUNITY
    “in craftwork, people can and do improve”
    “the isolated expert sends a signal that the organization is
    in trouble”
    “too many modern experts imagine themselves in the
    Stradivari trap−indeed, we could call the Stradivari
    Syndrome the conviction that one’s expertise is
    ineffable...as a result their skills degrade over time in
    comparison with doctors who turn outward professionally”
    

    View Slide

30. REFACTORING != REPAIR
    Refactoring: behaviour-preserving transformation
    Transformation in other dimensions
    Repair focusses on change in various dimensions
    

    View Slide

31. EXAMPLE: FEEDPARSER
    

    View Slide

32. BROKEN?
    Last release: 2007
    XXX open bugs and patches
    Supported ancient versions of Python
    Standard Feedparser for Python (and other) communities
    

    View Slide

33. BROKEN?
    No new committers in years
    Centralised development
    Comprehensive acceptance suite
    

    View Slide

34. START SMALL, CONCRETE
    AND PUBLIC
    

    View Slide

35. START SMALL, CONCRETE
    AND PUBLIC
    

    View Slide

36. EMBRACE POSITIVE
    DEVIATION AND DYNAMIC
    REPAIR
    

    View Slide

37. REPAIR IS A SKILLED PROCESS
    OF RENEWAL NOT AN EVENT
    

    View Slide

38. AFFORDANCE
    AND
    SKILL
    

    View Slide

39. EMPATHY
    AND API DESIGN
    

    View Slide

40. View Slide

41. View Slide

42. View Slide

43. View Slide

44. INFORMATION IS WORTHLESS
    IF IT DOESN’T CHANGE YOU
    

    View Slide

45. CHANGE A LITTLE
    

    View Slide

46. THANK YOU!
    

    View Slide