[翻译]Team Geek -01- Introduction（前言）

英文版原版下载：http://download.csdn.net/detail/leon1418/6935271

- 使命陈述

本书的目的是通过帮助程序员提高理解、交流和与人协作的能力来更高效的开发程序。

- 引言

 "Engineering is easy. People are hard"

 -Bill Coughran, former senior vice president of engineering at Google

生活总是充满意想不到的转折，我俩从来没有想过有一天我们会写一本关于软件工程的书。

像大多数电脑极客一样，我们发现我们所爱好和热衷的事情“玩电脑”会是毕业后谋生的一个很好的手段。并且，像大多数我们这一代的黑客一样，我们在90年代中期用散件组装电脑，用一大堆磁盘安装预发布版本的Linux系统，学习操作UNIX系统的机器。我们的工作像更是系统管理员，在互联网泡沫破裂前夕我们在一家小公司当程序员。当泡沫破裂后，我们开始为硅谷幸存下来的公司工作（像苹果），之后我们加入了一家创业公司设计和开发一款开源版本管理软件，就是Subversion。

但在2000年到2005年之间发生了一些意想不到的事情。在我们开发Subversion的过程中，我们工作职责慢慢改变了。我们不再每天只在自己的世界里编代码，我们要开始领导一个开源项目。这意味着需要成天挂在聊天室里和一群志愿程序员打交道，并且关注他们都在做什么；也意味着几乎完全要通过电子邮件来协调新功能的开发。一路过来，我们发现一个项目取得成功的关键不仅是写出漂亮的代码，为了实现最终目标人与人意见的合作方式同样重要。

2005年，我们在Google芝加哥工程办公室继续我们的程序员生涯。此时我们已经深入参与到了开源世界当中，现在不仅仅是Subversion项目，还有阿帕奇软件基金会项目（Apache Software Foundation）。我们将Subversion放到了Google BigTable系统，并且在Google Code下发起了一个开源项目的托管服务。我们开始关注并且在各种开发者大会上发言，像是OSCON、ApacheCon、PyCon以及Google I/O。在这当中，我们获得了很多真实软件开发项目中的智慧和轶事，这些项目包括公司项目和开源项目。开始时可能只是一系列关于糟糕软件开发过程的幽默讨论，最终变成讨论如何避免团队中一条臭鱼搅腥一锅汤。当越来越多的人加入我们的讨论中时，这个场景简直可以描述为程序员的集体治疗，每个人都会从我们讨论和抱怨的各种问题中找到共鸣。

 六年过去了，我们的编辑Mary Treseler指出我们应该将这六年来所经历的这一切，所参与的很多关于软件开发挑战的讨论写成一本书。这就是这本书的来历。

想写出优秀的代码？这本书正适合你

附原文：

- Introduction

"Engineering is easy. People are hard."

- Bill Coughran, former senior vice president of engineering at Google

Life is full of unexpected twists, and the two of us never imagined we’d someday write a book about software engineering.

Like most computer geeks, we discovered that our hobby and passion-playing with computers-was a great way to make a living after graduating college. And like most hackers of our generation, we spent the mid-1990s building PCs out of spare parts, installing prerelease versions of Linux from piles of diskettes, and learning to administer Unix machines. We worked as sysadmins, and then at the dawn of the dot-com bubble, became programmers in smaller companies. After the bubble burst, we started working for surviving Silicon Valley companies (such as Apple) and later were hired by a startup (CollabNet) to work full time on designing and writing an open source version control application called Subversion.

But something unexpected happened between 2000 and 2005. While we were creating Subversion, our job responsibilities slowly changed. We weren’t just writing code all day in a vacuum; we were leading an open source project. This meant hanging in a chat room all day with a dozen other volunteer programmers and paying attention to what they were doing. It meant coordinating new features almost entirely through an email list. Along the way, we discovered that the key to a project’s success wasn’t just writing great code: the way in which people collaborated toward the end goal mattered just as much.

In 2005 we started Google’s Chicago engineering office and continued our careers as programmers. At this point we were already deeply involved with the open source world-not just Subversion,but the  Apache Software Foundation (ASF) too. We ported Subversion to Google’s BigTable infrastructure and launched an open source project hosting service (similar to SourceForge) under the banner of Google Code. We began attending-then speaking at-developer-centric conferences such as OSCON, ApacheCon, PyCon, and eventually Google I/O. We discovered that by working in both corporations and open source projects we had accidentally picked up a trove of wisdom and anecdotes about how real software engineering teams work. What began as a series of humorous talks about dysfunctional development processes (“Subversion Worst Practices”) eventually turned into talks about protecting teams from jerks (“How Open Source Projects Survive Poisonous People”). Larger and larger crowds gathered at our presentations in what can only be described as “group therapy” for software developers. Everyone could relate to the sorts of problems we talked about and wanted to gripe about these problems as a group.

And so here we are, six years later, with a pile of standing-roomonly talks about the social challenges of software development. Our editor at O’Reilly Media, Mary Treseler, pointed out that we should convert these talks into a new book. The rest is history