The Book That Inspired GitHub’s New “Coder Caves”

Whether you’re designing software or real-world space, the right design patterns are key to usability. So GitHubbers dug into a 1977 architecture treatise on community pattern language to get ideas, coming up with concepts like “coder caves” which will be a feature of the new office. We bought the book on Amazon and mined it for more ideas–here’s what we found.

The Book That Inspired GitHub’s New “Coder Caves”

While I was doing reporting for this big story about GitHub, a side discussion came up with Scott Chacon, one of GitHub’s founders and the tsar of their new office, known to GitHubbers as Office 3.0. As we talked about the architecture of the new space, a “blank slate” industrial building where GitHub will move next month, it became easy to draw an analogical connection to the architecture of good software.


Pattern Languages In Architecture And Software

This anecdote stuck out: One GitHubber suggested Chacon read a book called A Pattern Language: Towns, Buildings And Construction to help vet ideas for the space. Of course, the title will sound familiar to any front-end designers out there: Design “patterns” are commonly discussed in software as well as architecture.

Since everything at GitHub is done in the open, there were a lot of ideas to vet. Chacon has been managing feedback about Office 3.0 in–where else–a GitHub repo. Since most of GitHub’s staffers are remote–about 70% of its employees are not located in San Francisco–the use cases for the office vary somewhat dramatically.

“I opened up a repository and emailed everybody saying: If you want to see something built, if you try to think about your daily life. Try to think about the time that you spend in the office–which is different whether you live in San Francisco and you use this for work, or whether you don’t, and use it to visit,” says Chacon. “Identify the problem-set [you face] when you’re in the office and let me know what works well, and what doesn’t work well.”


But in the back of my mind, that book gnawed. Without much training in architecture, I was curious how town and city “pattern languages” could teach me more about interface design, something I think about constantly for Writebot, the collaborative platform I’m building with two friends (and which we use here at Fast Company internally.) I bought A Pattern Language: Towns, Buildings And Construction on Amazon for about $23 used and pored over it for useful advice for software architects. Here’s what I found.

Think About Your App’s “Circulation Realms”

Chapter 98 of this tome covers “circulation realms,” which I’ll loosely define as the ease with which people can navigate a huge campus of buildings–or in a web analogy, how easy it is for users to find their way around your site. The chapter opens with a pertinent warning on page 481:

In many modern building complexes the problem of disorientation is acute. People have no idea where they are, and they experience considerable mental stress as a result.

Anyone who has tried to adjust settings in Facebook will know this feeling well; having a non-obvious structure or organization to a space makes navigating feel like cognitive molasses. The real problem, according to the authors, is lack of adequate language to describe where you are. Imagine a first-time visitor to your building (or app, or website) the book says:


From your point of view, the building is easy to grasp if someone can explain the position of this address to you, in a way you can remember easily, and carry in your head while you are looking for it.

Imagine your mom asks you how you might change her preferences in a certain app. In a user-friendly space–let’s use Mac OS as an example–it’s easy. Navigate to the Apple menu, then select System Preferences. Now imagine explaining how to change privacy settings in Facebook. You’d have to write three paragraphs. The book continues on p.482:

To put this in its most pungent form: a person must be able to explain any given address within the building, to any other person, who does not know his way around, in one sentence.

This is not just crucial for new users, the book says, but for anyone who has to carry around a mental map of a space. The more complex and nuanced the map required, the more cognitive load the person experiences–even if he’s been in the space for years.

If he spends a great deal of time looking out for landmarks, thinking about where to go next, then his time is entirely occupied, and leaves him little time for the process of reflection, tranquil contemplation, and thought.

What Are Your App’s “Main Buildings?”

Here the book gives some advice that might sound familiar to anyone who has designed iOS apps, or other applications where extreme simplicity and parsimony are crucial to usability. The book is talking about “main buildings” in a complex of buildings–say, the Rotunda at the University of Virginia, my alma mater–the brain, the locus of activity for the community of users. But it could easily be talking about an app’s “main task.” From p.487:


For any collection of buildings, decide which building in the group houses the most essential function–which building is the soul of the group, as a human institution… [B]uild the marin part of it higher and more prominent than the rest, so that they eye goes immediately to the part which is most important.

Apps or sites which have flat, uniform navigation inevitably leave people wondering what they’re supposed to be doing there. Apps that clearly call out the main task–for example, Instagram’s front-and-center camera button–are much easier for people to gain expertise in. Once they know what the main task is, everything else can be explored in the context of ancillary features.

Public Spaces And “Pedestrian Streets” In Software Design

This section could easily be titled “why people prefer to do things in public.” It’s why countless closed, proprietary networks have lost out to the robust public-ness of Twitter. From p.489:

The simple social intercourse created when people rub shoulders in public is one of the most essential kinds of social “glue” in society.

Software spaces, like physical buildings, often have centralized “corridors” or gathering spaces where people rub shoulders. This can be a feed or group chat; another example is people commenting around a piece of comment. Too much privacy, the book argues, can make these spaces feel awkwardly intimate:


… It is therefore unpleasant, even unnerving, to move through them; people in them are in no state to generate, or benefit from, social intercourse.

The book suggests allowing people to move between private spaces via outdoor areas that re-create pedestrian streets, where all sorts of activity is permissible and visible. This should make software architects think twice about what appears on their “home” or “dashboard” screens–whatever the user considers to be the app’s resting place. This is the place to house your most open social environment; closed feeds, groups, and person-to-person communications can branch off the central agora, but what people really want is a public space.

Coder Caves: GitHub’s Homebrewed Architectural Pattern

GitHubbers also used the book for inspiration, says Chacon, coming up with ideas that ranged from “super academic discussions” to “we want to have dark, smaller spaces with sound dampening, so it’s easy to concentrate.”

Those dark, small spaces earned the nickname “coder caves.” As Chacon describes the design: “It’s this maze-like structure where there are all very smaller rooms, they’re dark and there are small walls” to break up the space. “People can go in there and escape and have a quiet small space for themselves.”


Chacon shopped the idea around with other GitHubbers. “I was going back and forth with design and sketches with different people in the company, would it look cool like this, or like this? Should it we use it for design? Should we lay them out? Should we be able to see each other?” After some consensus-building, the caves were framed out by the contractor. “They’re built now–we can actually go through and walk through them,” says Chacon.

Design patterns also helped Chacon figure out which ideas to reject. One that seemed particularly dangerous was any design that encouraged GitHubbers to spend too much time in the office.

“Beds–that was something that I specifically pushed back on,” says Chacon. “We said, ‘We’re not a company that wants you to spend 18 hours at the office. We want you to go home. We don’t want you to plan to sleep in the office. We want to make sure that you have a life outside of GitHub.”


[Image: Flickr user Jon Olav Eikenes]


About the author

I've written about innovation, design, and technology for Fast Company since 2007. I was the co-founding editor of FastCoLabs


#FCFestival returns to NYC this September! Get your tickets today!