Comment travaillent-ils chez Github
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. Today we’ve moved into our second office, and Campfire is still where we get things done. There’s a reason for that: chat is asynchronous.
Asynchronous communication means I can take a step out for lunch and catch up on transcripts when I get back. Asynchronous communication means I can ask my coworker a question in-chat and not worry about bothering her since she’ll get back to me when she’s available. Asynchronous communication means I can go to rural Minnesota and feel like I’m working from the office like normal.
How GitHub Works: Be Asynchronous - Zach Holman
Pull Requests
The majority of our development workflow involves Pull Requests. I’m going to be going into a lot more detail about this in future blog posts and talks but in the meantime let me say this: living in a pull request world is sublime. Gone are days at companies with complicated branching strategies, with in-person code-on-a-screen code review.
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. At that point, we can run a partial deploy of that branch on different subsets of machines and try things out in production, and if everything looks good, merge into master.
With Pull Requests, I don’t have to drag anyone into a meeting that’s inconvenient for them and for me. There’s a good reason for that, too:
How GitHub Works: Be Asynchronous - Zach Holman
