Keeping People. The GitHub hiring experience. Ten Lessons from GitHub's First Year. NOTE: This post was written in late December of 2008, more than two years ago. It has stayed in my drafts folder since then, waiting for the last 2% to be written. Why I never published it is beyond my reckoning, but it serves as a great reminder of how I perceived the world back then.
In the time since I wrote this we’ve grown from four people to twenty-six, settled into an office, installed a kegerator, and still never taken outside funding. In some ways, things have changed a great deal, but in the most important ways, things are still exactly the same. Realizing this puts a big smile on my face. The end of the year is a great time to sit down with a glass of your favorite beverage, dim the lights, snuggle up next to the fire and think about what you’ve learned over the past twelve months. For me, 2008 was the year that I helped design, develop, and launch GitHub. Start Early When Chris and I started working on GitHub in late 2007, Git was largely unknown as a version control system. Scaling GitHub's Employees. GitHub has been pretty public about how we work. We love to write about it, tweet about it, and give talks about it. But there's usually a lingering question of whether this type of workflow scales.
It does. It scales. We do things differently at GitHub: we work out of chat rooms, we don't enforce hours, and we have zero managers. People work on what they want to work on. I'm GitHub employee number nine, and although I wasn't there at the beginning, I've been hearing and reading the same things since even before I was hired a year and a half ago: GitHub really has a great work environment, but it's not going to scale as they grow. Once we made it to five employees, we heard the same thing about ten employees. Code gets shipped fast Central to scaling GitHub's humans is a streamlined way to deliver code.
Pull Requests are our major breakthrough. Pull Requests are the way we're able to continually improve our product quickly without sacrificing code quality. Break apart the company. How GitHub Works: Be Asynchronous. This is — by far — my favorite aspect of working at GitHub. Everything is asynchronous. Chat GitHub didn't have an office for the first two years. Chat rooms (in our case, Campfire) is where things got done. Asynchronous communication means I can take a step out for lunch and catch up on transcripts when I get back. Pull Requests The majority of our development workflow involves Pull Requests. If I want to add a new feature or impact the codebase, I'll push a new branch, create a Pull Request for it, and my coworkers will review it 1) if they're impacted by those changes, 2) interested in the subject, or 3) when they have ample time to check out my changes. With Pull Requests, I don't have to drag anyone into a meeting that's inconvenient for them and for me.
Meetings are fucking toxic 37signals originated "meetings are toxic" in Getting Real. Meetings are usually called when you need to hash something out. Beyond that, meetings are utterly forgettable. The Zone. How GitHub Works: Hours are Bullshit. Frederick Winslow Taylor wrote the seminal analysis of management and efficiency in 1911 with The Principles of Scientific Management. He took the first scientific approach towards maximizing efficiency in manufacturing jobs.
Time is money. Faster is better. More hours are better. Hours are bullshit Hours are great ways to determine productivity in many industries, but not ours. Think back to the last time you were depressed or angry. We want employees to be in the zone as often as possible. By allowing for a more flexible work schedule, you create an atmosphere where employees can be excited about their work.
A day Everyone at GitHub is different. Wake up around 10am, check Campfire logs, clear overnight support ticketsBus into work and grab lunch around noon or 1Work from 1pm to somewhere around 6-9pm at the officeGo home and work/relax from my couch until 2am, or:Go out and drink with coworkers (more on this later) Why is our day so "loose"? Enforcement. How GitHub Works. How GitHub Works: Creativity is Important.
We want to foster a creative environment. We love it when employees hack on side projects. It gets people excited. Excitement is contagious, and spreads easily from one project to another. Even if we'll never make money on that side project, the excitement generated from it can bleed into things that will make us money. Alcohol It's no secret that there's more than a few people at GitHub who like to drink. We meet people. We meet each other. We brainstorm. Encourage different GitHub's primarily a Ruby shop: most of the developers use Ruby full-time and most of our projects use Ruby. We're setting up an Arduino shop in the office for those of us who have never done meatspace programming projects.
The point is to get people interested in a lot of different areas of life. Creativity means self-direction One of the initial questions Chris asked that led to this blog post was I'm sure anyone can't just write whatever they want. We're hiring.