对事不对人
在团队讨论中， 不要去说一些否定他人个人能力的话， 而是要简单的表达一下自己的观点， 抱着一种和他们探讨的心态…让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。我最早听这个说法“对事不对人”还是在阿里2010年校招时听当时的CEO卫哲说的， 当时感觉很有启发， 这也让我对卫哲很欣赏， 他口才不是一般的好…在和同事讨论问题时， 即使发生争吵， 也要把争吵点放在问题上， 而不是搞人身攻击， 在争吵过后， 还是要和以前一样共处， 而不要耿耿于怀…
我们每个人都会有好的想法，也会有不对的想法，团队中的每个人都需要自由地表达观点。即使你的建议不被全盘接受，也能对最终解决问题有所帮助。不要害怕受到批评。记住，任何一个专家都是从这里开始的。用Les Brown的一句话说就是：“你不需要很出色才能起步，但是你必须起步才能变的很出色。”
设定最终期限
如果你正在参加设计方案讨论会，或者是寻找解决方案是遇到问题，请设定一个明确的最终期限，例如午饭时间或者一天的结束。这样的时间限制可以防止人们陷入无休止的理论争辩中，保证团队工作的顺利进行。同时（我们觉得）应现实一些：没有最好的答案，只有更适合的方案。设定期限能够帮你在为难的时候果断做出决策，让工作可以继续进行。
尽力贡献自己的好想法，如果你的想法没有被采纳也无需生气。也不要因为只是想体现自己的想法而对拟定的好思路画蛇添足。
如果设计或代码中出现了奇怪的问题，花时间去理解为什么代码会是这样的。如果你找到了解决的办法，但代码仍然另人费解，唯一的解决办法就是重构代码，让他可读性更强。如果你没有马上理解那段代码，不要轻易的否定和重写他们。那不是勇气，而是鲁莽。
学无止境
软件开发行业是一个不停发展和永远变化的领域。虽然有一些概念一直有用，但还有很多只是很快就会过时。从事软件开发行业就像是在跑步机上，你必须一直跟上步伐稳步前进，狗则就会摔倒出局。谁会帮助你保持步伐前进呢？在一个企业化的社会中，只有一个人会为你负责------那就是你自己。是否能跟上变化，完全取决于你自己。
跟踪变化—跟上技术发展的步伐
迭代和增量式学习：每天计划用一段时间来学习新技术，它不需要很长时间，但需要经常进行。记下哪些你想学习的东西-------当你听到一些不熟悉的术语或者短语时，简要地把它记录下来。然后再计划时间去深入研究它。了解最新行情：互联网上有大量关于学习新技术的资源。阅读社区讨论的和邮件列表，可以了解其他人遇到的问题，以及他们发现的很酷的解决方案。额一些公认的优秀技术博客，经常去读一读，以了解那些顶尖的博客作者们在关注什么。（//感想：嗯， 现在我每天都花上1个小时左右的时间看IT相关的资讯， 平时经常看cnBeta，CSDN, 腾讯科技， 互联网的那点事， 月光博客， 除了这些网站或是博客， 还有腾讯微博和新浪微博， 收听一些IT名人的微博， 能了解到很多国内国外的行情）如饥似渴的阅读:找一些关于软件开发和非技术主题的好书,也可以是一些专业的期刊和商业杂志，甚至是一些大众媒体新闻（有趣的是在那些常常能看到老技术被吹捧为最新潮流）。(//感想： 嗯， 最近在网上下了好多程序员修养的书籍， 都还没看， 准备以后抽时间把这些书都看掉， 我觉得缺少的就是程序员职业修养， 视角太过狭窄， 所以想多看点这方面指导的书籍启发启发， 《高效程序员的45个习惯》是第一本阅读的书， 还有几本如《疯狂的程序员》， 《人月神话》， 《程序员自我修养》， 《程序开发心理学》， 《软件开发沉思录》， 《软件随想录》， 《人件》， 当然这些我都还没看， 只是看着名字， 觉得应该还可以， 以后都要看掉)参加研讨会议：计算机大会在世界各地举行，许多知名的顾问或者作者支持研讨会或者课程。这些聚会时向专家学习的最直接的好机会。
18. 每个人都比你厉害吗？嗯，那太好了…
为什么是这样呢？如果你是团队中最好的队员，就没有动力继续提高自己。如果周围的人都比你厉害，你就会有很强的动力区追赶他们。你将会在这样的游戏中走向自己的顶峰… 所以遇到比你强的人要放平心态， 努力学习他人长处， 早日超越…
学习新的东西，丢弃旧的东西
在学习一门新技术的时候，要丢弃会阻止你前进的旧习惯。毕竟，汽车要比马车车厢强得多。
不停的问为什么
不能只满足于别人告诉你的表面现象，要不停地提问知道你明白问题的根源。----为什么要问为什么呢， 开个玩笑， 嘿嘿…
时间盒
文章原话 //start敏捷开发者可以从多方面得到反馈：用户、团队成员和测试代码。这些反馈会帮助你驾驭项目。但是时间本身就是一个非常重要的反馈。许多的敏捷技巧来源于时间盒-----设定一个短时的期限，为任务设定不能延长的最终期限。你可以选择放弃其他方面的任务，但是最终期限是不变的。你可能不知道完成所有的任务需要多少个时间盒，但每个时间盒必须是短期的、有限的，并且要完成具体的目标。例如，迭代一般是两周的时间。当时间到的时候，迭代就完成了。那部分是固定不变的，但是在一个具体的迭代中完成哪些功能是灵活的。换句话说，你不会改变时间，但是你可以改变功能。相似地，你会为设计讨论会设定一个时间盒，即到了指定的时间点，会议结束，同时必须要做出最终的设计决策。当你遇到艰难抉择的时候，固定的时间期限会促使你做决定。你不能在讨论或功能上浪费很多时间，这些时间可以用于具体的工作。时间盒会帮助你一直前进。//end 嗯， 给自己限定一个时间， 会督促自己去赶紧完成…
让设计指导而不是操纵开发
设计满足实现即可，不必过于详细：好的设计应该是正确的，而不是精确的。也就是说，它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节。它是目标，不是具体的处方。（如何知道一个设计是好的设计，或者正合适？代码很自然地为设计的好坏提供了最好的反馈。如果需求有了小的变化，它仍然容易去实现，那么它就是好的设计。而如果小的需求变化就带来一大批基础代码的破坏，那么设计就需要改进）关于上面那段描述什么是好的设计的时候， 虽然说是那么说， 但是如何做到？自己理解的就是要做到代码的可复用性强吧， 在设计类的时候每个类都有一个特定的功能， 而不是集各种功能于一身， 同样， 每个函数的功能也都要尽量的单一， 用这些单一功能的函数去组合完成一个较大些的功能， 当这个较大些的功能需要改变时， 只需要改变一下这个小的功能函数的组合方式即可， 而不用去改底层的函数…晕， 这个我也没经验， 只是自己的一点想法， 还得学习…