一、时间并不决定一切

弗雷德里克·温斯洛·泰罗在1911年写了一篇有关管理和效率的惊世之作：《科学管理原理》。他是用科学方法阐述工业生产中最优效率的第一人。时间就是金钱。效率越高越好，时间越多越好。

“时间决定一切”不适用于我们

在很多行业中，时间是评判效率的准则，但不是我们的标准。在创业公司工作是完全不同的。你不可能花太多时间来解决一个问题。编程是一件需要创造力的事情，你需要在最佳状态才能编出高质量的代码。

想想上次你消沉或愤怒时候，你的效率如何？再想想上一次你真正高效的时候吧，代码好像从你的指尖飞出来的，你编码不仅速度快，代码的质量也高。在状态好的时候编码远远超过机械式的敲键盘。

我们希望雇员们更多的处于最佳状态，但规定上班时间会影响他们进入这种状态。如果强迫我早上九点钟上班，我将不会达到最佳状态。但GitHub一半的同事在早上工作都是最高效的。

如果创造一个更随意的工作时间，程序员会更积极工作，最终会促进程序员工作更久，更加高效。他们甚至会周末工作，晚上工作，因为他们感觉在做的事并不是别人要他们做的工作。

在GitHub的一天

每个在GitHub工作的人的时间安排都是不一样的。我没有平均计算过每一天的时间，但大致是这样的：

早上10点起床，查看Campfire日志，处理过夜支持请求
坐巴士上班，在十二点或一点钟左右吃饭
从下午一点开始工作，直到下午六点或晚九点下班
回家工作或休息到凌晨两点钟。

我们有同事早上七点来到办公室(简直是疯子)，也有人下午三点来。有一些同事在家里工作更有效率，如果你不喜欢来办公室，你不需要每天都来(尽管大部分同事每天都来)。

为什么我们的每一天都如此“松散”？这是因为：

我们可以随时随地用聊天室来交流，
我们想创造一个让所有人都高效的环境。

没有一个工作时间是适合每个人的，所以我们没有强制工作时间。

强制工作时间

我们现在有35个雇员，队伍在不断壮大。上班时间灵活随意，对我们的团队来说运作的非常好。但是经理们喜欢规定时间是有原因的：这样做可以给他们一个错觉，工作时间的长短可以转化为评判表现的标准。

经理们如果不看雇员们的工作时间，就得看他们其他方面的表现。他们代码的质量如何？他们修复了错误吗？他们在专心工作吗？更大的灵活性是否让他们更消极？

确实很难将以上这些评判标准进行量化。但是程序员的价值远比一天工作十小时要高。如果你认为时间决定一切的话，那么程序员在乎的将只是时间，而不是代码的质量。

二、异步工作

这是到目前为止我在GitHub工作最喜欢的方面：每件事都是异步的。

聊天

GiHtub在最初的两年没有办公室。我们用聊天室(Campfire)来沟通。现在我们已经搬到了第二个办公室，但仍然使用Campfire。这是因为聊天可以是不同步的。

用这种异步的交流方式，我可以出去吃饭，然后当我回来的时候我仍能跟得上对话；我可以问同事一个问题，不用担心会打扰到她，因为当她有时间的时候她自然会回复；我可以去Minnesota的乡村，也可以同平常一样好像在办公室工作。

Pull Requests

（编注：“Pull Requests”是GitHub上的一种讨论形式，有关代码讨论、代码审查、管理代码的变化。Pull Requests = 代码 + 问题 + 代码注释。）

我们的开发工作流程中涉及Pull Requests，我想在以后的博客中更加详细的讲述这一流程。现在我只想表达我对这种方式的喜爱之情。以前那些需要进行复杂的分支操作的日子一去不复返了，取而代之的是只需要自己对着屏幕查阅代码的简洁方式。

如果我想增加一个新功能，或者会修改代码，我会将代码push到一个新分支，并且新建一个Pull Requests。如果我的代码会影响我同事的代码，或者他们对我的代码感兴趣，或者他们时间充裕的话，他们可以查看我的代码。这时我们可以将那个分支发布到其他机器上，调试新功能，如果一切正常的话，就可以将这个分支合并到主分支去。

有了Pull Requests的工作方式，我就不需要特别去开个会，方便了每个人。还有个原因：

开会是有害的

37signals在《Getting Real》一书中讨论过“开会是有害的”这个主题。相对于37signals，我对于开会的厌恶是有过之而无不及，我讨厌开会。

往往你正在忙的时候，就要开会了。他们还经常会请一些不相关的人开会。即使你对会议的主题很感兴趣，你也会最终被搞得懊恼。因为开会，你不得不停止手头的工作，而开会却是跟你“谈论”你正在的工作。开会期望你提前在白纸上设计出完美的系统，而显然push一个分支，查看diff，基于diff来修改代码更简单些。

除此之外，开会的内容很容易被遗忘。即使你做了会议记录，你也不能保证你能记录所有内容。有某些你没有来得及记下来，你想会后再补上记录。但是三个星期过去了，你回忆起好像某些东西没有记录下来，显然那次讨论才是更重要的。如果采用聊天记录的方式，就不存在这个问题。另外文字沟通的方式也减少了开会时开小差的情况。

我们在GitHub也会开会，但是过去的一年半中开会的次数屈指可数。

最佳状态

你想要你的雇员处于“最佳状态”。但是如果他们只能在那种状态下工作一个小时就要开会了，这将打乱他们。

我们发现，如果让那些负责任的人按照他们自己的时间来安排工作，他们不仅能完成重要的工作，也能保证其他工作的高效率。

三、创新很重要
我们想创造一个创新的环境。员工做项目的时候会爱上这样的环境，它让人振奋，振奋是容易感染人的，可以从一个项目传递到另一个项目。甚至如果我们没有在一个项目上赚到钱，而振奋感仍旧会带入到能够让我们赚钱的项目中去。

酒精

在GitHub有相当多的人喜欢喝酒，这已经不是什么秘密了。我的意思是，我们在每个办公室的储物柜里都有四种啤酒随时可以取用。但酒精并不只是能使人上瘾，它还有更多其他的用途。

聚会。在我们的赞助酒会上，我们要和来自旧金山和世界各地的友人会面。啤酒能让人们为我们的产品感到激动，员工会感到为GitHub工作是一个很激动人心的事情。(和某人喝上几杯，在一个气氛轻松的环境下雇佣员工，比靠大规模紧张的面试的方式更可靠些。)

建立友谊。我们在一起工作，我们不仅是工作伙伴，还是朋友。我们在工作中建立友情。很难区分开我们是在讨论工作还是在聊天。这不单是自我感觉良好。当你和某人关系很好时，你会对他更诚恳。如果别人有了个点子，那么你直接告诉他们你的想法，帮助他们改进。这正是社交的一方面，所以说酒精被称作社交润滑剂。

头脑风暴。酒吧是个适合做假设分析的场所。不要太具体化–可以谈谈工业发展方向，能否应用到你的产品上，我们三年后会发展成什么样。我们许多的产品功能都来源自于旧金山酒吧里不太具体的讨论。

求同存异

我们为没有实战经验的程序员在办公室里设置了Arduino商店。GitHub每个月都会组织健身活动。我们会为谁能在Twitter上赢得最多的粉丝而展开激烈的哲学辩论。我们鼓励员工讨论任何事情，可以是晦涩的编程难题，可以是爬山。

鼓励员工对不同领域感兴趣，激励他们，让他们用完全全新的方式去思考。这样不仅提高了个人，也帮助改善了公司。

创新意味着自我引导

最初Chris问我的一个问题，也是我写这篇博客的原因，就是因为我相信，很多人都不能只是自己想做的产品，这是事实。

当然有些事情更加紧迫，例如在事件表影响到整个网站前就修改它，这比创建一个新的footer重要，但是在GitHub，最重要的在于自我引导，如果你对某一件事情感兴趣，那么就做最感兴趣的吧。往往伟大的作品都出自对作品本身有热情的人之手。

我们能够这样做是因为我们更多的讨论的是我们的产品，每个人都有机会参与。Pull Requests给了我们一个平台，我们可以在产品发布出来尝试我们的新想法。我们做不同的尝试，避免哗众取宠。如果你真的对某个点子感兴趣，就去做吧。我们会跟着你的原型去做。这个方式很棒，催生出很多产品。