1. 大胆的提出问题　有些新的程序员在进入公司的第一天很犹豫是否要去向别人寻求帮助，比如：当程序员在项目环境设定上遇到问题或者是他们不明白这个项目的商业流程的时候，他们很犹豫，不知道该不该问出这个问题。其实这都不是什么大的问题——尽管寻求帮助，或是向别人澄清一下你的想法。否则的话将会在和项目有关的问题上纠结、浪费时间。还有一种情况就是，当领导让你自己提出根本没有任何限制的问题的时候，很多程序员对自己的口才很吝啬。千万不要害怕问问题，尤其是在大的环境下。2. 找准自己的定位　在很多项目或者项目模块里缺少资源，这就意味着在你开始工作的时候或是完成目前项目的时候要让你的领导知道你的偏好项目和执行能力。许多人常常是喜欢加入一个新的有特色的项目，而有的人喜欢加入一个有熟人的开发团队。不过，最明智的选择是挑选一个没有多少同行的开发者知道的项目，只有你一个人在这方面擅长。只不过在刚开始的时候需要花大量的时间去了解熟悉它的运作模式和现有的代码；当一切事项都已掌握之后，就可以向管理层自我推荐，领先于别人，就是超越了自己。3. 熟悉App的“蓝图”现如今大多数的企业App都是比较复杂的，使用不同的技术完成的模块来组成的。作者展示了他现在的工作就是由3个部分组成的：一个和社交网络和收集数据互动的模块。一个处理收集的所有数据的模块。一个UI模块。　　每一个模块都是由不同的开发者团队开发并操控的。这些模块在技术上没有什么联系，但是在商业流程上是相互联系的，也就是说，无论什么时候想要引入一个新的功能的时候，都会影响到这3个模块。 事实上并没有多少人理解整个App的商业流程，当讨论一个新功能的时候，经理常常会要求在行的人对软件程序的更改最初最好的评估，评估结果可能会用在每一个模块里。所以如果你这道这个App蓝图的话，你就能参与到这个讨论中。4. 做你需要做的事，而不是做你喜欢的事　一些非常有才能的程序员经常会遇到很严重的问题——他们有自己的特别之处或者说是感兴趣的方向，一旦被要求去做其他的不一样的事情的时候，能力和做事质量就下降了。因为他们不能集中注意力在不感兴趣的事情上，这是很致命的短板。你如说：人们可能想要测试Scala，但必须先处理Hibernate或原生SQL；他们可能想要并发性，但是必须要协助与前端开发相关的工作。　如果你需要长期处理你自己根本不擅长的技术问题/工作，那么你最好换工作。否则如果你是临时帮助别人处理你不擅长的问题，最好表现的专业一点，把事情做好。5. 善于分享，乐于帮助     估计很少有人单枪匹马的情况下还能有很高的产量吧，这只能暗示在交流上的贫乏。自私是团队合作的最大障碍，最后也只能是整个团队停滞不前的结果。这样的“孤狼”也基本上得不到团队的信任。此外，如果你在一个区域办事处工作，而你的同事没有把任务做好，你最好去帮助他，因为团队荣誉至关重要，这也是一个双赢的决策。6. 尽量给出现实的评估给出太乐观的评估对于程序员来说是比较困难的，作者站在自己的立场给出两大主要原因：A. 我们经常忽略将要花费的时间：在实施阶段处理预料之外的问题。在开发环境上测试实现的功能。编写单元测试和集成测试。分散时间和精力到其他高优先级任务上。B. 有时在给出真正的评估之后会让我们觉得不舒服，因为经理看到这样的评估之后表情会很吓人。在这种情况下，我们通常会把特点划分成几个子任务，以至于总的评估看起来不是那么可怕。太乐观的评估在大多数情况下会有悲惨的结局： 你必须把任务移到QA在一个buggy状态下，通过思考来证明它：“通常QA会返回所有开发功能列表的备注资料给开发人员，所以我仍然会有机会解决所有的bug”。但是在现实的评估条件下情况就不会是这个样子了。
7. 测试，测试，再测试！      许多程序员因为错误评估而被迫转入QA环节，有些程序员在交货期来临之前停止了任务，转入测试阶段，只是想证明他们的高效能。当然了，这是一个好的意图，但是并不似所有的掉头检查都能带来好的结果。总之，中途检查要比从头开始好得多。再次强调一下单元测试和集成测试的重要性。它们是回归分析的第一个指标：一个打破现有功能的机会。不幸的是,有些人编写测试只有一个目的——避免漏掉代码覆盖率而带来的责任。这样的代码在代码审查过程中需要被捕获并拒绝，这是提高代码质量的另一个好方法。8. 记住：谁都会犯错误的。有谁希望和一个出现bug就喜欢批评别人的的人一起工作呢？估计没人愿意，但事实是我们大多数人看起来就是那个样子，只是自己没意识到。下面列举了一些避免出现这些状况的建议：如果你和同事一起构建一些功能，而他有稍微慢了一些，与其去责怪他还不如去帮助他，至少应该到经理那去争取更多的时间。既然需要共同的按时交付产品，那么两个人对这项功能的完成都是有责任的。       当你修复了一个bug或者是发现了一个bug，即使你知道是谁的缘故导致这些bug的出现，也没必要通过网络电话渠道让公司里的每个人都知道这件事。犯错误是在所难免的，有的时候你会遇到“ugly code”模块，同上，不需要让更多的人知道它的制造者。 如果你对一个同事有什么不好的意见，都没必要向你的上级反映，除非上级向你询问。首先你要确保你的上级是一个开明人士——知晓他所管理的团队里队员的强项和弱项，这样才能处理好队员之间需求。     恰恰相反，我们应该经量多的向大家包括领导反映同事做的一些好事。比如，数周之前我的一个同事在早上7点钟的时候临时驾车到公司来试运行App模块，所以他应该得到大家的赞美之词。
9. 在社交网站上宣传公司的强项。现如今，基本上每个程序员都在使用社交工具。你可以关注朋友们的公司，也可以在网上介绍自己所在公司，不管是好事还是坏事，都可以在网上贴出来：有的时候会组织技术峰会、赞助商会议、商业论坛、发布会、寻找新的开发者等等，社交工具对于一个程序员来说是有很大的用处的。除此之外，有很多的网站上都有公司人员对公司的评论，任何人都可以写，当然，只要是你喜欢的内容，没必要撒谎。在国外，想要和公司CTO或者是CEO进行交流的最简单的方式是通过Twitter，在国内可使用的交流工具也是各种各样啊！10. 小建议和小技巧。　接下来的是一些能够让你获得领导或者同事的赞美的建议和技巧：　A. 适应老板的时区许多来自欧洲和印度的程序员都是从美国那边接受发自总部的指令的。在这种情况下，如果程序员能够在晚上的时间段和美国总部进行交流讨论工作上的事情，肯定比在下午5点钟下班时候和总部进行交流所获得的工作效率要高得多。B. 如果有需要，任何时候都要帮助公司做事。       身边的例子：公司的生产系统需要全天候的监视着，因为任何时候都有可能出现问题。通常情况下是区域的程序员参与监视，但是去年的新年假期期间我们被要求留下来值班，我被安排在大年三十那天，我本来可以要求调整一下的，但是我服从了公司的安排，很幸运，那一晚上基本上没什么问题出现，我在一个很正常的环境下度过了我的新年，但是至少公司知道我随时愿意为公司付出。　C. 在公司的指引下参加应聘面试     如果你有机会以面试官的身份参加面试，一定要好好利用这一机会，因为这是无价的经验。首先，这能发挥出你的口才能力，很多程序员都缺乏这样的技能。其次，你可以认真听一听别的面试官（你的同事）都问了哪些问题。最后，你对求职者的观点将会纳入参考范围，这关乎到这个应聘者最后能不能加入到这个公司里。

1. 大胆的提出问题　有些新的程序员在进入公司的第一天很犹豫是否要去向别人寻求帮助，比如：当程序员在项目环境设定上遇到问题或者是他们不明白这个项目的商业流程的时候，他们很犹豫，不知道该不该问出这个问题。其实这都不是什么大的问题——尽管寻求帮助，或是向别人澄清一下你的想法。否则的话将会在和项目有关的问题上纠结、浪费时间。还有一种情况就是，当领导让你自己提出根本没有任何限制的问题的时候，很多程序员对自己的口才很吝啬。千万不要害怕问问题，尤其是在大的环境下。2. 找准自己的定位　在很多项目或者项目模块里缺少资源，这就意味着在你开始工作的时候或是完成目前项目的时候要让你的领导知道你的偏好项目和执行能力。许多人常常是喜欢加入一个新的有特色的项目，而有的人喜欢加入一个有熟人的开发团队。不过，最明智的选择是挑选一个没有多少同行的开发者知道的项目，只有你一个人在这方面擅长。只不过在刚开始的时候需要花大量的时间去了解熟悉它的运作模式和现有的代码；当一切事项都已掌握之后，就可以向管理层自我推荐，领先于别人，就是超越了自己。3. 熟悉App的“蓝图”现如今大多数的企业App都是比较复杂的，使用不同的技术完成的模块来组成的。作者展示了他现在的工作就是由3个部分组成的：一个和社交网络和收集数据互动的模块。一个处理收集的所有数据的模块。一个UI模块。　　每一个模块都是由不同的开发者团队开发并操控的。这些模块在技术上没有什么联系，但是在商业流程上是相互联系的，也就是说，无论什么时候想要引入一个新的功能的时候，都会影响到这3个模块。 事实上并没有多少人理解整个App的商业流程，当讨论一个新功能的时候，经理常常会要求在行的人对软件程序的更改最初最好的评估，评估结果可能会用在每一个模块里。所以如果你这道这个App蓝图的话，你就能参与到这个讨论中。4. 做你需要做的事，而不是做你喜欢的事　一些非常有才能的程序员经常会遇到很严重的问题——他们有自己的特别之处或者说是感兴趣的方向，一旦被要求去做其他的不一样的事情的时候，能力和做事质量就下降了。因为他们不能集中注意力在不感兴趣的事情上，这是很致命的短板。你如说：人们可能想要测试Scala，但必须先处理Hibernate或原生SQL；他们可能想要并发性，但是必须要协助与前端开发相关的工作。　如果你需要长期处理你自己根本不擅长的技术问题/工作，那么你最好换工作。否则如果你是临时帮助别人处理你不擅长的问题，最好表现的专业一点，把事情做好。5. 善于分享，乐于帮助     估计很少有人单枪匹马的情况下还能有很高的产量吧，这只能暗示在交流上的贫乏。自私是团队合作的最大障碍，最后也只能是整个团队停滞不前的结果。这样的“孤狼”也基本上得不到团队的信任。此外，如果你在一个区域办事处工作，而你的同事没有把任务做好，你最好去帮助他，因为团队荣誉至关重要，这也是一个双赢的决策。6. 尽量给出现实的评估给出太乐观的评估对于程序员来说是比较困难的，作者站在自己的立场给出两大主要原因：A. 我们经常忽略将要花费的时间：在实施阶段处理预料之外的问题。在开发环境上测试实现的功能。编写单元测试和集成测试。分散时间和精力到其他高优先级任务上。B. 有时在给出真正的评估之后会让我们觉得不舒服，因为经理看到这样的评估之后表情会很吓人。在这种情况下，我们通常会把特点划分成几个子任务，以至于总的评估看起来不是那么可怕。太乐观的评估在大多数情况下会有悲惨的结局： 你必须把任务移到QA在一个buggy状态下，通过思考来证明它：“通常QA会返回所有开发功能列表的备注资料给开发人员，所以我仍然会有机会解决所有的bug”。但是在现实的评估条件下情况就不会是这个样子了。
7. 测试，测试，再测试！      许多程序员因为错误评估而被迫转入QA环节，有些程序员在交货期来临之前停止了任务，转入测试阶段，只是想证明他们的高效能。当然了，这是一个好的意图，但是并不似所有的掉头检查都能带来好的结果。总之，中途检查要比从头开始好得多。再次强调一下单元测试和集成测试的重要性。它们是回归分析的第一个指标：一个打破现有功能的机会。不幸的是,有些人编写测试只有一个目的——避免漏掉代码覆盖率而带来的责任。这样的代码在代码审查过程中需要被捕获并拒绝，这是提高代码质量的另一个好方法。8. 记住：谁都会犯错误的。有谁希望和一个出现bug就喜欢批评别人的的人一起工作呢？估计没人愿意，但事实是我们大多数人看起来就是那个样子，只是自己没意识到。下面列举了一些避免出现这些状况的建议：如果你和同事一起构建一些功能，而他有稍微慢了一些，与其去责怪他还不如去帮助他，至少应该到经理那去争取更多的时间。既然需要共同的按时交付产品，那么两个人对这项功能的完成都是有责任的。       当你修复了一个bug或者是发现了一个bug，即使你知道是谁的缘故导致这些bug的出现，也没必要通过网络电话渠道让公司里的每个人都知道这件事。犯错误是在所难免的，有的时候你会遇到“ugly code”模块，同上，不需要让更多的人知道它的制造者。 如果你对一个同事有什么不好的意见，都没必要向你的上级反映，除非上级向你询问。首先你要确保你的上级是一个开明人士——知晓他所管理的团队里队员的强项和弱项，这样才能处理好队员之间需求。     恰恰相反，我们应该经量多的向大家包括领导反映同事做的一些好事。比如，数周之前我的一个同事在早上7点钟的时候临时驾车到公司来试运行App模块，所以他应该得到大家的赞美之词。
9. 在社交网站上宣传公司的强项。现如今，基本上每个程序员都在使用社交工具。你可以关注朋友们的公司，也可以在网上介绍自己所在公司，不管是好事还是坏事，都可以在网上贴出来：有的时候会组织技术峰会、赞助商会议、商业论坛、发布会、寻找新的开发者等等，社交工具对于一个程序员来说是有很大的用处的。除此之外，有很多的网站上都有公司人员对公司的评论，任何人都可以写，当然，只要是你喜欢的内容，没必要撒谎。在国外，想要和公司CTO或者是CEO进行交流的最简单的方式是通过Twitter，在国内可使用的交流工具也是各种各样啊！10. 小建议和小技巧。　接下来的是一些能够让你获得领导或者同事的赞美的建议和技巧：　A. 适应老板的时区许多来自欧洲和印度的程序员都是从美国那边接受发自总部的指令的。在这种情况下，如果程序员能够在晚上的时间段和美国总部进行交流讨论工作上的事情，肯定比在下午5点钟下班时候和总部进行交流所获得的工作效率要高得多。B. 如果有需要，任何时候都要帮助公司做事。       身边的例子：公司的生产系统需要全天候的监视着，因为任何时候都有可能出现问题。通常情况下是区域的程序员参与监视，但是去年的新年假期期间我们被要求留下来值班，我被安排在大年三十那天，我本来可以要求调整一下的，但是我服从了公司的安排，很幸运，那一晚上基本上没什么问题出现，我在一个很正常的环境下度过了我的新年，但是至少公司知道我随时愿意为公司付出。　C. 在公司的指引下参加应聘面试     如果你有机会以面试官的身份参加面试，一定要好好利用这一机会，因为这是无价的经验。首先，这能发挥出你的口才能力，很多程序员都缺乏这样的技能。其次，你可以认真听一听别的面试官（你的同事）都问了哪些问题。最后，你对求职者的观点将会纳入参考范围，这关乎到这个应聘者最后能不能加入到这个公司里。