Team Geek

culture 来自于创始团队， 即使是成熟公司，我们也可以track down 到他们

为什么culture很重要

因为你不去关注culture， 就会有个性很强的人会传播他的文化到team中去。

如果传播的是positive 的尚可，但是经常的是非如你所愿的。

如果team 没有形成共同价值观，无可保卫，那么被其他文化入侵，接管 就成为必然。

team culture 的组成是每一个人的担当。

team culture 会帮助team 来选人，选更多的适合这个culture的人进入团队。

在招聘过程中也是一样， team culture 是否相合决定了你是否会花更大的经历来让新人settle down .

在高度需要creative thinking 的软件行业， great products 需要 great engineers.

好的工程师喜欢和好的工程师一起工作。所以start team要从好的，牛人工程师开始招聘。

前面打消读者疑虑的东西略下不表：

第一章brief 放弃对天才程序员的迷信

1. 程序员可能有的一个通病就是不愿意在项目早期go public his code.

2. 软件是一个集体运动

3. 但是大家往往只注意了集体中最耀眼的明星，like Michael Jordan.

人们模仿明星，但是忘记了，我们可能并不是明星。

但是人们却喜欢用明星来要求自己，害怕自己的mistake放在聚光灯下。

4. 于是许多程序员喜欢躲起来干活，直到最后交出一个master piece 意图一鸣惊人（因为明星的光芒太过耀眼，似乎他们不曾失败过，就一步登天）

5. 躲藏是有害的，

只有更早的更多的go public 听取意见， 才能使得事情更安全。

公车因子： 项目里面多少人被撞死之后，项目才会黄。

项目有更多的人参与，而不是密室里的谋划，才能更安全。

现在，程序员的工作的排除干扰和提高带宽的方法 ： open office

6. 三个基础： HRT(like heart) = Humility + Respect + Truse

如何实践 HRT

如何谦逊的提意见，对待事情本人，而不是人；

Learn Patience Be Open to influence

Most software engineers work in dysfunctional corporate bureaucracies and need to employ certain manipulative techniques to get things done effectively.... We call it organizational manipulation. As companies grow, they develop bureaucracy and processes in an effort to manage profit, reduce risk, increase predictability, and support the massive weight of the organization itself. You need to underpromise and overdeliver whenever possible. As an engineer, try to focus your energies on launching products over just about everything else. As tempting as it might be to spend a ton of time cleaning up your code base and refactoring things, we've learned from experience that if you dedicate more than half of your time to this kind of defensive work, it's hardly valued at all and you'll find yourself in the somewhat embarrassing position of having nothing (politically) important to show for your time. This is not only a good way to get no recognition, but it's also a good way to get your product canceled. "Perception is nine-tenths of the law" We now have a handy rule we live by: a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide. Friends come and go...enemies accumulate. If you can't change the system, there's no point in continuing to put energy into changing it. Instead, put energy into leaving it. If you don't put the effort into understanding how to navigate your organization, you're leaving a huge part of your destiny to chance.

Chapter 4 When a team is started by a group of angry jerks, the effort tends to attract more and more individuals of the same sort. Certain projects that we won't mention here (like the Linux kernel community) are keen examples of this -- endless bickering, chest thumping, and sniping. lol.... You much protect your team's attention and focus. Ironically, years later, this person's predictions turned out to be correct on many levels, but that didn't stop Subversion from becoming wildly successful anyway -- at least in corporate software development. The point here isn't about who is right or wrong, but whether a disagreement is guaranteed to come to a conclusion and whether it's worthwhile to keep a debate going. ... at some point you need to decide when it's time to cut your losses and move on. not let "the perfect be the enemy of the good" The stronger your emotions are, the more likely you are to waste hours or days writing passionate replies to someone who doesn't deserve such attention. Choose your battles carefully and keep calm.