1.“博”和“专”中丢失的假设说的是一个人的学习有了重点，学习的内容和他实际参与的项目是一致的，那么就没有问题了吗？不幸的是，答案仍然是否定的。在任何一个子领域，仍然需要进一步考虑“博”与“临”的平衡。对于软件开发来说，设计是一个非常普通和简单的词。但是，如果把眼光放高一点，就会发现单单是设计，还是一个取之不尽、用之不竭的领域。我们可以快速扫描一些与设计相关的概念：（1）面向对象分析与设计（2）结构分析与设计（3）模型驱动开发（4）契约式编程（5）面向切面开发（6）组件-baseddevelopment(7)Metaprogramming设计中有时也涉及到方法论：(1)测试驱动开发(2)敏捷软件开发如果你觉得这还不够，可以查看Wiki上编程范式（paradigms）的词条。那里列出了47种范式，每一种都与设计有关。以上只是关于设计。如果横向展开，必然涉及到特定领域的框架选择、辅助工具的使用等。这也意味着，在薄波看来，即使是在设计这样一个看似狭窄的领域，依然是没有界限的。同时，把一个API研究透彻也是一个低价值的群体，因为这种深入的理解，从价值创造的角度来看，和单纯使用某个API的角度没有太大区别。这也意味着，对于大多数软件开发者来说，需要在广泛性和专业性之间找到平衡点：既不能闭上眼睛，也不能只用显微镜看世界。这个平衡点的值可以用反木桶原理来解释：木桶原理是说木桶里的水是由最短的木板决定的，但是在考虑人的价值时适用反木桶原理。也就是说，一个人的价值，往往是由最长的棋盘决定的。博合转的问题离不开产品研发。如前所述，产品开发往往与公司的现金流联系更紧密，能够为现金流做出贡献的技术就是有价值的技术。事实上，产品开发本身就对博文程度和专业知识提出了最基本的要求，而这种要求往往具有迭代的特点。为了形象地说明这一点，这里举一个通用的例子来说明：在第一次迭代中，往往需要实现两个基本目标。首要目标是能够为产品做出贡献，但是代码质量一般。如果达不到这个目标，一个人就会失去自己的存在价值。这时候你至少需要会某种语言（如：C++）、某种平台（如：Windows）、某种IDE（如：VisualStudio）和一些业务相关的知识（如：打印系统）。这个范围可以越小越好，但是你必须学会??如何使用它。比如：无论接触哪个框架，都必须了解它的内存机制、线程机制、异常处理组件构建、国际化处理等全局机制，而不仅仅是如何使用某个接口。这个要求不是很高，没有这些就成了“靠运气编程”，写完程序还得祈祷他能跑起来。了解了这些，你就可以承担一部分的开发工作，否则只能做一个旁观者，无法参与到实际的工作中。第二个目标是把事情做好，并且能够负担得起一些更高层次的工作。这时候就需要对面向对象、结构化方法、设计模式有更深入的了解，理解设计原则，并能够很好地运用它们。至少要能够判断这个程序写得好那个程序写得不好，同时在需求面前能够继续工作。前两个目标是基础。一般来说，在学校的基础越好，这个阶段就越短。这两个基本目标达成后，再结合情况做进一步的选择。可以认为这是博和专业选择的第二次迭代。当然，这个时候，我们也要切记不要脱离修行。完成以上两个层次后，有两个方向可以选择：（1）可以进一步考虑专业化的问题，比如在特定领域加深知识。如果你是司机，你必须了解操作系统的核心机制，如果你是打印机，你必须了解页面描述语言等，但这个时候，你要适当警惕边际效应。边际效应是指你可能只需要投入100元，一亩地的产量就可以从500斤提高到1000斤；产量从1000提高到1500可能需要200元；400元。一个典型的例子就是C++的学习。C++被认为是复杂的。如果你想成为一名C++律师，10年后你可能会获得资格。但问题是，如果把所有的时间都花在这上面，投入产出比未必好。正确的停靠点是一个规模问题。一般来说是细节问题，可以用时间弥补，不适合专精到最底层。比如一个100万行的程序，提前花时间了解每一个细节就有点过分了。(2)博客可以进一步进阶，比如：熟悉专业领域的专业知识，熟悉现有各种框架的特点，熟悉提高用户体验的关键点。熟悉各种现有框架的特点的具体含义是：在设计某个解决方案时，首先要考虑的是自己开发还是使用现有的模块。一旦决定使用现有模块（包、框架等），就该考虑使用哪一个了。在做这类工作的时候，如果没有一定的广博知识，选择起来就会特别困难。如果说公司要引进项目管理系统，做决定的负责人至少要考虑以下所有事情：（1）从头开始构建，还是使用现成的进行二次开发？(2)使用现成的、开源的产品，Microsoft或其他公司？（3）微软方面，是基于MSProject还是基于SharePoint，还是混合？考虑到授权费真的划算吗？(4)开源产品，那么多选择，我应该导入哪一个？(5)如果我从头开始构建，是基于微软的技术还是LAMP之类的技术？(6)使用什么框架？(7)如果你想做，你会用什么语言？一个人很难精通以上所有领域，但在做选择时，完全没有概念也是灾难性的。此外，在考虑博主和专家之间的平衡时似乎有一个特例。研究具体算法的人，一开始只往专科方向发展，不会考虑别人。举个例子：研究TTS的人可能只需要专注TTS几十年。至于选择哪个方向，就看你自己的情况了。总的原则是以当前的工作为基础，选择各种知识为实际所用，追求一个平衡点。一般来说，期望成为技术专家的人更适合前一个方向，而期望成为技术经理的人更适合后一个方向。学习软件工程的时机和必要性简单来说，越没有经验的人越不适合学习软件工程，越需要统筹全局，越需要学习软件工程.软件工程涵盖的要素非常复杂，包括管理、过程、开发模型、估算、分析和设计方法等，这无疑会把知识面扩展得非常广。一旦没有基础，就很容易成为空谈和豪言壮语。在众多与软件相关的知识中，软件工程绝对是非常特殊的一门。很多人鄙视软件工程，说：软件工程的书我一看到就跳过；相应的，很多人都非常推崇软件工程，会花很多时间去研究敏捷，CMMI等，刚进入职场的程序员一般都很讨厌软件工程，因为这个东西离自己实践有点远，而且它主要是添加约束。但既然规律可以在更复杂、更复杂的历史中总结出来，那么忽视软件发展的内在规律，对于立志成为管理者的人来说无疑是不利的。如果真想学软件工程，不适合从抽象层次高的教材入手，而是从《代码大全》这类贴近实际的书入手比较合适。看来，软件工程在中国的实施，一直都是举步维艰。与软件工程相关的术语不断变化（ISO、CMMI、Agile等），但真正能落地的却不多，最终导致一个悖论的局面：一对一个感到绝望，又开始期待一个新的，并对这两个简单的步骤进行无限循环。这种情况可能有更深层次的原因。例如，由于生存压力大，忽略了工程实力的长期价值，以至于方法论不是为解决实际问题而存在，而是为证书而存在。很难说软件工程一文不值。2.错过了生活中的美好时光还没毕业或者刚毕业的程序员往往觉得自己的空闲时间很充裕，心里还是很苦恼，不知道怎么打发时间，但其实一个人的生活中可用于充电的时间远比想象的少。一旦错失良机，往往后悔都来不及。对于大多数人来说，生活就像一个模板，小的地方有偏差，大的地方基本一致。20-30岁这个阶段可以说是黄金时期。这个阶段，家庭负担比较小，可以自由处置的时间比较多。当然，如果碰上非常特殊的公司，需要疯狂加班，那就只能单独算了。30岁以后，由于生娃等原因，花在家庭上的时间增加，个人可支配的时间减少。很大一部分可能还会面临电视剧中经常提到的婆媳矛盾，让你每天都心神不宁。40岁以后，家务活会进一步增加，通常是有长辈和晚辈之分。其实运气不好也会得一些病——颈椎病、腰椎间盘突出症、胃病大概可以选为程序员的三大职业病。50岁以后，时间又会自由，可惜我也老了，时间不在了。如果按照年龄把人生画成一条抛物线，一个人在40岁左右可以达到的人生巅峰，以后突破的概率就变小了。从历史人物来看，大器晚成者并非没有，但确实很少。仔细观察会发现，招聘启示往往会注明年龄必须在35岁或40岁以下，除非是高层招聘。这反过来意味着，如果你没有登顶，你的人生会在40岁之前定型，之后就会有下滑的风险（比如遇到经济衰退、公司倒闭等）。对于程序员来说，这个风险特别高，因为很可能你辛辛苦苦掌握的知识体系会被取代。学习本身无疑需要顺应这个自然规律。很多人犯的一个大错误就是，在黄金时代，他们只是享受生活，没有做任何积累，但一旦意识到积累的必要性，就会被许多琐事所困，感到虚弱，最终他们的生活得到了高度发展。有限，并迅速走低。这就是现代程序员版的“年轻人不努力，老板难过”。基本上，35岁之前，需要大量时间掌握硬技能，学习曲线陡峭的技能，具备工作所需的所有主要技能，而35岁之后，则着重于更新知识和一些软技能技巧。学习的时候加水的效率真的很低。每点燃一根火柴烧开水，一壶水1亿年也烧不开。同时，相对硬的技能（例如：DonaldKnuth的《计算机程序设计艺术》）往往需要大量的时间投入，但年纪越大，时间越碎片化，硬知识的获取就越难————天生就很容易创造出加水战术。对于更软的技能，可以利用碎片化的时间来学习，比如：提高PPT的制作水平，提高表达能力。如果你能安排好自己的时间和软硬知识的关系，那么你就可以在特定的基础上不断积累，一步一个脚印，让自己的价值越来越高。从这个角度来说，青春绝对是一种债，大部分人都必须在还清之前还清欠下的债。那么具体来说，那些比较难的事情，是不是应该在35岁之前做呢？这因目标而异，但以下几项应该是非常通用的：（1）精通一种最常用的语言（2）了解一种最常用的平台的基本机制，例如：内存管理，线程机制等(3))UML图和面向对象分析设计方法(4)设计原则，如：单一职责等(5)设计模式(6)《代码大全》中提到的一切(7)Intensive阅读一个著名的但有点规模化的程序。至此，我们要感谢开源项目为我们提供了这么多优秀的程序。但谨防野心太大，动辄挑战Linux内核，精读是关键。(8)积累一定的代码量，例如：独立完成一个东西，几万代码行。这里的关键是完全自己搭建，千万不能复制粘贴。（9）掌握基本的算法和数据结构（不一定要自己写，但至少要知道它们的复杂性和差异性）（10）养成清晰的编码风格（11）有自己的专业（金融、高等）-并发网站、图像处理、TTS等）学习英语的时机和必要性总的来说，程序员学习英语是一种投资，投资回报率比较高。从目标来看，程序员不一定非要英语口语流利，但至少要能无障碍阅读英文资料。这里有一件微妙的事情。一旦英语阅读问题比较大，就会习惯百度找问题，自然会限制一个人的视野。不是百度本身不好，而是英语世界有更多精彩的内容。不管我们喜不喜欢，我们都必须承认，英语是IT世界的世界语。一方面是因为美国公司的实力，另一方面是因为选择英文开源。这最终导致IT世界的新趋势，解决问题的技巧，网站架构等等，都得在英文世界里找到。在StackOverlow上很容易找到各种小问题的答案，在Quora上很容易找到各种网站的结构。从学习机会的角度来看，这件事应该在大学里做。如果没有，至少毕业后一到两年，必须达到阅读无障碍的水平。当然，如果你想加入外企，就需要额外付费。从学习方法上看，学外语真的没有什么特别的诀窍，只要坚持，投入时间。3、在程序员的增值方面，人生最大的陷阱可能就是被安全的假象所欺骗，让自己彻底放松。这种情况在生存环境比较恶劣的情况下不太可能发生，但在垄断企业或者在某一领域绝对领先的企业中很容易滋生。不难发现你是否停止了更新知识。比如一年不读一本书，一年不接触一点新知识，对一年中的工作量基本不满意，都可以是一个信号。这真是一只温水煮青蛙。一旦三十多岁，习惯了这个环境，想跳出来基本是不可能的。唯一能做的就是祈祷公司不要挂掉，公司不要来造势，进行人事大变动。曰：一日三省，甚为必要。至于知道危险后能不能做点什么，那是人的事。(1)技术人员的知识更新接触到一个新的岗位后，一般要经历一个学习、逐渐胜任的过程。在这段时间里，大多数人的学习热情都很高。一旦你基本上胜任了，事情就会改变。很多人可能觉得这种知识反正只是工作用的，没必要学其他的，于是开始封闭自己，不看书，不看科技新闻太多了。这其实是很危险的，因为这种做法无异于把自己和现在的工作绑在一起。而且任何产品都有自己的生命周期。一旦一个产品的生命周期结束，其中使用的技术恰好落伍了，当事人就会很尴尬。因为产品可以结束，但生活还得继续。一个非常经典的例子就是MFC。微软的产品历史非常悠久，从1992年发布到2012年已经存在了将近20年，随着90后程序员的逐渐涌现，这项技术很快就会比程序员更老。即使在今天，许多桌面应用程序仍然是基于MFC开发的，通过查看包的dll依赖项可以很容易地验证这一点。MFC是一个具有深度和历史的大池。弄清楚MFC的类继承关系、消息机制、框架结构、RTTI、序列化，还是需要一点时间的。现在我们假设一个庞大的企业应用程序是基于MFC开发的。一个程序员也通过几年的努力，了解了MFC和应用程序本身，能够承担起修正错误和增加新功能等任务。那么程序员好像没什么可学的了。因为MFC的更新几乎停滞了，学习MFC几乎不需要太多时间。现有的代码也整理出来了，不用花很多时间学习。现有的方案也比较符合企业的需求，几乎没有推倒重来的可能。这个时候程序员不需要学习吗？答案一定是否定的。这其中存在着巨大的矛盾。从企业的角度来说，必须要有一个团队来维护这个程序的开发。但从个人角度来说，如果所有的青春都花在旧技术上，那么一旦旧技术退出历史舞台，个人该怎么办？还是上面的例子，假设一个人继续投入这种类型的开发，当他45岁的时候，现在的产品生命周期结束了，这个世界就变成了只有移动开发和云开发，那么如果他要怎么办呢？只擅长MFC？如此一来，此人就会被逼到墙角，人生很可能会出现巨大的下滑。因此，我们千万不要认为我们所学的就足以停止更新和学习技能。从具体对策来看，一是参考知识地图，横向扩展知识广度。比如，不仅需要关注代码，还要了解业务；既要注重发展，又要注意一点估算；第二，更好的提高机动性对事物的掌握程度，比如：面向对象的分析和设计，这样当你跨到其他技术的时候，可以比较平稳的过渡。三是争取岗位轮换，争取多种实践机会。(2)更新管理者的知识到目前为止，大多数人都认为管理者需要懂技术。从逻辑上讲，“理解”基本上是不盲目指挥的前提，所以这堪称中国版的“临场论”，估计也没有太大争议。关键问题是我们应该“理解”到什么程度？如果有两个人，一个选择管理方向，一个选择技术方向。其次要求管理方向的人的技术水平和技术方向的一样，所以除非这个人特别有才华，否则不太可能。前面说了，这是两个方向的“Key”不同造成的。如果目标是确保最终产品的成功，并假设管理者拥有更高的决策权，那么管理者必须具备以下几个方面的技术意识。从做产品的角度来看，要想成功，有两个关键的维度需要同时把握。一是把握产品的概念完整性；另一种是使用适当的手段来实现产品。之前的话题很老了，《人月神话》也提到过，但在实践中总是忘记。好的产品必须执行某种统一的意志，而iPhone和微信又重新验证了这个古老的原则。虽然机械组装的产品融合了很多人的想法，但它们往往是平庸的，而且往往是项目执行过程中出错的根源。就像一个国家，虽然有法律，但每个人都有自己的理解，各司其职。这个概念的完整性是管理者首先要掌握的，其次是要解决产品怎么造的问题。为了达到这个目标，管理者必须在以下几个方面有自己的理解，至少有自己的原则：下面简单列出几个关键的考虑因素，与上面讨论的如何向博客方向发展类似有一个很少重叠：(1)使用现有产品或自行开发。例如：那些模块适合你处理，那些你可以买。采购时应遵循什么样的标准。(2)使用哪种平台技术例如：是使用微软技术还是开源技术。（3）目前的架构能否达到产品目标，如：硬件和软件同时支持的并发数。(4)如何约束代码的可维护性这需要熟练掌握一些原理性的东西，比如：什么是信息隐藏，正交分解，抽象是否充分。还有一些明确的指标，比如：圈复杂度，单元测试的收益平衡。(5)那些环节必须固化成过程，那些必须由团队自由决定，例如文档的范围，以及不同阶段之间必要的输入和输出是什么。……假设有人不这么认为，但在做了管理之后，表现出足够的惰性，不再不断更新自己的知识体系，那会怎样呢？这个时候，很可能会出现管理倒置。也就是说，管理者名义上是上级，但基本上失去了对场面的把握，一切决策完全取决于下属。没有称职的下属，各种决策只能一味地做，最终成为只会沟通的管理者---即使被食人族吃掉，也无人察觉，因为存在的价值被无限稀释，成为A象征性的标志。也可能与下属发生激烈冲突。因为这种管理者没有自己的位置，上面有任务只能往下压。结果与实际情况相差千里，无法实现。这样的管理者不能向上级汇报，只能向下传递压力。不管是什么，一旦到了这个地步，其实已经趋于失败，只能祈祷食人者不要来了。为什么中层管理者坚持更新知识？IT行业流传着一个关于食人族的著名笑话。这个笑话说：两个食人者在一家大公司应聘。于是他告诫他们：“敢在公司吃人，立马开除！”两个食人族客客气气的答应了，说他们绝对不会吃公司里的人。两个月过去了，公司安然无恙。突然有一天，公司发现负责打扫公司的保洁员不见了。于是人事主管很生气，找了两个食人族训斥了一顿，当场开除。一出公司大门，一个食人族立即向另一个抱怨道：“我一直警告你们不要吃做事的人，你们就是不听！我们两个月来每天都吃一个经理，没有有人注意到了。现在看，把清洁工吃掉，他们马上就会发现！你是头猪！”这个笑话讽刺了一些大公司病了，人浮于事。大企业的病根很难一下子说清楚，但结果更明显，必然会导致更多人成为中层管理者。如果说成功的企业天生就有感染大企业病的倾向，那么中层管理人员无疑也自然有扩张的倾向。从个人角度来说，被食人魔吃掉无人问津并不是什么好事，因为这意味着存在的价值被削弱，不需要更新知识。一旦面临裁员之类的事情，这个人很可能已经失去了面对残酷竞争的能力。
