Seven Months at Github
I just passed my seven month anniversary at GitHub, and working here has been amazing. GitHub is a pretty special company, and I thought I would take a moment to reflect on what makes it special and some lessons I have learned over the past half year.
Great People above all else
The quality of people at GitHub enables every other unique and powerful thing about our company. We don’t have deadlines, top down management, or much in the way of rules or process because GitHubbers are self motivated, smart, and passionate. While it is nice to imagine a world where all companies could be like GitHub and optimize for happiness and get rid of management, the reality is that you need awesome people whose happiness is derived from creating a great product for that to work.
Positive Peer Pressure
We thrive on very loose process and self management because of positive peer pressure. GitHubbers want to work on hard, important problems to get their peers to also work on them. We fix nasty bugs and work the support queue because making customers happy is awesome, and it also earns the respect of our peers, even if the work is thankless sometimes.
GitHub Hiring
GitHub hires great people. We put a lot into hiring and screening of candidates. That doesn’t mean draining, three day interviews with comp sci heavy interviews. You won’t have any GitHubbers glaring at you while you try to implement Quicksort on a whiteboard. There was a bit of coding in my interview, but it was actually just pairing on the GitHub codebase, working on a real problem that my interviewee happened to be working with that day. It was really just an exercise to see how I approached solving problems and worked with other people. By the time you get to the office for an in-person interview, it is assumed you have the basic chops to work at GitHub, and the rest is culture fit and personality fit.
Culture of Shipping
GitHub has a culture of shipping like nowhere I’ve seen. Even when it comes to things that many may not think of as easily “shippable”, like architecture, process change or redesigns. For example:
- creating a pull request with a spike demonstrating a small (but critical) piece of an architectural change
- drafting a post in our internal ideas app, with references, diagrams, and examples, showing how to improve our teamwork
- sketching a redesign idea on paper and uploading a scan to a pull request
So while it can be valuable to have conversations about things like architecture, process, or design, it is more valuable to take concrete action, even as fuel to move the conversation forward. Any experienced software development has seen “bikeshedding” kill productivity - endless philosophical debates and arguments driven by ego instead of practical value. Focusing on actions and shipping cuts through the crap and keeps things progressing forward.
Anarchist Structure
Much is made of the flat, nearly non-existant management style of GitHub. Yes, it really is true that you can work on whatever you want. Yes, that means that I could drop everything and work on a Haskell rewrite of github/github, but in reality that just doesn’t happen.
It turns out when you hire self motivated, talented people who want to work with other really other good people, folks generally work on important stuff. Bugs get fixed and crummy things like grunt-work automation and difficult tests still get written. And if those things get missed on the first pass, peer pressure and continual review ensure ensure they get done.
End
It has been a fantasticly good half a year at GitHub. I have learned so much, shipped some great software, and look forward to many more years of learnings and shipping.