The Zen of GitHub
TL;DR: Whether you call it taste, culture, or zen, there are underlying assumptions that members of an organization rely on to resolve ambiguity in pursuit of the organization’s mission.
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 (as seen live above), 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.
Check out these popular posts on GitHub's culture and communication patterns.
If you enjoyed this post, you might also enjoy:
- 15 rules for communicating at GitHub
- Four characteristics of modern collaboration tools
- 19 reasons why technologists don't want to work at your government agency
- Ten ways to make a product great
- Five best practices in open source: external engagement
- Twelve tips for growing communities around your open source project
- Speak like a human: 12 ways tech companies can write less-corporate blog posts
- Leaders show their work
- Why everything should have a URL
- Why open source
- The seven things a corporate Chief of Staff does
Ben Balter is the Director of Engineering Operations and Culture at GitHub, the world’s largest software development platform. Previously, as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →
This page is open source. Please help improve it.
Edit