How GitHub Works (v2)

78b475797a14c84799063c7cd073962f?s=47 Zach Holman
December 12, 2012

How GitHub Works (v2)

This is the updated version of my "How GitHub Works" talk.

Read more: http://zachholman.com/posts/how-github-works/

78b475797a14c84799063c7cd073962f?s=128

Zach Holman

December 12, 2012
Tweet

Transcript

  1. github works how

  2. we all work in the finest industry of all time

  3. dream it that morning

  4. build it that afternoon

  5. that’s remarkable.

  6. can we do better?

  7. we’ve been on the same path for years

  8. can we improve how product is built?

  9. working asynchronously optimizing happiness for five years later github

  10. @holman

  11. github, inc.

  12. ASYNCHRONOUSLY WORKing the philosophy

  13. when github was founded they: worked on what they wanted

    worked where they wanted worked when they wanted
  14. when github was founded they: were happy

  15. why change this?

  16. developer happiness is central to our workflow

  17. no managers · NO DEADLINES NO MEETINGS · NO WORK

    HOURS this: reflects that workflow
  18. in hindsight, we work like a big open source project

  19. WORK LIKE OPEN SOURCE

  20. the open source model works

  21. distributed collaboration

  22. GEOGRAPHY

  23. open source happens everywhere smart people are everywhere

  24. build a company that can work anywhere

  25. tools are our office planning, discussing, building

  26. all information should be accessible

  27. HOURS

  28. open source happens at any time people are creative at

    all hours
  29. code is a creative endeavor let your people stay fresh

  30. night owls ain’t morning people

  31. morning people ain’t night owls

  32. you can’t enforce creativity

  33. minimal process

  34. every step you add increases complexity

  35. every step you add increases onboarding

  36. every step you add increases inefficiency

  37. minimize human processes

  38. code branching & release (WRONG) V2 BRANCH QA MANAGER STABLE

    merged FEATURE BRANCH TUESDAY CODE REVIEW
  39. code branching & release (WRONG) V2 BRANCH QA MANAGER STABLE

    merged FEATURE BRANCH X TUESDAY CODE REVIEW
  40. minimize human processes code branching & release

  41. code branching & release branch pull request master merged

  42. code branching & release merged run tests auto-deploy

  43. sometimes it’s not about automation sometimes you have to remove

    barriers
  44. ship code quicker

  45. less metawork, more actual work

  46. ASYNCHRONOUSLY WORKing with tools

  47. pull requests a request to merge your code

  48. pull requests 3,108 github/github pull requests 399 in the last

    month 63 in the last month - 1 year
  49. pull requests 3.1 1.4 pull requests PER employee per month,

    2011 pull requests PER employee per month, 2012
  50. pull requests we use pulls for any new code

  51. pull requests asynchronous ask for feedback at their leisure

  52. pull requests mentions ping users, teams

  53. pull requests avoid meetings & in-person code review

  54. chat

  55. chat chat is inherently asynchronous

  56. chat tapping me on my shoulder is inherently being a

    jerk
  57. chat scheduling a meeting is inherently probably a hate crime

  58. chat 83 chat rooms

  59. chat ping someone

  60. chat ping someone native OS X + ios notifications

  61. chat get someone’s attention without bothering them

  62. OPTIMIZing HAPPINESS for

  63. WHY BE HAPPY?

  64. if you’re asking, you’re probably a horrible person but...

  65. investing in employees makes fiscal sense (I can’t believe I

    had to say that)
  66. happy people produce better work

  67. happy people help you recruit

  68. happy people keep you happier

  69. so how?

  70. BREAK CONVENTION from

  71. work style asynchronous, distributed

  72. side project culture let people build cool things hubot ·

    CI testing · deploy infrastructure door me · music server · support tools dev environment management · more
  73. travel

  74. company summit 2x/year company-wide brainstorm travel

  75. mini-summit 1x/year team-based brainstorm travel

  76. any talk, anywhere your talk or as a travel buddy

    travel
  77. github destinations hack house for a dozen for a month

    travel
  78. github destinations hack house for a dozen for a month

    travel berlin · hawaii · Uruguay · Beijing · rome · etc.
  79. travel why?

  80. travel travel is eye-opening new perspectives, new approaches

  81. travel face time bond with your coworkers

  82. travel stay fresh

  83. FAMILY focus

  84. people have kids and stuff

  85. flexible hours & locations are great

  86. 120 hour work weeks are silly

  87. family-friendly company events

  88. existence of families reflects success

  89. f i v e YEARS LATER

  90. four years in, github’s the same

  91. four years in, github’s changed

  92. changes and constants are fascinating

  93. MORE HUMANS

  94. 2010

  95. 2010 2011

  96. 2010 2011 2012

  97. 2012

  98. 132 employees today

  99. 2.5 million users today

  100. death of the hero developer

  101. work moves across ops, design, backend, & frontend more frequently

  102. rely on other teams for sanity checks

  103. pull requests bottleneck prevention:

  104. we average 10-20 per day

  105. means fast development without sacrificing quality

  106. INTERNAL TOOLING

  107. the bigger we get, the more time we spend on

    internal tools
  108. our dev tools are prettier than most for-profit products

  109. SUPPORT

  110. Chat

  111. TEAM

  112. it becomes mathematically improbable that this time was wasted

  113. teams

  114. teams let you focus

  115. but teams shouldn’t be about lock-in

  116. permissive repositories permit people to float

  117. self-selecting teams hugely important in crisis

  118. we still suck at teams it’s important to get right

    though
  119. how you work is as important to me as what

    your work is
  120. can this work for your company? maybe, maybe not.

  121. the point is to reevaluate what is important to you.

  122. thanks.

  123. @holman