team geek
1. 转载自http://book.douban.com/review/6007037/，版权归丸子(^.^)v所有。
New Google employees (we call “Nooglers”) often ask me what makes me effective at what I do. I tell them only half-jokingly that it’s very simple: I do the Right Thing for Google and the world, and then I sit back and wait to get fired. If I don’t get fired, I’ve done the Right Thing for everyone. If I do get fired, this is the wrong employer to work for in the first place. So, either way, I win. That is my career strategy.
这是我读这本书过程中看到觉得最激动人心的话^_^ 工程师科学家群体可爱的一点， 就是在这个群体中你还可以找到这么一些人， 他们不仅敢于坚持， 毫不畏惧自己的坚持可能给自己带来的所有潜在的损失， 敢于面对， 并且敢于说出来， 以一种非常自豪的态度， 类似像老子 敢做就敢当， 敢想就敢承认！ 这样～ 这让我觉得我并不孤单>_< 这已经有点相依为命的感觉了， 因为同类真的太少太少～ 然后我就在当天的facebook广播里插播上了以下这么一段:
It applies to be effective to find the right one. I just do the right thing for her and me and possibly "us", and sit back and wait to get fired. If I do not get fired, I have done the right thing for everyone. If I do get fired, this is the wrong one to accompany with in the first place. So, either way, I win. That is my truelove seeking strategy = v=
开篇intro说是写给工程师看， 其实到后来， 后来特指最后一章， 感觉更像是写给经理看来着， 但跟专门写给经理看的 比如人月神话， 人件等等相比又总有点独善其身的味道。 个人觉得就是写给team lead那么个角色看的～ 首先， team lead并不一定是coding最强那个， 比如我现在就是team lead了， 在以intermediate level入职14～15个月以后， 其中前两个月是完全颓废的 接下来四个月是半废状态， 个人觉得单就技术而言还远远不到principle engineer或者architect的程度； 第二， team lead的职责不是说code完自己那部分就完事了， 下接程序员 上接经理， 要按各人的强项分派给各人相应的任务， 保证队员的个人生活的同时还要按着经理的要求， 保证各功能特性的开发进度贴着商业宣传发布计划或者集团里其他部门的合作项目的进度那么来走， 有任何搭不上的就是team lead在奔走协调 有任何特别难都没人做得来或者直接就没人愿意接手的就是team lead来做 holy shit； 最后， 在木有架构师并且又非常需要大的翻新重写的时候， 就是team lead来担任这个苦逼的角色了， 尤其队中有元老反对重构的时候， 还必须用礼貌而坚决强硬的方式获取他们对此事的支持， 维持…… 妈的那个词儿用中文怎么说来着？ 团队的结构完整思想一致性～ 囧～ Anyway, this book is not for writing good code, but for writing good software! For some reasons, 除了设计模式， make it big in software和代码阅读技巧以外， 这本书是每个CS毕业生都应该懂但学校没有教的内容之一。 For future reference， 下面简单总结一下全书中比较实用需要时刻铭记在心练习到深入骨髓任何时候不爆线不走光的技能和办公室行为基本指导思想：
不要隐藏自己的过失以及能力上不足的地方， 做不到就老老实实说做不到 向做得到的人请教＝ ＝ 尽管有可能失败， 还是可以努力往前迈进， fail early, fail fast, fail often. 这样我们才有改进的机会～ 那做为人生来讲，如果每件事事后都注意总结， 注意改进， 简单说如果能保证每个错误你此生只犯一次， 那一生失败的总数应该是一定的～ 那么， 少年， 让我们尽量向只犯一次这个目标看齐， 把失败的quota在前40年都用光吧～
让团队成员之间心无芥蒂 同心协力的关键： 人性， 尊重， 信任(HRT)。 实际上包括但不限于办公室这么个背景环境， 任何社交方面的冲突都可以归结为 这三样中某一样或几样的缺乏。
做为HRT的具体实现， 比如：
没人喜欢跟在哪里都表现得好像他特别重要的人合作。 看待自我的态度很重要， 这跟你对团队的贡献是两码事。
关于code review， 讨论措辞， 永远记得一点， 帮助性的善意的批评 破是为了立 先立再破或者不破， 大家都心悦诚服滴follow你立起来的东西那其他的没人去做了那就不攻自破， 这样最大的好处是提出对立观点的队友不会有被critisized的不悦感＝ ＝ 没人想被critisized 即便只是队里一个喽啰～
迅速入手， 要失败也失败早一点， 这样可以早点学习， 迭代式滴快速进行改进。
留出时间学习 要分清重要的事和紧急的事。 紧急的事就是那些有deadline的， deadline越靠近越紧急。 重要的事就是那些区分你跟其他人技能等级知识水平的， 让你变得不可被取代让领导都感到有压力觉得老婆生气都不重要但一定要哄好你否则你一生气撒腿走人一大摊子事舍你其谁可以瞬间陷入瘫痪。 区分度越大越重要。 一般公司让你做的大多紧急的事， 办公室里的生活就是deadline oriented， 有些可能很有技术含量， 不过应该不多， 因为做为经理来讲他大概知道每个人的知识和能力， 分配你做你做不来的事到时候ship不出来那项目是要fail 的， 这时候要想获得career promotion就要靠自己每天划出一定时间来增益己所不能。 做为我来讲， 在原来那家公司是android tech lead， 到现在这家公司一开始就是写些可有可无的东西， 经理态度很明确啊， 就是你写得出来当然好， 写不出来那也没所谓， 反正我们公司大着呢也不缺养着你这么个废物的钱。 这时候尤其需要一种耐心， 那么耐心哪里来呢？ 从盼望中来。 每天学新的东西， 并且你知道怎么样使你做同样的事情比其他人做得更好的那些， 日积跬步， 始终focus在whatever currently assign to you， 然后你大概会知道在什么时候能冒出来， 然后你知道这样不被信任的感觉什么时候可以终结， 这就是盼头哇～ 而快速晋升的关键也恰恰在于此： 每一次不仅仅deliver一个能work的东西， 更重要的是deliver一种远超预期， 一种amazing， 一种over qualified current position的感觉。 记住， 每一次！
快节奏的生活中， 计划往往赶不上变化， 但这不意味着我们就不需要计划， 而是说， 在面对变化的时候， 怀着一种open 而实事求是的态度。 永远不要觉得中途插进来策划时间不到1分钟的意图取代你原来花一个星期才做好的计划的这么一个想法就是不成熟不可采纳或者totally bullshit， 试着想想你队友也不弱， 无论技术水平开发经验， 好吧其实我一直觉得我队友们都比我强， 就那些一开口就“你还没出生的时候我就怎么怎么滴”的货， 那为什么会产生这样的想法， 试着顺着他们的出发点往下走， 一旦end to end的整条通路每个环节的逻辑都make sense，并且在bottleneck问题上跟你的方案比有胜出的地方， 那就不用管你原来那一个星期的努力白费了好可惜早知道就不去想了神马这些碎碎念了， 大胆采用新想法。 这是一种快速自适应的能力， 也是一种适当相信别人， 相信你不能掌控的部分的能力。如果别人没有能力掌控， 却愿意凭着对你的信心相信你你觉得很appreciate的话， 那相信我， 你对别人做同样的事情时别人心里会有跟你一样的感觉！
其实中国传统教育中有很多事， 我觉得现在看来已经不适用了～ More specifically对快节奏办公室生活来说我此时此刻脑里想到的有两件事， 以前读书时候学校从来没教， 或者说有些学校教着完全相反的做法， 反倒是一些经常失恋的家伙写的那些无病呻吟的文字里见得比较多： 一是忘记不该记住的， 二是相信你目前无法相信的， 无论那是凭你个人主观感情， 或者甚至凭你已有知识能力做出的客观分析都无法相信的。 第二点就是刚才说滴。 至于第一点， 遇到事情如果能在几分钟之内迅速处理， 或者figure out应该forward给谁处理最妥当， 那就迅速把它给做了， 然后最重要也是最难做到的是， 彻底忘了它！ 这样你不用一直keep住一堆事在你脑里， 然后你可以全力以赴做好眼前的事。 如果不能， 那么静下心来分析一下， 或者跟相关的人谈如果有必要的话， 至少figure out要解决这个问题必须先解决哪几个问题， 或者必须先满足哪些条件， 而那些事又都是什么时候才会发生， 把整个dependency和各事情的timeline做成一个diagram整进calendar里 然后彻底忘记直到calendar提醒你每个单独的事件。 Point就是说， 你要心无旁骛滴一直focus在你目前工作的事情上。这不是一句空话， 要切实做到， 最好的办法是有效滴清空但不遗忘其他事情， 使你脑里任何时候就一件事…… (这跟 不要在一棵树上吊死是两码事， 那是给那些有勇无谋的家伙， 用来把他们从另一个极端中拉回来用的。)
接下来就是谈文化的问题了。 构建团队文化， 或者说企业文化的关键， 在于沟通。 沟通的量要大到能让那么多千奇百怪思维形态各异的家伙工作起来真正实现 “one mind, many hands.” 方式可以有很多， 邮件列表， 内部wiki/BBS， 设计文档， 代码注解等等。
大量沟通的关键是要让别人乐意花时间花精力跟你练习英语原书讲了很多很实用很具体的技巧， 总的来说， 就一条原则， 不要让不想知道或者不需要知道的人知道。把握对象的背景知识倾听兴趣和时机。 向合适的对象传递合适的内容就比如如果我在看陈绮贞音乐专辑的页面， 很可能我对陈绮贞在当地或者附近的现场演唱会信息感兴趣， 收集了我的位置信息和浏览历史纪录以后你pop up相应的广告我会很感激并且很乐意点击， 但如果你这时候pop up 宝马车的广告， 无论画面多好deal多吸引人我只会觉得占用了我本可以多看音乐专辑插图以及过往现场演唱会图片的地方； 在合适的时候传递合适的内容比如 OK我是很喜欢陈绮贞， 但现在我要听一下她新专辑的demo片段， 我已经大量浏览过她的现场演唱会图片或者我其实想等下再看这些， 反正我现在不想看， 我只想听， 你就不要整版滴铺那些图片让我找一个play button还要多点一堆链接 拼命压抑自己狂躁的情绪多load一堆页面， 最后才来到play button的所在。
还有一点我现在做得很不好的， 尊重对方在交流中发表自己基于刚听到的东西临时起意产生的一些想法并得到认真对待无论那想法有多傻多天真的意愿和权利。
有几点原则需要一直遵守， 因为在绝大多数情况下这些实践都是有利无害的～
对每次commit 都要有code review
开发过程需要有实时测试， 发布过程需要控制好， 使得发布变得容易， 这样可以至少每周出一个QA release并且不占用dev team太多时间。 I do think we really need some automation。
所有这一切沟通的努力都是围绕着代码在进行， 在进行沟通的过程中应该时刻记得这一点。 不要喧宾夺主让工具和辅助手段变成工作生活的全部或者说， 大部分～ 这不仅在开发活动中， 其实我想说在日常生活中人们经常犯着类似的错误， 矫枉过正。 比如以前在计算机学院经常可以看到一堆人整天都在学英语， 没错英语是计算机的母语， 没错工欲善其事必先利其器， 没错我们全都用英文影印版在教学英文不好看到都头大根本没法学， 好吧老师讲课是用中文所以…… 但是也不用把90%以上的时间都拿去学英文到毕业的时候英文比外语学院的人都利害看到函数指针直接傻掉“这什么呀这写错了吧 指针没有这么声明的吧blablabla” ； 再举个例子， 比如在一段relationship里， production code是你的另一半， 是那个人， 爱只是工具或者辅助手段， 爱把你们两连在一起， 结婚是跟那个人连接成一体不是跟爱连接成为一体， 很多搞错这两者关系的人的一个外部表现就类似， 不断滴换着爱人， 享受被爱的感觉， 爱是重点是享受的来源人只是一个工具用来提供爱的具体是哪个人来提供并不重要 重要的是如果这个工具malfunctions， 很简单那就换一个啰就像如果我的车坏了修都懒得修直接买一辆新的， 坐什么车我并不在乎我在乎的是任何时刻要有这么个东西给我提供这种竞速的感觉…… 这项原则应该应用在不只包括平常队友间的口头沟通， 包括但不限于电子邮件， 内部IM， 设计文档， 产品目标定义文档， 代码注释等等， 既要保证别人充分理解， 又要尽量减小communication overhead， 这里不是打马虎眼， 而是这个微妙平衡的拿捏真的是case by case。 这本书中介绍的是对大多数场合70％～80％适用的approach， 看完以后需要自己figure out的是稍微改变一下， 看怎么样就对我现在身处的场合100%， 或者至少95%适用的approach。 关于这个平衡的拿捏， 有一本书， 中国人写的个人觉得还挺不错的， 名曰 大道至简。 貌似作者是在金山还是腾讯当一个什么东西记不清了……
Every boat needs a captain 这一章真的就完全是针对team lead这么个角色说的了～ 其实并不是说一定要title 挂上这个， 很多公司甚至都木有这么个title 但是如果你每日的工作主体， 你60%以上的时间都工作在相应的职责上， 那都可以读一下。 实际上如果一些基本指导思想已经在你脑中成型甚至运用得炉火纯青的话， 这一章是可以不看的， 或者说任何软技能的东西都可以不看， 遇到事情具体问题具体分析只要解决方案不违反江湖道义不违背武林狭义你看怎么好使就怎么来吧， just simply let it as it is, 我相信在一些靠谱指导思想下做出的解决方案不会差到哪里去， 比那些教条主义把课本中的定理运用到不合适的地方的家伙要好得多。 这一章最主要就是给出， 比如基于这么几条办公室行为指导思想， 那具体到team lead这个位置面对这种情况应该具体使怎么表现呢？ 如果你不具备自己figure out解决方案得能力或者你想求快直接拿人家现成的做法来进行实践然后基于反馈去修正的话， 也可以读一下。 书中列举了几个antipattern， 我不是完全赞同的， 但是人家对此是有着多年实践经验的， 最重要的一点是有着众多成功经验的， 而我刚那啥＝ ＝ 还是那句话， 如果没立起来， 不要随便去破……
最后一章主要论述了， OK前面说的是理想情况， 那万一真遇到了猪一样的队友， 好吧也不是说人家蠢就是说对团队产生负面影响的人要是不幸跟你共事， 从developer的角度应该如何相处； 这是一方面另一方面在于如果你直接report的那个经理是个小人， 饿你筋骨劳你体肤还抢你credit 屁事不干啥都不懂就会瞎指挥， 那从developer的角度又该怎么办， 什么时候采取defensive的approach什么时候采取农村包围城市的还蛮aggressive的approach， 然后谈到办公室政治 ＝ ＝ 局面变成这一步就很不好了但是感谢主， 我现在的情形还不需要考虑这个。 最后讲到对产品， 如果你个人能控制产品特性和发展战略的话在考虑这些问题的时候思路里应该包括哪些因素， 目前我也还没到这一步， 可以mark一下到时候再回来看。
这段时间职场上发生的事情让我越发相信，真正的相信，纯粹的热爱，小小的尝试，长长的坚持，就可以慢慢成就大大的梦想， 虽然生活中发生的事情恰恰相反＝ ＝
最后， 以一首诗来概括一下这段时间的工作学习生活：
日升月落， 生生不息的世界
永恒的远方， 你的轮廓在夕阳中融化
找到了一种幸福足以悲伤
沉默的祈祷只为安抚受伤的灵魂
当一切归还于寂静 我则别无渴求……
2.自己的话
我没有丸子(^.^)那么多的经历和经验，能从自身和外部环境写出这么多的感悟。
我的感悟，可能就是，作为一名职场新人，如何融入团队，如何对待猪一样的队友，如何对待神一样的队友，如何处理与leader的关系，如何从leader的角度出发考虑问题，如何培养自己成为leader。
至于目前，对我来说，融入团队最重要的是，培养自己的技能树，让自己成为某一方面的专家。做一些career promotion方面的工作。
