You are currently browsing the monthly archive for June 2013.

Recently I wanted to find out how github works technically, with the intention of uploading a small personal project. After googling I found a presentation titled exactly that – How GitHub works. However it turns out that it was a presentation given by one of their employees about how the company itself works – how they communicate, how they do planning, development, product releases, etc. I found this very interesting and watched the whole things which is 55 minutes long. Here’s the presentation and a summary I’ve made:

– starts with company structure, ethos, hierarchy (no managers), flexible hours, team setup and size, etc
– @2m Working 9 to 5 doesn’t suit every company, best solutions happen in the zone
– @4m Embrace flexibility, let people work when they want and when they’re most productive
– @7m Trust the people you hire
– @8m Asynchronous workflow
– @10m Limit in person contact, use chat even in same room – lets others into the conversation;
– @12m Weekly tech talks, recorded and uploaded to internal server for future usage for new employees
– @13m Have face-time, once or twice per year get team together for day out / meal / drinks
– @14m Minimize distractions – the zone is difficult to re-enter
– @15m No technical meetings, no stand-up, daily, or planning meetings. Use chat to communicate asynchronously
– @16m 60 employees, no managers
– @19m Minimal process – plan it, build it, ship it
– @22m Use simple branching: master => branch => pull request => merge; master always ready to deploy
– @23m Deploy 5 to 30 times per day
– @23m Pull requests replace traditional code reviews;
– @25m Count number of assertions, currently 8000 taking 250 seconds
– @26m A slow test is a regression
– @28m Deploy => check exceptions => check performance => merge into master (if applicable) => celebrate!
– @32m Foster exploration, shared side projects
– @34m Continuous learning
– @35m Avoid burnout by encouraging new things

%d bloggers like this: