$30 off During Our Annual Pro Sale. View Details »

Optimize for Developer Happiness

Optimize for Developer Happiness

Why how you work is as important as what you work on

Ben Balter

April 26, 2016
Tweet

More Decks by Ben Balter

Other Decks in Technology

Transcript

  1. ! Optimize for developer happiness Why how you work is

    as important as what you work on @benbalter
  2. CONWAY'S LAW "organizations which design systems... are constrained to produce

    designs which are copies of the communication structures of these organizations"
  3. ! Developer-centric development

  4. ! STARTUP the fairytale

  5. Low value High value Startup Established firm Ideas Process

  6. Low value High value Startup Established firm Geeks Suits

  7. ! What does your organization optimize for?

  8. ! Happy shareholders Successful software Efficient developers Strategic management

  9. ! Happy shareholders Good software Happy developers Happy Customers

  10. ! You can make software without MANAGEMENT

  11. ! You can make software without COMPLIANCE AND OVERSIGHT

  12. ! You can't make software without DEVELOPERS

  13. ! DEVELOPER HAPPINESS Optimize for and the rest will follow

  14. ! Developer happiness (Inside|Outside) the firewall

  15. ! Inside the firewall

  16. ! Traditional software development

  17. ! When outcomes can't be measured, institute process

  18. ! Daily, synchronous meetings to manually shuttle information around the

    organization
  19. ! Decisions made in person, 
 in hour-long blocks with

    
 all stakeholders present
  20. ! Blocking, human-based processes

  21. ! Email as the least-common denominator

  22. ! Organizational knowledge lives (and dies) with employees

  23. ! bus_factor++

  24. ! Open-source development

  25. ! Transparency solves for process

  26. ! The constraints of open source

  27. ! Electronic

  28. ! Available

  29. ! Asynchronous

  30. ! Lock-free

  31. ! Prefer systems that naturally 
 CAPTURE AND EXPOSE PROCESS

  32. ! Open source inside the firewall

  33. ! Open source is a 
 PHILOSOPHY AND A WORKFLOW

    
 not as an alternative technology
  34. ! How to 
 WORK LIKE AN OPEN SOURCE PROJECT

  35. ! 1. Share to the widest extent possible

  36. ! Openness breaks down silos, reduces duplication, and minimizes on-boarding

    time
  37. ! 2. Minimize developer friction

  38. ! Friction (n) 
 the time it takes to go

    from 
 "I want to contribute" to 
 "I have contributed"
  39. ! Common scripts to rule them all http://githubengineering.com/scripts-to-rule-them-all/

  40. ! PREFER CULTURAL CONSTRAINTS to technical and administrative constraints

  41. ! Non-blocking is better than blocking

  42. ! Never force a human to do what a robot

    can
  43. ! ChatOps, DevOps, Hubot, and CI

  44. ! If you liked it you should have PUT AN

    API ON IT
  45. ! Outside the firewall

  46. ! APIs make developers happy

  47. ! Openness makes developers happy

  48. ! Two caveats

  49. ! 1. Open up almost everything

  50. ! 2. Openness is about more than just throwing 0's

    and 1's over the firewall
  51. ! Treat your data with the same respect that developers

    treat code
  52. ! Open source, inner source, APIs, & open data all


    foster communities around shared challenges
  53. ! Be the hub, not the single point of failure

    (or innovation)
  54. ! Adopt an expanded definition of stakeholders

  55. ! Ensure all stakeholders have the opportunity to contribute 


    on equal footing
  56. ! Decentralize governance

  57. ! Minimize information imbalance

  58. ! 1. Work in the open

  59. ! 2. Propose and discuss improvements in the open

  60. ! 3. One shared, public issue tracker

  61. ! 4. Minimize synchronous meetings (and memorialize them when necessary)

  62. ! 5. Extensive, automated tests

  63. ! How do you optimize for developer happiness?

  64. ! Inside the firewall systems that capture and expose process

  65. ! Outside the firewall treat external stakeholders as internal stakeholders

  66. ! No really, how do you optimize for developer happiness?

  67. ! TECHNOLOGY is the easy part

  68. ! Bureaucracy is an organism

  69. ! Inoculate with small doses of culture and innovation

  70. ! Involve all stakeholders early on

  71. ! Start small and
 go through the motions

  72. ! Create a "feedback" repository both internally and externally

  73. ! Open data Open governance Open tooling

  74. ! DEVELOPER HAPPINESS Optimize for and the rest will follow

  75. ! Optimize for developer happiness Why how you work is

    as important as what you work on @benbalter