The Zen of GitHub

I’ve got a broadside hanging in my office which reads “ZEN” in bright red, hand-typeset lettering. It’s what we call the Zen of GitHub. It’s the first words displayed each time a GitHub server spins up, and it’s the philosophy that has historically underpinned most major decisions at GitHub, both technical and otherwise. @kneath published a great write up as to the how and why that GitHub Zen came to be. Speaking to the contrast between Apple and Microsoft, he wrote:

[A]n organization’s taste is defined by the process and style in which they make design decisions. What features belong in our product? Which prototype feels better? Do we need more iterations, or is this good enough? Are these questions answered by tools? By a process? By a person? Those answers are the essence of taste. In other words, an organization’s taste is the way the organization makes design decisions.

Kyle uses the term “taste”. In government, we often call it “culture”. Whatever you call it, it’s the underlying assumptions that members of an organization fall back on as they resolve ambiguity in pursuit of the organization’s mission. Should we be iterative or precise? Process driven or outcome oriented? Do we serve end users or execs? Spoken or unspoken, these assumptions will undoubtedly shape what the entirety of your organization’s outputs are optimized for, so why not write them down?

At GitHub, we did just that:

  • Responsive is better than fast
  • It’s not fully shipped until it’s fast
  • Anything added dilutes everything else
  • Practicality beats purity
  • Approachable is better than simple
  • Mind your words, they are important
  • Speak like a human
  • Half measures are as bad as nothing at all
  • Encourage flow
  • Non-blocking is better than blocking
  • Favor focus over features
  • Avoid administrative distraction
  • Design for failure
  • Keep it logically awesome

These aren’t mere words. There’s an API endpoint to retrieve random Zen upon request, and heck you, can even have Ms. Mona Lisa Octocat read the Zen herself, should you ever need it. Whether you’ve written them down or not, whether you’ve discussed them or not, whether you’ve realized them or not, every decision members of your organization make are bound by the constraints of these (often unspoken) first principles.

If you haven’t already, I’d encourage you to spend a cycle documenting those assumptions that drive (or constrain) your organization’s efforts. You’d be surprised how much less squishy culture becomes when culture has a URL.

benbalter

Prior to GitHub, Ben was a member of the inaugural class of Presidential Innovation Fellows where he served as entrepreneur in residence reimagining the role of technology in brokering the relationship between citizens and government. Ben has also served as a Fellow in the Office of the US Chief Information Officer within the Executive Office of the President where he was instrumental in drafting the President’s Digital Strategy and Open Data Policy, on the SoftWare Automation and Technology (SWAT) Team, the White House’s first and only agile development team, and as a New Media Fellow, in the Federal Communications Commission’s Office of the Managing Director. His paper, Towards a More Agile Government was published in the Public Contract Law Journal, arguing that Federal IT Procurement should be more amenable to modern, agile development methods. More about the author →

This content is open source.
Please help improve it.