1.前言

本文的主旨是列内部培训的提纲，特别对培训他人和写作技巧写得细一些，让大家明白很多东西可以培训和怎么传播知识。
虽然题为培训，但我还是想说一句：程序员其实不需要培训，只需要指点。原因有三：

程序员的工作都必须去实践，几乎没有纯理论的领域。
由于互联网的开放性，程序员能找到大量的资源自学。
随着实践深入，会自然地遇到一些问题。解决这些问题除了靠智力外，大部分只需要知道答案的大致方位就能用时间来消灭掉。

大牛之所以能成为大牛，就是知道了很多答案存在的地方以及发现这些地方的方法。优秀的程序员培训师懂得教方法而不仅是教答案。可惜很多培训师不是这样的，公司内部的培训流于形式，大家听完后就知道这是个很牛b的技术，却不知道怎么令自己也牛b起来。
HR就算懂上面的道理，他们因为知识领域的差异也从根本上没能力推动发展程序员的内部培训。HR能做的事是帮助管理者在程序员心中培养技术为尊的意识，让他们有动力去自学并实践，并以公司内某位榜样为目标赶超他。
HR难以发起大活动，也令大多数公司很少重视培训（培训 != 交流，请留意第3节）。因为即使不培训也不会影响赚钱，工作效率的低下可以用加班来弥补。而且项目做到一定程度就会更新换代、推倒重来，原本写得多烂的代码都成过眼云烟。还有就是老员工们都有自己的习惯，较难通过培训来改变，基本都需要有人经常提醒。
在实际中有时候还是需要培训的，这其中多数是因为负责人懒得写文档，或者文档很容易过时而懒得更新，不如口头说一遍算了，╮(╯▽╰)╭。

2.业务技术培训

按内容区分，培训可分为业务技术培训和软技能培训，还有HR组织的集训。

大家对技术培训的第一反应都是PPT式会议，因为这种形式多，而且也是最最初级的培训。
PPT最大的意义在于做报告，内容凝练而简略，所以受众是没法得到很多的信息的。但是这并不等于没用。PPT式会议和网上的视频教程一样，能帮助零基础的人快速入门。这里需要解释一下何谓零基础，是指对这门知识几乎没接触过，但已有相近的知识。例如已知C学C++或已知C++学Java，也就是说，至少不用在培训中解释何谓关键字或者面向对象。连相近知识也没有的人，应该叫负基础，他们会连PPT式会议都听不懂，还是得回归书本。
书本不仅适合负基础的人，也适合高级读者。因为看书有时间细想琢磨，有助于吸收。专家级则是阅读各种SDK和API文档。大神级的就是看各类源代码看出神的了。

搜遍各种书籍和互联网都找不到的东西，才是真正有意义做培训的，多数跟本公司密切关联：

产品的整体架构、设计思路、业务逻辑，迭代历史等
各类工具/系统（IDE、需求、项目管理、测试与bug、文档等）的使用技巧
解bug、做优化等的经验
工作流程和制度
本部门的知识体系梳理。直接用例子说明是什么吧，请点击《iOS开发知识与能力体系思维导图》。文章很久没更新，但能说明问题了，相信不做iOS的也能get√到。

掌握技术知识需要花很多时间思考并经过实践，通过培训来达到目的的性价比很低，只有其中牵涉到工作业务的部分能带来实效。换句话说，“如何把技术应用到业务中”是公司内部培训要解决的核心问题，而实现业务所需要的“技术”本身，应该让大家边自学边实践。

能让受众最大程度吸收的培训形式应该是手把手地教，这个贯穿在设计和编码过程中。本人实践过，发现被培训的人确实能完整地吸收，而且时间长了他会有反馈并跟你讨论，你可能在讨论中反过来也学到东西。当然，这个很少发生在互联网公司里，大家都很忙碌。

3.软技能培训

相对于编程能力、设计能力这些程序员的硬性要求，其它能辅助工作的技能都算软技能。
大家能思考出这部分内容的意义吗？答案我写在最后吧。下面这些都是可培训的。

3.1高效会议

这一节放到前面很重要，因为不少人搞不清几种会议的差别。会议的主持人或主讲人对会议的高效性负有最大责任，如果都用同一种思路来召开，会议就变得没什么效果。IT界“尊崇”的会议是乔布斯的苹果发布会和各种技术大会上的交流演讲，可惜这些并不是公司内部会议的榜样，很多人找错了模仿对象。

会议类型	用途	特点和要求
发布会	展示新产品、新战略	算是一种表演，要声色俱全，多媒体设备只是一种道具。目的是引起轰动，传播的内容要能煽动观众的情绪，不断制造高潮。
交流	传播自己或本公司的经验（技术大会属于这个性质）	展示个人、团队或公司的优秀技术或成果，间接地卖广告。讲授的内容具有高度概括性，不会讲细节。不会很在意观众是否都听懂，甚至怕泄密而有所保留
培训	传播知识，提高工作效率	引导观众记忆和会后探索，目标是让观众最大程度地记住传授内容
宣讲会	传达信息或做动员	观众可能是被要求来听的，这在本质上是一种命令，所以不用在意讲得怎么样
评审	对方案的评审	主持人讲述自己的方案，观众提出意见和建议对方案的描述要尽可能地细致，目的是让观众都理解后能发现问题，减少实施过程中的返工
总结	成果展示、述职	为了提高绩效评级，在符合事实的前提下，能怎么吹就怎么吹，你懂的
研讨	讨论、头脑风暴	没有主讲人，而要有主持人。非主持人都可以随意发言，有专人做会议记录。主持人的最大职责是引导讨论有序进行且不偏离主题，并减少争论以至形成共识。
例会（日/周）	日常的信息交换	每个人都可发言，要尽量简短。发言内容只需在场有另外一个人听懂。产生的问题会后再由各关联者自行讨论，不占用所有人时间

*请留意交流和培训的差异。

在日常工作中，一个会议的性质可能会包含以上多种，主持人需要在不同的阶段完成不同的职责。特别是主持人也是作为主讲人的时候，应该留意场景的切换，如培训完毕后的问答阶段。一般来说主持人都需要做到这几点：

宣讲会议议程或子主题，让参会人做好准备配合
尽量使会议达成目标。如果没达成，商定后续的安排，可再开一次
按时开始，不超时结束
帮助观众理解发言人（包括自己）的讲话内容
提醒其他发言人注意时间、语气等。不要因为一个人而耽误了全部人的时间
确保重要的人员都到齐
引导会议中的讨论达成一致意见
记录重要的发言和待跟进事项

3.2培训他人

好的程序员不一定是好的培训师，但好的架构师一定是合格的培训师，因为架构师必须向他人传达自己的思想，那恰是培训的意义所在。
做培训的首要目标是让观众完全吸收你所讲的内容，当然这很难做到，但做得到让人吸收大部分的也太少了。这是令多数公司不重视培训的重要原因，但也不能完全怪讲师，因为好的培训是需要花费大量时间和精力的。如果不是专门设立培训师岗位或者把培训职责写入KPI，没有几个人会对把培训做到极致。交流演讲和培训的侧重点不同，不能说哪个的要求更高，但如果把交流的意义上升到代表团队和公司，那应该更重视。看看需要做多少功夫才能做好吧：

会前准备：

观察和调查你的听众的特点，例如数量、知识与技能基础、职位、工作内容、最感兴趣领域等。培训内容和手法应根据这些特点做调整，假如向Java工程师培训C++，就可以多用Java的术语来介绍C++。
冥想和模拟训练。在脑子里演练完整个培训过程，或者找个地方（培训现场最佳）对着空气讲。这能减小忘词的概率和减轻现场讲演的紧张感，还能发现培训逻辑的疏漏。如果还不够，可以先让少部分人来听，然后再面向全体。
如果怕会上遗漏一些事项没说，应准备一张小纸写上给自己做提醒的话语。非庄重场合写在手机里也行。
PPT的制作技巧，很多书可参考，不赘述了。特别提醒，如果确认这是一个培训而不是一个交流演讲，PPT上的字不应该追求简略，特别是重要到需要观众记忆或记笔记的内容（也可能把PPT交给他们）。甚至可以考虑用Word或网页而不是PPT。
如果要讲到代码，不应该只用PPT。可以直接打开编辑器对着代码讲。在PPT里贴大段代码的都是耍流氓，因为代码占用的篇幅大，而且信息量较多，很难短时间理解透。（这时候技术培训不如文档，但现实往往是相反的，本质原因是文档的糟糕。读者看不下去而希望能面授，集体的诉求自然转变成现场培训。）
如果需要演示操作或有多个培训材料，应提前打开所需的软件，并令其状态准备至一切换窗口过来就能讲（例如滚动条位置都拖好），不要在会议上花费这样的时间，因为一群人在等你。
发邮件提醒培训的适用人群。如有需要，提醒参会者提前阅读一些基础知识。
保证自己在培训过程精力充沛。为此，喝茶、喝咖啡、做几个俯卧撑什么的都行，用你喜欢的方式。
选择观众注意力容易集中的时间段。不饿，不困，不忙等。
选择好的场地，帮助观众集中注意力。不吵、无异味、气温适中（空调设好）、座位密度适中等。座位密度：太疏容易分心走神或听不见就玩手机去了；太密会被旁人影响；一个判断标准可以是侧头不侧身地看，刚好看不清人家微信里的字。
培训内容的准备。思考如果你是观众，你最希望听到什么内容。培训的思路可参考下节“写作”。
其实，你的发型和服装都会影响培训效果，不信你cosplay来试试。

进行时：

帮助观众保持注意力集中：
- 如果讲授的内容很繁重，可尝试分节，每节40分钟左右，中间休息10分钟。是的，培训的本质是上课。
- 多微笑，声音洪亮。在旁人眼中，此刻的你应该比平常状态更兴奋和活跃。自己表现得越投入，观众就会越认真听，否则会变成一场催眠大会。
- 提到他的名字，让他的注意力集中回来，或让他有更多的参与感。比如“某某肯定也是这样想的”，“某某曾经说（问）过”，“这样就能解决某某的问题了”。
- 注意自己的姿势、手势，可用来引导观众的目光位置，但不要动作夸张到吸引走了注意力。如果一直拿着鼠标，记得不要乱动，观众的眼睛会跟着光标走。
- 开始讲述的内容可以不怎么重要，例如做自我介绍或描述一些东西辅助今天培训的主题，帮助观众慢慢进入状态。
演讲的技巧：
- 克服和利用紧张与恐惧。要理解这是人的天性，被很多人围观而自然产生的防御心理，实际上这能帮助你更集中注意力做好培训。
  克服它们的方法有自我暗示（用特定的话语激励自己，想象过往成功的演讲，想象这只是普通的例会等）、深呼吸、转移注意力（喝口水，摆弄一下其他物品，跟别人说说话等）等。
  事实上无论你犯多大的错，观众过几天就淡忘了。
- 不能用提问来考验人，更确切来说不能令被提问者尴尬而导致冷场，别学学校老师那套。提问可用于：现场调查，证明结论；开放式的，没有正确答案；让观众猜测，活跃气氛。
- 重复以强调。讲完例子或论据后重复一遍观点，加深观众的印象。或者更直接地，“这个很重要，我再重复一遍”。
- 不跑题。我就见过“我如何当好技术leader”这个主题花了三成时间讲“我如何当上技术leader”的人。
- 让观众跟上你的节奏。“承上启下，伏笔，呼应”这些写作技巧，在演讲中表现为“前面我们讲的都是理论，下面我们看看如何应用”、“这点我们后面会有详细描述”、“我们前面讲到的XXX在这里就是最典型的应用”。
- 适当的停顿。如果需要观众思考、消化理解，不妨直接说“给大家15秒时间思考一下”，就这样沉默着。
- 幽默。注意幽默是为了加深记忆服务的，不要最终变成展示个人魅力。“如何制造幽默效果”这个话题很大，不展开了，建议找书看。幽默感需要刻意地积累，而且要恰到好处地用在演讲上是需要锻炼的。
- 说服。最佳方式是列举好处，以利诱导，而不是把规矩硬塞入别人的思想。更厉害的方法是洗脑，这个也是可以找书看哦。
- 要会讲故事，在故事中蕴含你观点。故事的形式比理论好。
- 生动，运用打比方和对比、反比。观众一时难以理解你所描述的内容时，可以换一种角度来说。比如向不懂编程的家人解释架构设计是做什么，“就好比设计一辆汽车，要做到零件可拆卸组装（模块化），多个厂家都能帮助生产零件（可扩展性强），开起来省油又马力足（性能高）……”
控制会场的一切：
- 利用好你的权力。无论发生什么影响会议进程的事情，如何处理都以你的决策为主。即使你的上司在场也请记住，这个时候你最大。
- 准备面对意外。比如投影仪或麦克风坏了你也能继续做培训；有人问你答不出的问题，你可以找后援团来回答或说会后私聊。
- 现场环境的使用。麦克风音量、笔记本电脑、灯光、投影仪、座位摆放、提词板、遥控器、激光笔、白板等。

会后：

收集反馈。提醒大家可以随意批评这次培训中做得不好的地方。
注意受众的当场反应。
观察受众的会后行为，是否有受你的培训影响而有所改变等

3.3写作

这里特指撰写技术文档和报告，其它文档都比这个的要求低。
写作是很多程序员的弱项，除了表达能力基本功缺乏锻炼外，最主要是忽略了文档的作用是给别人看的，不是给自己看的，无论内容多么有意义也得保证用户平均停留时间和留存率。这恰恰是产品经理熟悉的领域，好的文档也是追求用户体验的，所以想锻炼写作的话不妨用一下这个偏方——找产品设计方面的书看看。举个更形象的例子，电商网站（如淘宝）上的宝贝页面也算一个文档，你是怎么被吸引或引导去付费呢？当然，最好的模仿对象应该是Windows/iOS/Android的系统SDK文档。
培训和写作有部分技巧是相通的，这里不再重复。

保证读者有耐心从头到尾看完：

读起来通顺，有一定的节奏感（长短句排布适中，合理使用标点符号断句；不是指押韵，但读起来会有一点点韵律感）。
有条理，有过渡，同级的子主题之间不跳跃
由浅入深，不会突然遇到理解障碍。想想C++/C#/Java书籍的目录？
选择不花眼、不太小的字体，排版好看，不凌乱
如果是web文档，要注意让读者不需要点击太多链接，必要时自己总结链接文档的内容。
一张图片内不要信息量太大。尺寸不要过大致无法一页看完，或作适当分割；Web文档的大图要做成竖型，不要产生横向滚动条。

保证“傻瓜”也能看懂：

朴实。不要用口语，不要带非群众性的幽默甚至没有，这不是在写演讲稿，也不要写成内心独白。
别卖弄知识和文采，也不要用偏门词汇和方言，会影响部分人的理解。比如有多少人知道银弹（silver builet）或者“抛书包”的意思？考考你粤语：撞板、撞彩。
抽象或模糊的概念和观点有示例做进一步说明。（很可惜，本文因时间关系没做到，那能写成一本书了）
考虑读者可能不具备一些基础知识而看不懂，要么在文章开头写明阅读基础，要么在文中加注释阐述。
没有歧义。比如一个新闻标题叫“中国过早拆房1年浪费数千亿”，这里可以有三种歧义：“过早1年拆房，浪费数千亿”、“过早拆房，这一年浪费数千亿“、”过早拆房，每一年浪费数千亿“。改成这样就没歧义了：“中国过早拆房每年浪费数千亿”。
一个概念从头到尾都用同一个词，不要同时使用同义词或近义词，并且应选择读者惯用的那个。例如：
1. “闪退”和“崩溃”都代表程序非正常退出，前者是用户用语，后者是程序员用语（即Crash），但不是所有程序员都听过“闪退”。当写文档给程序员看时，应始终用“崩溃”这个词，如果用了“闪退”，也许会有人问你“闪退”是什么意思。
2. Singleton有翻译成单例或单件，应该统一只用其中一个翻译，或者全篇直接就用英文单词。
3. 更常见的情况是，某个业务名称在这个部门叫AAA，在另一个部门叫BBB，写给哪个部门看的，就应该只用那个部门的惯用语。

专业性，保证处女座不会看疯：

简洁凝练，不要废话连篇。用最短的话说清楚问题。在技术领域，还可多用专业词汇来减少长篇描述，比如用“外观模式”代替“新增一个类统一封装这个模块的所有接口，对外屏蔽这个模块的复杂逻辑”。
更高要求的简洁是在语文层面的，这方面的能力很多人在大学毕业就固定下来了，故不想多言，有兴趣请百度。
精简掉冗余信息，不是必要的信息不写或简写或写在末尾，减少读者耗费的时间成本。
关键的信息处不能有错别字。英文单词拼写也是哦，特别是时态、名词还是形容词。
严谨，严密，有逻辑。不断论证，有理有据，不留疑问，无懈可击

技术文档会被多次查看，保证后续的阅读能迅速找到最可能感兴趣的点：

请注意很多制作PPT的技巧不适用于写文档，两者的用途分别是单次展示概貌和多次查看细节，相差甚远。例如不能盲目地执行“能画图的画图，能用表格的用表格”，有时候图表不是描述细节的最佳方法。
能从几个维度方便查找。可参考论文、书籍的写法，有目录、摘要、关键字、前言、章节、参考文献等。
重点的地方可改变字体（颜色、粗细、大小、字形等）
按查看频率排章节。某些文档会把思考和论证过程写上去，最后写结论。这也意味着别人查看的时候，鼠标得滚好远，这时可考虑把结论放前面。
合理地分章节。这里要很多例子才能帮助理解，时间关系只能讲一个。假如文档的主要内容是“在Windows、Mac OS、Linux下如何使用线程和进程”，那么：
如果为了方便查找各操作系统下怎么使用，各节的标题应该是“Windows下的使用”、“Mac OS下的使用”、“Linux下的使用”，每节都是描述此操作系统下线程和进程的API；
如果为了方便查找线程和进程的使用分别在不同系统有什么差异，那么各节的标题应该是“线程”、“进程”，每节都是同时列举三个操作系统下的API。
内容多到一定程度，应分多篇文档。和上一点一样，同样有技巧。比如写Windows SDK的使用，可分为“初级篇、中级篇，高级篇”，每篇都可能讲到绘图框架，但难度不同；也可分为“……，I/O，绘图，网络……”，把所有的绘图框架知识写到同一章。具体的应根据目标读者的需求来划分。
如果更新频率较高或是多人合作，能不用画图的尽量不画，或用文本型图（点我看示例）。这样方便维护，无需额外的软件就能编辑；文本型图还有个好处是可以Find和复制其中的部分内容。
利用好Web文档的便捷性——超链接
链接的目标网页如果不是最上面，应直接链接到锚点，不需要别人再拖动滚动条。
链接过去的文档如果内容很多，一下子找不到你引用的信息，应该自己总结一下或复制核心的内容过来

如何具备写好文档的能力？多练，以及总结你看到的优秀文章的特点。
不过除非是写用户手册（说明书）的文档工程师，很少有公司对程序员有这方面的要求，或者说国内还没到这个境界。

3.4沟通交流

在团队合作中总会遇到冲突，优良的沟通技巧能和谐掉很多不愉快的事情。

对事不对人，不要对人进行评论。即使对方知道你的原则，也可以是事先再说一遍“我是对事不对人的”。讨论对方做得不好的地方时，应设法降低这种讨论的不良影响，尽量去除对方警戒心以避免升级为冲突。
人多的场合，赞扬可点名，指出错误需匿名。
幽默。它可以化解很多的问题。
措辞。这个最好是向国家机关的发言人学习，但也不要太官腔。举个例子，“不够好”比“比较差”更少一点攻击性。
随时敢于承认自己的错误，可以解释，但不要用来推翻你犯错的事实。这个年代，“我错了”、“你赢了”都成了幽默词汇，还怕什么多说几句。
微笑。不建议伪装地笑，应发自内心。如果做不到，不严肃即可。
理清概念，避免歧义。如果对话中有无法理解的词语，要问清楚什么意思，不要不懂装懂。
请教别人问题时，先说明你的目的再讲述细节，让别人带着问题去听细节，他会自然地筛选其中的重要信息。常用句式：“我想干嘛干嘛，现在的情况是这样这样，我该怎么做或你有什么意见”。
不轻易打断别人，尊重发言欲。如果不赶时间，即使对方讲的话没意义也等他讲完吧，至少在别人停顿稍长的时候再插入而不要显得突兀。
抓住重点。简单的事情不要用一大段话来说。当别人说了一大段无关紧要的话时，你可以用自己的话概况一遍请对方确认是不是这个意思。
精确传递信息，不要误传误报。
用打比方或过往事例来帮助别人理解你的话。比如向外行人解释“终于把bug解掉了的感觉”，就像“肚子疼时终于坐到了马桶上”。（哈，相信你会有更好的描述）
转折话题时做好过渡，别人未必能反应过来，以为你还要争论。很经常用到的一句是：“这部分是对的，还有一个问题是……”
控制好自己和他人的情绪，也就是情商的锻炼。实际的锻炼过程是需要经常反思的，没有一个理论能帮助你应对所有状况。

3.5敏捷教练

无论敏捷开发究竟有没有用，至少很多公司在学习和推广。Scrum Master是有认证体系的，可以派人去参加外训拿个证书，然后回公司推广。各种理论就不在此展开了，请百度。
补充一个点，教练的人选也很重要。最好是原本就在团队内，但不是团队leader，并且leader有当众声明教练的权责。这恐怕算是中国特色了。原因：

如果leader是教练，那么大家都当是命令，会产生抵触心理，也不敢乱提反对意见，达成不了自组织状态
如果教练是外来的，碍于情面，很多改革难以指正执行
如果教练没有足够的权力（至少能合理地否决leader的意见），那会是个吃力不讨好的工作。想纯靠精神宣导，那是痴人说梦。

3.6行为规范/职业素养

HR领域的正直、不干违法事情这类东西就摆一边去吧。技术领域的也不提了，比如遵守代码规范，多写注释方便Review和维护之类的。这里说的是：

做有利于团队合作的选择，但如果自己有牺牲也要表现出来。最简单的例子：如果你的工作是团队另一个紧急任务的前提，免费加班也先搞好。
忠于自己的专业眼光，不轻易妥协，也不做消极对抗。例如，如果认定这样某段代码会有风险，在未验证前不同意发布产品。
承诺的时间点都按时按质完成。
传递前辈对你的帮助，激励后辈的成长。
坚持学习。本文应该也有引导作用，除了学技术，还有很多可学呢。
多观察别人是怎么做的，多自己解决问题，不问低级问题
敢于承担责任，不推诿

拥有的知识和技能越多，表现出来的素养应该越高，不再投机取巧。

3.7时间管理

“番茄工作法”和“四象限法则（重要&&紧急）”这两个理论应该比较多人听过。但如何正确运用在日常工作中恐怕很多人没头绪。这也就是培训的重点，应结合实际工作举例。这个领域的学问也挺多，鼓励多看书。

3.8事务推进与思考

即使你不是leader，当由你牵头某个事务时就需要应用一些管理方法。举几个例子，不解释了，请点击链接：

还有很多，微博里到处都有转发，或者找些公众号关注下吧。
知道这些理论还不够，要自己思考如何运用到实际工作中。只举一个例子，破窗效应：如果一个人不遵守代码规范而你又不要求他改正，其他人看到就会松懈、模仿、复制粘贴，最后很多人都不遵守规范了。

3.9职业规划

这种培训少数公司才有，因为懂得越多，越会跟HR作对。呵，心大了就想升职或跳槽了。
问题大概有这些：

选什么岗位，要不要转岗。开发、测试、产品经理、管理类等。
选什么行业。传统软件型、硬件厂商、互联网、非IT业的IT部门等。
选什么技术。前端、后台、移动开发、硬件……
选什么类型的公司。外企、创业企业、国企等。
选哪类城市。北上广深还是二三线？
跳槽的时机。

公司组织的培训一般都是某些英雄人物讲自己在本公司的成长经历，因为有很多限制，效果一般不佳，例如要避免炫耀的嫌疑，不能说得很细。而且可以说这可能是特殊情况，套在自己身上不合适。所以基本上都需要多听几个人的演讲，由观众自己找出相似的点，这些点比较可能不是个案。
个人自学的话也差不多，多看些职业规划的理论、名人传记、网上写个人经历的文章（如《非计算机类专业毕业生五年程序员职业生涯的回顾和思考》）等。先广泛收集，再从中挑选拼凑出合适的。也可以做做网上免费的职业评测。

3.10外面的世界

程序员可以终身都在学习，即使不跳槽，也要了解外面的变化，最起码要知道同行的情况。培训这些东西的最大作用自然是激励员工。可是要得到这些信息并不容易，因为有可能涉及商业机密。渠道还是有的：网络或技术大会的分享、第三方咨询机构、社交、挖角过来等。
也可分享下外国本土公司的特点，虽然能照搬过来的东西不多，但能借鉴的也是有的。例如：开发活动的形式本身也在进化，不仅仅是人在追求最大效益；英雄主义的竞争文化，崇尚以一敌百的能力。

题外话：培训自己

软技能都不会给公司带来直接明显的收益，所以大多数公司不会重视培训这些。实际上，软技能可以加倍工作效率，公司和个人是双赢的。就算公司不重视，自己一定要重视，没人培训你，那就自己培训自己。如果技术水平相当、资历相近的两个人选哪个当官，那自然是选和领导最亲近的。哈，你觉得和领导亲近不是靠软技能在发挥作用？
软件工程的概念是借鉴工业工程的，程序员要发展也可以从很多其它行业获取知识。就像编程能力之于程序员，以上每一种软技能都是某一种职业的核心技能。也许你无法和很多不同职业的人交朋友，但你能买到所有职业的专业书，这年头真的连如何当乞丐的教程都有。不要等着老师教你，推荐看看HR、管理学、心理学、销售、演艺、人物传记、科普、旅游、艺术设计等领域的书籍。
还有就是，锻炼好身体，革命的本钱嘛。

补充

《程序员内部培训与个人发展杂谈》是本文的补充。参见http://blog.csdn.net/hursing/article/details/75313637

如何优化程序员的内部培训