How GitHub Writes Blog Posts
You may have heard that we use GitHub to build GitHub. But our company isn’t built on just code: there’s strategy and HR policies and internal communications and a multitude of other documents that need to get written, too. All of which we can use GitHub to write as well. Now, we’re a bit of an oddball company. You’ll have a tough time finding another organization with so many lawyers who know Git
Move Fast and Break Nothing
I gave the closing keynote at the Future of Web Apps in London this October, 2014. This is that talk. The slides and the full video of the talk are directly below. If you're interested in a text accompaniment, read on for the high-level overview. moving fast and breaking things Let's start with the classic Facebook quote, Move fast and break things. Facebook's used that for years: it's a philosoph
A Day of Communication at GitHub
I’ve done a lot of posts and talks about how we work together at GitHub. The high-level discussion about how we manage to operate without managers in a 60% remote, 240-employee company is pretty interesting to me. Just like code, though, sometimes the high-level is too high-level. Just show me the code, dammit. Sure, you work asynchronously, but what does that actually mean? So, here’s a look at m
How GitHub Works
In 2011, I wrote a three-part series called How GitHub Works. I wanted to detail how we planned ideas, built them, and shipped them. GitHub no longer works like this, electing instead to institute a hierarchical, manager-driven, top-down, geocentric organization. I’m going to keep these posts up, though, because I think they address extremely important aspects of how good technical companies shoul
Unsucking Your Team's Development Environment
Success can bring many glamorous changes to your company: hiring more employees, getting free coffee, and giving everyone a private jet filled with cash and endangered African predatory cats. Success can lead to less-glamorous problems, though. As you grow, your team’s development environment becomes really important. How long does it take to clone, set up, and boot your apps? Can your employees s
The Most Important Code Isn't Code
Documentation is the single most important change I’ve made to my coding style in the last year. Documentation is Personal I’m not talking about injecting a few comments in front of confusing lines here and there. I’m talking about taking a firm, consistent view at how you document your methods, your classes, and your projects, and then sticking to that mentality. Documentation is mostly described
Don't Give Your Users Shit Work
The problem with shit work is that no one likes doing it, but an awful lot of people say they do. Shit work Take a look at Twitter Lists. The idea behind Twitter Lists was that users would carefully cultivate lists on Twitter of different accounts they’re following (or not following). These could be divided into lists like Family, Friends, Coworkers, People I Find Mildly Attractive, People To Murd
Slide Design for Developers
So I gave this talk called How GitHub Uses GitHub to Build GitHub. Someone submitted my slides to Hacker News, where it stayed at #1 for most of the day. This was pretty strange to me at first. My slides are not designed for people who didn’t see the talk in person. They’re designed to support my words, not some online audience. What’s more, many commented that they found the design of the slides
How GitHub Uses GitHub to Build GitHub
Build features fast. Ship them. That’s what we try to do at GitHub. Our process is the anti-process: what’s the minimum overhead we can put up with to keep our code quality high, all while building features as quickly as possible? It’s not just features, either: faster development means happier developers. Slides Video References Merlin Mann’s “Mud Rooms, Red Letters, and Real Priorities” sinatra_
How GitHub Works: Hours are Bullshit
You're reading part one of How GitHub Works, a three-post journey into how we work at GitHub. They're all separate posts on different topics, but if you're interested you can also read the other two: Be Asynchronous and Creativity is Important. Frederick Winslow Taylor wrote the seminal analysis of management and efficiency in 1911 with The Principles of Scientific Management. He took the first sc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
