做事

指责不能修复bug---Blame dosn't fix bugs.

把精力放在解决问题上,而不是抱怨和指责.

过程符合标准并不意味着结果是正确的.

在团队中,勇于承认自己不知道答案,这会让人放心.

"这不是我的错",这句话不对."这都是你的错",这句话更不对!

如果你没犯过任何错误,说明你可能没有努力去工作.

如果团队中的一个成员的行为一再伤害了团队,则他表现的很不职业.

欲速则不达

防微杜渐---Be ware of land mines.

不要坠入快速的简单修复之中.要投入时间和经精力保持代码的整洁,敞亮.

一次又一次的快速修复,每一次都不探究问题的根源,久而久之就形成了一个危险的沼泽池,最终会吞噬整个项目的生命.

你需要了解团队的开发方法或开发过程.

如果团队成员花些时间阅读其他成员的代码,他们就能保证代码是可阅读和可理解的.

代码复审是发现bug的最有效的方法之一.

单元测试是防止代码难懂的重要技术.

你必须要理解一块代码的是如何工作的,但不是一定需要成为专家.

不要急于修复一段没能真正理解的代码.

所有的大型系统都非常复杂,没有一个人可以完全明白所有的代码.

对事不对人

消极扼杀创新---Negativity kills innovation.

整个团队应该关注真正有价值的问题,而不是勾心斗角,误入歧途.

你必须把重点放在解决问题上,而不是极力证明谁的注意更好.

你不需要出色才能起步,但是你必须起步才能出色.

如果你是一个有远见的人,就一定要特别尊重别人的意见.

你是一个掌舵者,一定要把握方向,深思熟虑,吸取各方意见.

关于决策:设定最终期限,逆向思维,设立仲裁人,支持已经做出的决定

尽力贡献自己的好想法,如果你的想法没有采纳也无需生气.

脱离实际的反方观点会使争论变味.不带个人情绪并不是盲目接受所有的观点.

排除万难,奋勇向前

动手证明是最有效的方式,把糟糕的代码放到一边,立刻重写.

当发现问题时,不要视图掩盖这些问题.

如果设计或代码中出现了奇怪的问题,花时间去理解为什么代码会是这样.

如果你找到解决的办法,但代码仍旧令人费解,唯一的解决办法是重构代码,让他可读性更强.

如果你没有马上理解那段代码,不要轻易地否定和重写他们.

如果你说天快要塌下来了,但是团队成员都不赞同.反思一下,也许是你是正确的但你没有说清楚自己的理由.

如果你说天快要塌下来了,但是团队成员都不赞同.认真考虑下,他们也许是对的.