《程序员生存定律》 李智勇

首先感谢作者能写这样的东西分享给大家(原作者：李智勇 V 众投发起人,《完美软件开发:方法与逻辑》作者)。

以下是我摘了一些对自己有启发的片段，以前是傻傻地放在自己的云笔记中的，不懂分享：

 转载请注明出处:http://blog.csdn.net/enyusmile/article/details/45498293

• 本书中试图用四个可控变量来定义程序人生的规律,它们分别是:自身价值---也就是你能干什么;自身价值上的表达力---也就是别人认为你能干什么;自身价值的稀缺性---也就是在特定时空背景下,市场对某种技能的渴求程度;身处公司的特质和未来---也就是公司提供了怎样的平台给人发挥。本书认为这四个变量一起决定了一个人在职场中的市场价值,个人的一切选择主要是为了在这四个变量上有所收益,并使市场价值最大化。
• 尝试以写程序的方式建立一种精确的人生模型是非常困难的。一旦试图这样做很容易进入一个误区,即期望为人生建立一个真理式的公式。比如:如果你努力,那么你一定成功。如果你有责任感,你一定成功。如果你人品好,你一定成功。如果你读书,那么一定成功。如果你注意细节,那么你一定成功。如果你时间管理做好,你一定成功。...
• 据说某位行为科学家曾经总结过:上帝把所有容易的问题都留给了物理学家。言下之意是,社会学科的问题都大不易。其根本原因在于,人生是不精确的。这里的关键是要找到起关键作用的可控因子和权变变量。
• 人生其实是条曲线,其振幅则随着时间的流逝而逐渐收窄。而一个人最终振幅的高度则同时取决于:机缘、天分和努力。家世,时代种种皆可归为机缘。智商、情商、体质种种皆可归为天分。机缘和天分皆是命数,无从左右的起。也即是说,一个人持有的,可以打破既定命数的砝码也只是努力而已。从人生长短的角度来看,上帝是公平的,每个人可用时间大致相同。不同的则是努力的效能。

第二章 职场生存定律

• 支撑职场的基本规则是交换,交换的两端分别是你可创造的价值与你的职场位置(包含收入)。交换就像任督二脉间的通道一样,越是通畅,人生也就越顺风顺水;堵得越死,人也就越寸步难行。
• 如果收入水平为 I,那么当 S x A > I 时一个人是有选择权的也是安全的,否则一个人对于公司而言是负资产(至少是被认为是负资产),潜在的有被剔除的风险。一旦一个人在多家公司里都处于这样一种情形下时,这个人的选择权会越来收的越窄(只有公司可以选择个人,个人却没可能选择公司),人生也就会越来越被动。确实有几个因素会
  使实现程度 A 急速膨大。这几个因素可以概括为:自身价值表达力,自身价值的稀缺性,
  公司的特质和未来。

      定律要素之一：自身价值

1. 人创造价值的基本途径只有两个:一个是完全依赖于自身的技能,另一个则是假于他人之手。
2. 自身价值也是公司命运的根本。吴军先生的《浪潮之巅》

     定律要素之二：自身价值上的表达力

1. 敏于
   事讷于言的人很多,难道他们就没有表达力了么?显然不是的。一个人的过往、行止、习惯、性格等都是表达力的一部分。
2. 程序员必然同时具备这两方面的能力:编程技能与做员工的技能,而做员工的技能则像一个变压器,最终放大或缩小你的真实能力。这就是表达力的功效,而做员工的技巧正是表达力的一部分。
3. 组织行为学这类学科中会把这个问题单独作为一个研究项目:印象管理(impression management),首因效应等
4. 从长期的
   视角来看,影响自身价值表达的几个主要因素是:资历、自身性格特征、借势的程度以及权术的运用等。

    定律三：定律要素之三:自身价值的稀缺性

1. 稀缺性本身取决于需求与供给,这样获得稀缺性就有两个主要的手段:一是站在需求相对恒定,供给比较稀少的位置上;一是加入需求急速膨胀,而供给有限的场景下。
2. 稀缺性的客观状态是一种大势,作为个人基本上不可能改变,只能做选择以对应将来。所以其背后主要隐藏的是在特定时间点做出恰当判断的问题。而且稀缺性是有时效的。

      定律要素之四:身处公司的特质和未来

1. 组织是利益分配的基本单位。作为结果,不管喜欢不喜欢,组织是利益分配的基本单位,在这之后,才是组织中的个人如何进行利益分配。在分配 iPhone 所带来的利润时,首先是苹果和富士康间的利润分配,接下来才是苹果内部和富士康内部。
2. 在《史记•货殖列传》里太史公写过这样一段话:是以无财作力,少有斗智,既饶争时,此其大经也。这段话里描述的三个层次则与我们上述描述的层次类似:谋求自身增值是无财作力的层次,增强表达力是少有斗智的层次,而注意稀缺性和公司特质则大致是既饶争时的层次。
3. 我们可以看一个简单且常见的例子,并用上面四个要素分析一下利弊得失:工作中总是存在简单且重复的工作,极端的就是生产线,你可能只是需要伸缩一下手臂,只是每 3~4 秒就要来一次。在程序员的工作中不太会有生产线那么夸张,但确实也有简单重复性工作,比如单纯的拖控件、关联数据库或者例行设置大量配置信息等。
   对这样一份工作应该如何进行分析?平心而论,想彻底避免简单重复性工作是不可能的,但如果一项工作的主体部分体现为简单重复,并且不可能自动化,那么这种工作从增值的角度看是没有助益的,可归为技术
   路径短,不增加自身价值的工作。稀缺性则依赖于所做工作的具体含义。比如:如果你所处理的大量配置信息深嵌在一个公司内部的各个角落(收集困难),各个配置项的含义并不是很好理解,这个工作对某家公司又特别有义,那么稀缺性反倒可能很好,但可流动性就几乎没有,个人利益和公司利益将结合的无比紧密。这时候公司平台变得很关键。由于选择权已然变小(只能在特定的公司或领域),这个时候表达力就非常的重要,如果不能在表达力这样的活动上有所突破,那个人的未来就很难明朗。这个四个要素总是同时起作用,但不同时期、不同情景下,权重会有比较大的变化,这点在后面会逐渐展开。微观来看,每个人的职场经历可能都很不相同,但骨子里起作用的始终都是这几个因素。
4. 时运：程序员的命运也受时运所左右,你可能能力优秀、思维活跃,性格鲜明,表达、技术也很优秀,但如果几次换工作却总是碰到呆板,喜欢老实人的领导,碰到平庸的公司,就可能一直不被欣赏。这种事情既不会是今天才有,也不会在明天就立刻消失。面对这类较差的时运,最需要的旺盛的斗志和耐性,干别的都没用,求神拜佛也不行。马化腾、马云这些大佬当年一样很折磨,如果马化腾在最痛苦的时候把腾讯卖了,那就不会有今天的每年 400多亿收入,程序员也一样,这时候要有点但行好事莫问前程的心态。但这里有个陷阱,很多人会把个人的失误推诿到时运身上,麻醉自己,让自己心里好过点,这个是假的时运。

第三章 软件的世界是怎样的

1. 规律是必须顺应而不能改变的,但除此之外现实中还有一些事实也是无法改变的,这两者都很像程序中的常量,想提高人生的高度则需要同时驾驭这两者,而不能试图为两者赋值。

     3.1  技术更迭偏快

     3.2  介入门槛偏低

• 当然,后劲不足可能会把不思进取的软件开发人员限制在某个范围内,比如说只能做
  应用级的开发,最终让他们等待淘汰。

     3.3  软件和软件差别可以很大

• 对方法论而言,基于这一点最关键的一个引申结论是:任何一种方法论不只要陈述自己的方法,还要陈述自己方法的适用边界。

软件的世界里还有许多其它的特征,但和个人发展相关且无法改变主要是这里提到的三点:技术更迭较快、介入门槛相对较低、不同软件差别极大。这三者类似于全局常量,而个人努力则类似于变量,它们共同在生存定律之下起作用,影响人生的最终高度。从自我增值的角度看,最关键的事情是不能与这三者所带来的效应相违背。

第四章 程序员的增值之路

• 我们将把增值之路分解为三个根本步骤并分别进行讨论:如何选定自己的方向、如何开始自己的学习、如何持续的进阶并成为高手。
• 4.1 方向的选择:技术还是管理
  • 4.1.1 技术与管理的关键差异
    • 要想做出自己的那份选择,还需要考虑三件事情:一是既定环境下技术路径究竟有多长,也就是说做技术有前途么;一是个人的性格适不适合做管理工作;一是做管理工作可能会有什么负面影响。
  • 4.1.2 技术路径长短对前途的影响
    • 类比到软件行业里,单纯的在既定接口下实现已定义的业务逻辑就是技术路径比较短的工作,是体力密集型的;而分析业务逻辑,控制整体架构或者去研究 TTS 的算法则是智力密集型的,技术路径较长。
      在选择方向时关键要避免的是选择了技术方向,但身处的现实中技术方向却路径较短,或者喜欢管理但跑到了纯粹技术流的公司里,这种选择其内部所蕴含的矛盾会给当事人的人生造成极大的困扰。
  • 4.1.3 什么样的程序员适合转管理
    • 先天带来的很多东西,比如性格等实在很难改变,更多时候选择顺应自己的天性比选择对抗更加明智。
    • 在大五模型里用五个因素来考察人格特质:
      • 外倾性(extroversion):外倾者者倾向于喜欢群居,善于社交和自我决断。内倾者则比较内向,胆小害羞,安静少语。
      • 随和性(agreeableness):高随和性的人是合作的,热情的和信赖他人的,低随和性的人是冷淡的,敌对的和不受欢迎的。
      • 责任心(conscientiousness):高责任心的人是负责的,有条不紊的,值得信赖的,持之以恒的。低责任心的人则容易精力分散,缺乏规划性,且不可信赖。
      • 情绪稳定性(emotional stability):积极的情绪稳定性者倾向于平和,自信;而消极情绪稳定性者(神经质的人)倾向于紧张,焦虑,失望和缺乏安全感。
      • 经验开放性(Openness to experience):开放性高的人富有创造性,凡事好奇,具有艺术的敏感性;开放性低的人则保守对熟悉的事物感到舒适和满足。
    • 总的来看,外倾性和经验开放性好的人更适合走上管理岗位。
  • 4.1.4 管理工作的负效应
    • 管理工作和人打交道比较多,所以对人员的特质有很强的依赖性。
    • 长时间在管理岗位的话,即使是做技术出身,技术能力也会退化,沟通技能、与上级的信任程度反倒会提高。
• 4.2 增值之路的起点
  • 4.2.1 从那里开始编程生涯
    • 如何参与开源项目?
      蔡俊杰主编的《开源软件之道》对开源软件的各个方面进行了比较系统的介绍,也介绍了参加开源项目的方法。总的来看参与开源项目并没有很高的门槛,需要的是用心和投入。为了参与开源项目第一步选定项目并弄清目标开源社区的运作方法。 Apache 和 Mozilla都是开源社区,但运作方式还是有差异的。接下来要熟悉特定的开源项目,包括产品的功能和特点、代码规范和架构等。为了做出具体的贡献,那么需要订阅邮件列表或者新闻组来了解社区当前状况。接下来可以尝试提交补丁或实现新功能来解决社区中的特定问题。一般来讲开源社区会把参与人员分为几个层次,比如:在 Apache 的运作模式中共有这样几种角色:开发者( Developer) ,技术专家 (Committer) ,项目管理委员会成员( ProjectManagement Committees) , Apache 软件基金会理事会 (Board of Directors) 。当一个开发者付出足够努力,获得足够影响力后,项目管理委员会会授予这个人 Committer 称号,只有 Committer才拥有对代码库的写权限。如果 Committer 的贡献足够大,就有可能被选举进入项目管理委员会,而项目管理委员会的主席则都是 Apache 软件基金会的 VP 。新参与者在最开始阶段必然只能是 Developer 的层次,不会具有写权限。只有通过积极参与讨论,为社区做出了具体贡献之后才可能获得 Committer 称号。这是一个持续投入的过程。当然参与社区工作,不一定非是提交代码,也可以帮助完善文档、运行测试用例、报告缺陷维护网站等等。
  • 4.2.2 打牢根基 VS 速成道路
    • 那些东西可以被认为是编程的根基,需要在学习阶段扎实的掌握?下面将通过推荐几本书(或者说几类书)来描述一个共通于所有程序员的最小集合。
      • 计算机体系结构：《深入理解计算机系统》,作者是 Randal E.Bryant 和David O’Hallaron。
      • 算法和数据结构:《算法导论》,作者是 Thomas H.Cormen,Charles E.Leiserson,Ronald L.Rivest,Clifford Stein。
      • 设计原则和模式:《敏捷软件开发:原则、模式与实践》,作者是 Robert C.Martin。GoF 的《设计模式》
      • 软件工程:《代码大全》,作者是 Steve McConnell。《人月神话》
    • 《Hadoop 技术内幕》
    • 如果条件实在不允许厚积薄发,非要速成,我觉得可以尝试用这样一种方法:死磕一个流行的开源程序。比如国内用的比较多的是 WordPress,那如果狠狠心花半年一年把WordPress 搞透了,技能能提升不说,对找份合适的工作也还是很有帮助的。
  • 4.2.3 掌握读代码的方法和技巧
    • 从学习的目的来看,一定要精读一定量的经典代码。而精读是指每行都读懂,不看代码脑子里就能勾画出程序的基本结构。
    • 这节里主要关注的是如何泛读较大规模代码,不是精读。
      • 读规模较大的程序前,先得把规格说明书大致弄清楚,而不能上来就读。
      • 接下来从大往小,从面到点来看。
      • 接下来选择出最常用的典型场景,然后在典型场景下考察上面的静态结构是如何发挥
        作用的。
      • 接下来要关注进程、线程的结构。
      • 上述四步(规格、静态结构、典型场景、进程线程)完成后,对程序的第一次泛读完成。检验是否达成目标的方法可以很简单,如果真的基本读懂了,这时应该能够单靠纸笔描述出程序典型场景的 Sequence 图。
    • 有两个基本技巧总是需要的,一个是要掌握具体程序里内嵌的 Log 机制,要能看 Log,必要时可能还得加 Log;一个是基本调试方法。同时一个合适的代码阅读工具会对提升代码阅读速度有所帮助,比如:一款名叫 SourceInsight 的小工具中可以把窗口分拆为几个部分,点击任何方法的时候,这个方法的实现以及 Calls Graph 都可以被自动展开,这样的小功能无疑的对阅读代码是有帮助的。
  • 4.2.4 从那门编程语言开始学习?
    • 学习阶段学习语言的目的是为了掌握编程的基础概念并能更快速的学好另一门语言。显然这仍然是打基础的范畴。
    • 只有一门语言是必须学的,那就是 C
• 4.3 如何顺利的成为高手
  • 4.3.1 高手的定义和养成关键
    • 软件的三个基本特征(技术更迭快、低介入门槛、多内部分野)就像铡刀一样,一旦选择出错,就会把个人的努力切的粉碎,一点价值也留不下来。而与此相对的,则是人的黄金学习时间其实并不多---不过是毕业后的 10 年左右的时间。
    • 为了在成为高手这条路上走的顺畅,事实上有三个关键点:一是要有一张全局性的地图,以便选好方向;二是要知道都有那些坑,好绕开它,免得掉进去。三是要有足够的热情和动力,能坚持走下去。
  • 4.3.2 全局性的地图
    • 清代著名学者曾对知识地图的必要性做过非常精确的表述:凡读书最切要者,目录之学也。目录明,方可读书,不明,终是乱读。--- 王鸣盛,《十七史商榷》目录即是地图。
    • 契约式编程
    • 《人件》
    • 随着待解决问题越来越复杂,通用的领域知识中,几种技术往往会组成一种技术 Stack,他 们 更 需 要 被 看 做 一 组 必 须 一 起 掌 握 的 知 识 , 比 如 : LAMP(Linux+Apache+MySQL+Python/PHP)
    • 读书无疑的可以加速一个人增值的过程,记不得是谁说过:实践无疑是人类最好的老师,但只靠实践来认知世界无疑也是愚蠢的。这是非常精辟的。除此之外,要想培养大局观,那就非读书不可。
    • 有一本很有名的书对培养技术的大局观有帮助:《代码大全》。
    • 基于上面这样的一张地图,我们就可以具体的去考虑几条进阶路径。
      • 1. 路径一:由程序员而架构师
        • 假设说一个人已经掌握了一门或几门编程语言、面向对象、设计模式、能够很熟练的写出质量较高的代码,接下来他想成为架构师,这个时候他需要做什么?我个人认为,这时候这个人首先要有一个“专业”。这个专业可以是“金融”,“财务”,“电商”,“管理”等等。这是一种属于某一专业的领域知识,而不是编程技术。如果把需求和最终的代码,看成描述同一事物的一体两面,那么设计始终是要架起这两者间的桥梁。而架桥的时候,怎么可能只知道一端而不知道另一端。
        • 接下来是深化设计所需要的各种通用领域知识(UML、面向对象、性能确保等)。
        • 最后一点是,做架构设计已经相对于在做技术管理工作,至少要适当涉猎估算并能做出合适的任务分解,这样一旦日程紧张,则可以通过增加人手等手段来在质量、成本和进度之间进行均衡。
        • 架构师所需要达成的最终目标可以形象的描述为:产品经理考虑用户和市场建立了一个模型,那么架构师要能把这东西映射到技术的世界里来。如果是在互联网行业,那么在你的主导设计下要可以做出高并发的网站。换到其他行业也与此类似,从产品的的角度往回看,架构师要能解决和技术相关的所有问题,主导完成商业上有价值的产品或项目的开发工作。实现手段上倒并无限制,可以是购买,可以是组织人员进行开发,只要能平衡短期和长期利益,解决特定的问题即可。
      • 2. 路径二:由程序员而 CodeGuru
        • 这条路线里,程序员并不把自己擅长的领域扩的太宽,但在指定领域上会挖掘的很深。驱动、字库、图形库、算法库、OCR 等都偏向于这一领域。
        • 成为 Guru 的最简单方法?
          有一条成为 Guru 的捷径,并且可能可以比较好的实现自己的价值:选定一个应用比较广的,有深度的开源项目,读通它的代码,参与进去,在社区中累积自己的声誉。
      • 3. 路径三:由程序员而纯管理
        • 从需要读的书来看,这时候可能要看过 PMBOK,《项目管理修炼之道》,《管理的实践》,《基业长青》等等。
        • 抛开机缘这类东西不论,做好管理工作有两点很关键:
          • 一是要把技术工作做的相对比较好。过度务实的人容易迷失于道路,过度务虚的人则容易飘的太高而丧失根基。管理者正应该身处在这两者之间的一个平衡点。
          • 二是要能够借势。要情商比较好,能把很多人组织在一起。这个时候要知道那些东西需要规则化,那些东西需要灵活把握。过度偏向规则是教条,过度偏向灵活则是人治,平衡点始终要根据具体人员的状况,工作特质这些不可改变的事情来把握。这有点微妙。但即使
            程序员这个群体相对简单,但并不能推翻先人后事这类规则。这不知道是不是东方特色,当你想做管理并想推进事情的时候,终究要理清人际上的关系,否则就和可能会欲速则不达。
        • 管理者需要有产品的视角对于公司而言,产品往往因为和现金流更近而有更直接的价值,而技术之所以有价值则是因为他往往是产品构建中最关键的一环。所以说大多时候是技术服务于产品,而非是产品服务于技术。而过于关注于技术的程序员则往往倒置这一关系,试图让产品服务于技术。
  • 4.3.3 避开增值路上常见的“坑”
    • 1. 学习失去焦点
      • 这里想表明的是,一旦误读了知识与目的间的因果关系,那么学习就会失去焦点,进而造成负效应,毕竟相对于人的可承受负荷而言,这个世界上的知识不是太少,而是太多。
      • 一般的认识是只要学习就必然有所得,所以对人生的影响一定的是正面的。但实际上这个想法是偏颇的,尤其是在软件行业里。在软件行业中,这种风险之所以异常突出,就在于前面提到过的软件的两个特质:更迭速度快和子领域众多。这两个因素导致软件相关的知识是爆炸性增长。
      • 避免“失去焦点”这一陷阱的第一关键则是分类:对软件开发进行分类,对软件所关联的知识也进行分类,形成自己的大局观和整体视图。
        • 算法领域中,最经典的书籍恐怕是 Donald Knuth 的《计算机程序设计艺术》。
        • 这里最关键的就是聚焦,聚焦的根本则是要在限定时间范围内创生价值。
    • 2. 学习与实践相分离
      • 解决艰难问题时,天分很重要;解决复杂问题时,练习很重要。
      • 根据统计最多的 Bug 是由新手导致的。这从侧面说明,能做和能做好之间的鸿沟需要大量的实践来填平的。
    • 3. “博”与“专”上的迷失
      • 对于大多数软件开发人员而言,要去寻找广博与精专间的均衡点:既不能闭上眼睛,也不能就用显微镜来看世界。而这一均衡点的价值则可用反木桶原理来说明:木桶原理说的是桶里的水是由最短的一块板决定的,但考量人的价值时却是适用于反木桶原理,即人的价值往往由最长的一块板决定。
      • 此外,考虑博与专平衡点时似乎有一种特例,钻研特定算法的人,从一开始就只往专的方向发展,并不会考虑其他。比如:钻研 TTS 的人,可能几十年如一日只要专注于 TTS就完了.
      • 总的原则是要以当下工作为根基,以实用为目的甄选各种知识,并追求平衡点。
      • 学习软件工程的时机与必要性简单来讲越是没实践经验的人越不适合学习软件工程,越需要规划整体把握全局的时候越需要学习软件工程。
    • 4. 错过人生中的好时机
      •  学习本身无疑的是需要顺应这种自然规律的。
      • 学习英语的时机和必要性总的来看,程序员学习英语是一项投资回报率相对比较好的投入。从目标上来看,程序员未必一定要口语流利,但最低要达到阅读英文资料没有障碍的程度。
    • 5. 停止知识更新
      • 对程序员的增值而言,人生里最大的陷阱也许是为安全的假象所欺骗而彻底的放松自己。
      • 从做产品来看,要想成功,有两个关键维度需要同时进行把握,一是产品的概念完整性的把握;一是用合适的手段去实现这个产品。
  • 4.3.4 给自己找一个驱动力
    • 1. 纯物质上的驱动力
    • 2. 兴趣的力量
      • 总的来看,兴趣可以分为两个层次:一个是浅层次的。比如看到一个游戏比较酷可能想玩玩,看别人写博客,自己也写几篇;另一种则是深层次的。比如:爱因斯坦你不让他思考,他可能感觉活着就没什么意思了。找到后一种兴趣的人是幸运的,但大多数人并没有这么幸运,所以一般所说的兴趣都是前一种,尤其是即将毕业和刚毕业不久的人
      • 我个人感觉,越是靠近体力一端的工作越不可能兴趣驱动,而越靠近智力一端的工作越可能是纯兴趣驱动。
    • 3. 使人生永动的势能
      • 如果说物质和单纯的兴趣不足以成为一种长久的驱动力,那么无疑的我们需要继续去寻找一种可以使人生永动的势能。
      • 《青春》塞缪尔·厄尔曼
      • 青春是一种进取的精神,是一种远离颓废追逐理想的状态。
      • 人的思维和欲望具有无边界特质,只要在未来和现在之间制造一种差距,那么就会产生无尽的势能,人也就会不断的前行。而制造这种差距的最佳素材往往只能是理想。
      • 这里最后想说的是有理想、有斗志不一定会成功,但无理想、无斗志几乎一定会铸就平庸和失败,因为细致想来世界本身归根到底是理想主义者的。
      • 动机理论里最有名的可能是马斯洛的需求层次理论,即:
        • 生理需要:包括觅食,饮水,栖身,性和其它身体需要。
        • 安全需要:保护自己免受生理和情绪伤害的需要。
        • 社会需要:爱、归属、接纳和友谊。
        • 尊重的需要:自尊、自主和成就感;地位、认可和关注等。
        • 自我实现的需要。
      • 上面的内容则主要参照了人民大学出版的《组织行为学》一书。

第五章 程序员的表达力磨砺

• 5.1 表达力的类别和作用
  •    表达力和技术技能不是一种对立关系,而是一种叠加的关系。从纯量的观点来看,叠加后的高度,才是一个人表现出来的高度。
  •  一提表达很多人会想到沟通,尤其是言语沟通,但这是一个非常巨大的误解,表达力并非只限于语言,现实亦可为表达作证。当面对一个陌生人的时候,更多人会采用察其言观其行的方法。这时候往往行重于言。也就是说,但凡影响一个人在他人、在组织里的形象的东西皆可视为一种表达。
• 5.2 改善表达力的途径:在本书中,我们认为四个因素对一个人的表达力有关键影响,它们分别是:资历、性格与习惯、借势与公司政治。
  • 5.2.1 给自己一点资历
    • 用心来想,资历之中主要包含了三个方面的力量:忠诚、信任与对既有规则的熟悉和对既有人员的熟悉.一个人最终表现出来的能力事实上有两个关键支撑,一是能做什么所对应的能力,一是工作意愿,两者相乘才是一个人表现出来的能力。
    • 资历有助于体现个人能力,所以要给自己一点资历,只在彻底没有希望的时候换工作。否则会损失掉资历背后的力量。
  • 5.2.2 去除性格和习惯中的致命缺陷
    • 性格决定人缘,而人缘影响沟通成效,最终影响一个人的表达力。
    • 1. 人情练达
      • 傲气与狂妄的差别:程序员是需要有点傲气的,一点傲气都没有的程序员往往就会失去对技术的追求并失去对自己的信任。这在技术上是很致命的。但狂妄则是走向灭亡的前兆,要引起警觉。
    • 2. 有条件的顺应环境
      • 做点事情其实远比想的麻烦,即使是在开明的公司里面,唯有抱怨最容易,但抱怨什么也换不来。
    • 3. 去除致命的坏习惯
      • 忽视细节
      • 推卸责任
  • 5.2.3 善用借势
    • 1. 借势的价值
    • 2. 借势的具体方法
      • 关于 Instagram 如何成功想必有很多细节,但从公开报道来看,技术上的完美借势是很关键的一个原因。这从其开发团队所遵循的原则就可以看出来:
         Keep it very simple(极简主义);
         Don’t re-invent the wheel (不重复发明轮子);
         With proven and solid technologies when you can (能用就用靠谱的技术);
        两个技术水平差不多的人,一个信奉什么都从头造,一个信奉尽可能用现有靠得住的技术,那么无疑的从“表现力”的角度看,后者占优。
  • 5.2.4 了解一点“政治”
    • 1. 程序员躲不开“政治”
      • 为什么大公司的钱不能随便要?
      • 这里面的规律可以简单描述为一旦一个公司发展起来后,内部必然伴随着某种势力格局,这种势力格局就会衍生出政治。只有在公司初创,高速成长期,这类氛围才可能比较淡薄.道理很简单,打仗的时候首先考量的是一个将军是不是能征善战,和平时期则不只要考虑一个人是不是能征善战。
    • 2. 可参考的“政治”手段
      • 印象管理:印象管理讲的是如何控制自己的表现面。当进行这类印象管理时往往需要一定程度的自我监控。总的来看原则却并不复杂:诚实的宣传自己,更多的获得认可。
      • 常见的权术手段
        • 合法性。
        • 理性说服。
        • 鼓舞式诉求。
        • 商议。
        • 交换。
        • 个人式诉求。
        • 逢迎。
        • 施压。
        • 联盟。
      • 从代码里你可以看到政治么?纯粹的程序员从代码里只看到技术,所以大多时候会抱怨:谁写了这么垃圾的代码?但懂点微观经济学的程序员则会在技术之外从代码中看到利益纠葛,看到人心世道。为什么世界上会有这么多垃圾代码,这绝对不只是因为技术不行。如果世界只由技术因素主宰,那么按理说只要一个软件存在的时间足够长,投入的人力足够多,代码一定会变的足够好。但事实恰恰与这相反,存在时间越长的代码往往越垃圾。这可以简单理解,既存的代码表征着一种市场价值,如果改了它那么一旦造成的损失谁来负责?程序员来负责?总经理来负责?没人来负责,那么只能破坏逻辑清晰性来保证妥当性,代码自然就会变得越来越垃圾。所以说这里首先是利益纠葛问题。这是非常有意思的一个课题,因为改好代码长期有收益,短期必然有风险 --- 再牛的人也没办法保证自己的修改毫无偏差。宏观来看,保证好代码真的很简单:找一帮有责任心的很牛的人,让他们不考虑市场因素的持续进行重构,那代码必然越变越好。而关键则是,如果你是 CEO ,你愿意这么干么?所以说在市场经济里面,往往并没有纯粹的技术。这样一来,政治的存在也就不是什么值得奇怪的事情了。当然开源很可能是例外的。
• 5.3 检查自己的表达力
  • 假设有一个你很想做的项目要开始了,你的技术能力是足够的,你想在这个项目里承担比当前责任范围更大的工作,这时候在有竞争者的前提下你有多大把握获得参与这个项目的机会?这个时候如果答案是绝对没问题,那么表达力上大致是没什么问题的。如果是没可能,那么表达力上是很有问题的,需要做点反省.
  • 如果想系统的做个检查,那就要按照上述所说逐项进行检查:
    • 自己换工作的频度是不是太高了?
    • 自己是不是个惹人厌烦的人?
    • 自己有没有一点影响力?
  • 怎么判定自己是缺表达力,还是缺技术力,则并不是很难的事情。大多数人只要在夜深人静的时候仔细想想过往,大致就可以找出答案。如果答案仍然模糊,那么可以做张表,给自己的技术力在公司里排排位置,如果已经排的很靠前,并且掌握前面所说的知识地图中大部分知识,但职业路径却不顺畅,那基本上是缺表达力了。

第六章 程序员的稀缺性营造

• 稀缺性同时受两个维度上的力量影响:一个是自身的努力,比如前文所提到的增值和表达力;一个是大环境的变化以及对这种变化的适应。
• 6.1 稀缺性可带给你什么
• 6.2 改善稀缺性的途径
  • 6.2.1 奔向程序世界里的价值高地
    • 投资大师巴菲特先生说过一句流传很广的话:有的企业有高耸的护城河,河里头还有凶猛的鳄鱼、海盗与鲨鱼守护着,这才是你应该投资的企业。这句话非常传神的描述了价值高地的外在形象。
    • 不管是那种方向,最终都要达成这样一种效果:你可以完整的搞定一件很有商业价值的事情,而这件事情大多数人搞不定。
  • 6.2.2 走在技术大潮的前面或里面
    • 如果回望十年,我们就会发现,先有 PC 客户端程序的鼎盛,接下来是互联网的兴起,再接下来则是移动客户端的兴旺。以当下而论,无疑的移动客户端和互联网要比传统的 PC客户端来的更有吸引力。而在云的时代里,壁垒比较分明的两套 Tech Stack 则是基于闭源的一系列技术(主要是由微软提供)和基于开源的一系列技术。在这里面如果那个 Tech Stack的技术逐渐取得优势,那么无疑的在相应的 Tech Stack 中有积累的人会有比较好的稀缺性。虽然眼下看来,两者似乎没有明显差别,但在这点上,我个人认为未来开源 Tech Stack会逐渐取得优势。在 Quora(quora.com)和 High Scalability(highscalability.com)上,我们可以查找到国外大部分新兴的、市值超过 10 亿美元 Web2.0 网站的技术架构,如: Flickr, Pinterest,Instagram 等。如果用心来读这些技术架构,就会发现他们一个根本的共同点:他们都是基于开源技术构建的。这种不约而同的选择背后有一定的必然性。当希望一定的定制性并且不愿意支付高额成本时开源 Tech Stack 几乎是一种唯一的选择,尤其是当开源的技术有越来越多成功实例的时候,这种优势就越来越明显。如果非要在客户端(iOS,Android,WinRT)和互联网中选择,我个人认为互联网比客户端更有优势。
• 6.3 检查自己的稀缺性
  • 如果想比较系统的评估自己的稀缺性,那么需要依次考虑如下问题:
    • 自己所掌握的技术是即将过时的技术么?为保持对技术动向的敏感度,定期阅读别人的架构非常关键。
    • 自己所掌握的技能究竟有多少人会?。比如:单纯的会用 ASP.net开发网页几乎没有较高的技术壁垒,但对数据库的设计有相当程度的掌握、能够较好的通过负载均衡、缓存等手段保证系统的性能就可以使自己的稀缺性上个台阶。
  • 软件相关的知识实在是太庞杂,没法设计一条唯一的道路,但稀缺性好不好却可以大致评定:考虑一下一个新毕业生达到自己这个高度,需要多久。如果和新毕业生三年后所能达到的高度相似,那就怎么也不是稀缺性好的位置。

第七章 程序员的公司选择

• 在武侠的世界里,帮派本身借助了个人的力量而成其威名,但反过来个人却又因为帮派的力量而被烘托的更高。如果我们把公司类比为帮派,把程序员类比为一众江湖人士,那么帮派和成员间这种异化、同化的过程就几乎在每一个程序员的身上都可以看到。牛顿说过一句广为流传的话:如果说我比别人看得更远些,那是因为我站在了巨人的肩上。选择在什么样的公司里工作,几乎等价于选择站在什么人的肩膀上。再形象点讲就是选错了公司等价于输在起跑线上。
• 7.1 给公司分类
  • 7.1.1 分类的方法
    • 分工所处位置的视角:帮派间是有食物链的.类似的关系也存在于公司与公司之间,但这时这种关系则是有产业分工时公司所处的位置所决定的。
    • 这种链条的一个根本特征是上游的企业人少但分享的利润更高,当然其承担的创新风险也更大。
    • 行业的视角
      • 很难讲那个行业相对另一个行业具有绝对优势,但有两点需要额外注意:一是软件是不是公司的主营业务对发展空间往往会形成一定限制。制造业的工厂里也做软件,但不太可能选几个做软件的去做厂长,金融公司里程序员也很难发展成为总裁。另一点是有的子行业处在成熟期,发展相对平缓,而有的子行业则处在高速发展期,发展很迅速。
    • 时间轴的视角
      • 选择发展期的公司还是选择成熟期的公司上,要依赖于个人选择。通常来讲选择成熟度较高,市场地位较高的大公司会比较好,便于做技术积累。
    • 核心竞争力的视角
    • 地域的视角
    • 公司文化的视角
    • 人生中的关键选择与公司分类:程序员的一生中会有几次非常关键的选择。第一次关键选择往往是你毕业后加入了什么样的一个公司。第二次关键选择是毕业后的 3~5 年。。这次选择很可能是关于换工作换行业,也可能是关于选择持续做技术还是转到管理方向,或者两者都有。 3~5 年间,不同人的累积可以差到很悬殊的地步,上面的两类选择只对其中表现比较优秀的才有现实意义。没有积累的,往往既没有选择管理的机会,也没有换工作换行业的机会,或者说即使换工作也只是表面的变化,而工作的内涵则很难变化。因为这段时间一定程度上还是在打基础,所以多少还有转换子行业的机会,在此之后就非常困难了。第三次选择是毕业后 10 年左右。这次选择是关于保持生活现状,还是打破现状,进行冒险。比较优秀的人在这个时候,往往会有一定成绩,很可能算是比较中层的位置。但接下来的生活很可能变得重复性比较强。这时一个人可以选择换一种活法,还是持续自己现有的工作和生活风格。当然就像武侠的世界中有没有品级的高手一样,这世界上也总是有例外和英雄豪杰,大学生也可以创业,开创自己的商业帝国。上面只是正常的情形罢了。
  • 7.1.2 具体类别的点评:外包行业
    • 如果让我来排个顺序则首先是知名的独立软件开发商(ISV),其次是前景比较好的独立软件供应商,接下来才是做高端外包业务的公司,做低端外包业务的公司大多时候不是什么好的选择,因为对个人成长不利。
    • 杰克•韦尔奇 《赢》
    • 外包的根本目的就是节约成本,不是为了创新等高附加值工作,也就是说通过把附加值低的工作转移到人力成本相对便宜的地区来降低成本是外包的根本目的。这是一种无可避免的潮流,A 公司做了,A 就可以大幅拉低成本,B 和 C 也就必须得跟进。
  • 7.1.3 具体类别的点评:互联网行业:如果说 IT 行业是朝阳行业,那互联网绝对是朝阳中的朝阳。在这个领域中我们看到了门户网站,看到了搜索引擎,看到了社交网络,看到了各种云平台和大数据,但故事应该远未终结。未来究竟出现什么样的产品很难预测,但未来的产品会和互联网紧密相关这点错的可能性很低。所以在行业选择上加入一家以互联网业务为核心的公司是不错的选择,从发展的角度看很同等条件下要比加入通信、金融这样的行业更有优势一点。假如一个人想创业,那这就更是一种必然选择,互联网是智力密集型的工作,需要一定资本,但对资本的要求并不高,几个人拉到风险投资后,假设网站开始创业怎么也比研发路由器开始创业更适应于一般人一点。这里面在分类上有一个微妙的地方需要注意,搜索引擎、大数据、社交网络可以认为是互联网,但挪到互联网上的 ERP 也还是 ERP,不能算是互联网行业,这个差别很大,考察公司的时候要注意。
  • 7.1.4 具体类别的点评:外企
    • 什么叫透明天花板?职业路径被封死在某个高度以下,但这种封锁在可见制度层面又不存在,这就是透明天花板,往往是做到一定高度的人对此感受的更为清晰。
  • 7.1.5 具体类别的点评:受非市场因素影响大的公司
    • 这个类别的公司特征是可以因为特别的机会(某个大单或某项特别资助)在短时间蓬勃发展,但接下来又很可能会在短时间轰然倒下。我个人倾向于认为应该规避这类公司,因为这类公司通常并不会把精力放在产品的开发上,而会放在非市场因素的经营上,这对个人成长并不是很有利,尤其是走技术方向的人。一旦公司出现危机,那么个人反倒可能会因此陷入困境。
• 7.2 选择公司的方法
  • 7.2.1 使工作和自己的根基契合
    • 不契合首先造成一种浪费,其次会对自己的职业路径形成障碍。这种选择错位,大致可以有两种表现。
      • 把自己升级使用,这种情形下公司大多时候不干,所以情况不多,但把自己置身在前行无路的状况下却很可能。与上述例子相比,把自己降级使用因为种种原因反倒更常见,所以个人主要力争避免的是别把自己降级使用。
  • 7.2.2 当前可得到什么、将来可得到什么
    • 对短期目标和长期目标的平衡可以从四个维度上进行考察:收入、发展、安稳和兴趣。收入、发展、安稳和兴趣这四个维度所导致的可能选择往往是矛盾的。但如果非要给这四个因素按权重排个优先级的话,更合理的结果是:兴趣>发展>赚钱和安稳。后两者纯属是个人选择,很难清晰区分。
    • 在进行其他说明前,需要补充的一点是这里说的兴趣不是那种很快会来很快会走的兴趣,而是说能够伴随自己一生的偏好。兴趣之所以大于发展是因为人生要想有高度,必须持续的投入,而要想在一生中持续的投入,没有一个关键支撑,那是不可能的。而没有一种持续的投入,最终可达到的高度就会被限定在一定尺度以下。
    • 而这里面很可怕的一个陷阱是一旦你选择了某个领域比如金融,再想跨越到其他的领域比如说游戏,那成功几率极低。因此兴趣是大于发展、安稳与赚钱的权重。但这里有个极容易被误解的东西,那就是虽然兴趣非常关键,但实际上大多数人其实并没有真的兴趣,而会把一时的喜好误认为兴趣,这种兴趣因为会在时间轴上频繁变化而毫无价值,过多考虑这种兴趣会让自己走入误区,为自己造成损伤。这时候要对自己有个清醒的认识,如果自己不是一个对兴趣非常执着,而是做什么都还可以接受的人,那么就可以把兴趣的优先级放在较低的位置上。发展之所以大于安稳和赚钱,道理也很简单。年纪越小,未来越重要,没有个人价值的提高,未来既不会赚到钱,也不会安稳。
    • 平衡这四点之后,就可以找到一些大多时候都适用的选择方法:
      • 知名软件公司在大多时候在这四个方面可以达成很好的均衡,是首先考虑的对象。
      • 软件不是主营的公司在一个或多个方面都有负面影响应该尽力回避。(我现在就在这样的公司,干这样的活,有共鸣)在《软件随想录》里 Joel 说的更直接:千万不要去干什么内部软件,那会把你榨干。
      • 衰落期的公司、分工上处在下游的公司、无核心竞争力的公司并非优选。
      • 越有梦想,越想快速成长,就越适合在一线城市工作。
    • 感受大公司中主营业务的威力?李开复先生的《世界因你不同》里面提到了 .NET 开发在微软内部扭曲变形的过程:在 2000 年的时候,微软决定启动 .NET 计划,那时候规划中的 .NET 和我们现在看到的 .NET 并不相同,那时的目标是基于浏览器可以运行所有的应用软件,和今天的云计算概念非常相似(注意这是 2000 年),电子邮件、即时通讯、登录、 Office 、高质量的打印、机器翻译、人工翻译等都会被整合到网络之中。但一旦开始行动时,李开复先生遭遇了“人的问题”(即是政治问题),待整合的团队有三个: IE 、 MSN Explore 、 NetDocs ,其中 MSN Explore 和 IE 是死对头, MSN Explore 和NetDocs 因为使用不同技术有过节,与此同时,庞然大物 Office 团队则因为 NetDocs 意图取代 Office 而恨之入骨。这种复杂的关系导致从各个团队抽调人员非常困难,最终只有 MSN Explore 被整合到了李开复先生这边,但这个团队只有 100 多人,根本无法开始 .NET 的宏伟计划。正在这时微软的一个一个强势人物:吉姆•阿尔钦回到了公司。吉姆•阿尔钦是 Windows团队的负责人,1995 年开始一直负责 Windows98 和 XP 的开发,他是 Windows 的狂热拥护者,一回来就把.NET 计划批评的一无是处。他说:你们知不知道是谁在付你们薪水?是 Windows!我的血液里流的是视窗的四色血液。你们呢!难道是冷血的?“他又到盖茨的面前威胁如果公司执意而行,他就辞职。在强势威胁后,阿尔钦通过 Windows 的远景说服了比尔盖茨。最终结局是取消原来的.NET 计划,重点还是 Windows,接下来就启动了著名的 Vista 的开发。---上面的案例参照《世界因你不同》缩略而成。上述这样的一个案例落在不同的人眼里,看到的东西应该不同,可能是政治的力量,也可能是其他。这里我想强调的则是强势部门的力量。吉姆•阿尔钦这个人为什么有这么大的影响力?原因可能有很多,但其中一定绕不开的一条是他所负责的 Windows 是微软的根基所在,是主营业务。在公司之中往往可以有很多产品线,但这些产品线往往并非均摊权重,而是要有君臣佐使。这种差异往往会成为内部资源分配、职位晋升的影响因素。在这种情形下,无疑的主营业务相关人等会被重点关注。
• 7.3 小结
  • 让我们再回到最开始时提到的问题:是去大公司好呢,还是去小公司好呢?是去用ASP.net 做 ERP 的公司好呢,还是去做 Mobile 应用的公司好呢?这时答案已经比较清楚了。对于前者,显然是去知名的大公司比较好。对于后者,同等条件下,首先考虑下那个与自己的兴趣契合的比较好,也就是说自己期望在那个行业里做长期发展。接下来要考虑回避掉无核心竞争力的公司。
  • 从起薪看公司的差异

第八章 六个程序员的故事

• 8.1 一个 40 岁程序员的无奈
• 8.2 一个普通码农的退场过程
  • 1、能进大公司就别去小公司,在大公司里你能接受真正正统软件开发教育,比到小公司当个什么啥都干,啥都不精的主管强。2、不断的学习,注意技术积累和更新,那是你唯一的资本。3、做软硬件结合方面的开发,单片机的开发,嵌入式系统的开发,比较有前途而且门槛高。但凡基于数据库的开发,不管是.NET 平台的,J2EE 平台的,VC,DELPHI,PB,VB 都是扯淡,其核心价值是开发人员的经验而不是技术本身。因为真正的核心技术都在国外,中国没有,我发现不管那种语言,最好用的类库或组件都是老外写的。4、要有个好点的学历,别像我一样。毕竟是个高学历的行业,学历低人家都瞧不起你,你的发展也很有限 。30 岁之前,可考虑弄个高程,CCNA,数据库管理员之类比较有含金量的证书打扮打扮自己,过了 35 岁其实意义就不大了。
• 8.3 一个关于项目经理的故事
• 8.4 一个技术牛人的成长经历(杭州李云)
  • 李云是《专业嵌入式软件开发》一书的作者
  • 我想给出我的职场第一感悟:自学能力是竞争力之本。
  • 我的职场第二感悟:自信能让你与众不同,尽管有时的自信有点莫名其妙。
  • 我的职场第三感悟:
    兴趣是学习效率的催化剂,培养自己的职业兴趣。
  • 我的职场第四感悟:学习应给自己设置虚拟的项目目标,以做项目的形式提升学习效果,只有这样学到的内容才会深入而实用,切忌无目标地学到哪算哪。
  • 我的职场第五感悟:话语权首先来自能力,而不是职位权力。
  • 我的职场第六感悟:难学的技能一旦掌握更具竞争优势。
  • 我的职场第七感悟:用阶段性成果不断增强自己的自信,但最终支持自信的是能力,而不是自大。
  • 我的职场第八感悟:做自己喜欢的事,如果那是自己的兴趣最好。
  • 我的职场第九感悟:不论身处多么困难的环境,即使觉得前途渺茫,也不要放弃学习,否则就是“自断筋脉”。
  • 我的职场第十一感悟:机遇很重要,但你得有能力才能抓住它。
  • 我的职场第十二感悟:职场首先比拼的不是智商,而是坚持与好习惯。
  • 我的职场第十三感悟:当短期利益与长远利益无法得兼时,选择长远利益。
  • 我的职场第十四感悟:学历是很重要的敲门砖,即便你的能力很强;学历尽管很重要,但能力才是最终的通行证。
  • 我的职场第十五感悟:技术细节掌握得越深,解决问题时就越能游刃有余。
  • 我的职场第十六感悟:技能的发展应采取深度先于广度且交替进行的方式,只有这样,面对大量的新知识才能更淡定。
  • 在我的职业生涯中,我一直热衷于去解决别人难以解决的技术问题,这是因为我的职场第十七感悟:越难的技术问题,其所蕴藏的知识越丰富,也越具学习价值。
  • 在职场中,我不时能成功解决复杂问题和克服技术障碍。这与我的职场第十八感悟是分不开的:每次积累的点滴知识,一定会在将来不知不觉地发挥效能。
  • 我始终坚守我的职场
    第十九感悟:通过文档化的方式传承知识给后继者是你的基本责任,因为你作为后继者时也希望如此,这也是对自己负责的一种表现。
  • 我职场第二十感悟:别人对你价值的认可,其实不是简单地根据你的自身能力,而是根据你对他人和团队的贡献。
  • 对于自认为英语听说能力不行的同仁,请记住我的职场第二十一感悟:英语的听说能力只要有合适的环境,并勇于张嘴练习的情况下能快速地提高,不必担心。
  • 我的职场第二十二感悟:在软件开发活动中,应设法通过有效的技术途径去解决工程困境。
  • 我从亮身上学到的第一个内容是如何与美国管理层打交道。总体说来,Motorola 在软件开发管理方面很是四平八稳,其管理存在两大特色,一是争夺项目的所有权(Ownership),另一个是质疑(Challenge)。前者使得各团队职责清晰,不容易出现突发问题或状况找不到负责人;后者使得团队在工作中有所作为,不至于让人浑水摸鱼。在面对美国团队的质疑时,我以前看到的大多管理者都很紧张,总想一味地达到美国方面的要求,但亮在这方面的表现却明显不同。他告诉我们(包括 Team Leader):“如果美国提的要求不合理,直接与他们‘掰’”。后来我认识到,美国方面做事其实很讲逻辑,只要我们对于他们所质疑的问题能给出合理的解释,很多异常事件根本就没什么大不了。我的职场第二十三感悟:不要用沉默的方式一味地迎合别人的要求,据理力争或许才是作为的表现。
  • 尽管我们常将“职业规划”挂在嘴边,实际上职场发展真的是一种“布朗运动”。你不知道下一站会是哪、也不知道后面将要从事什么工作、更不清楚后面会碰到怎样的老板。在众多不确定因素面前,或许参照我一路走来所总结出的职场感悟能让你不断地朝好的方向发展。
• 8.5 一个创业者的十年
  • 不是创业不好,而是说输不起的人不适合创业,而很不辛大部分人其实是输不起。
  • 戴志康和他的 Discuz!
    • 创业的初期,技术、资金、人脉、主意等等,都可以看成是一个个筹码,创业者所主要要做的就是要把你的筹码转换为持续不断的现金流。随着现金流的不断放大,这个人的创业故事也就越来越成功。
    • 在考虑创业前,在考虑巨大收益前,要考虑自己是不是付得起创业的基本代价。
• 8.6 一个女程序员的编程之旅
  • 工作与生活的关系:工作与生活究竟应该是怎么样的一种关系?这又是一个没有也不应该有唯一答案的问题。人生很多事其实是个可伸缩的模型。理想重要么?当然很重要,但当饿到一定程度时,对绝大多数人,理想就没有馒头重要。工作比生活重要么?生活比工作重要么?一这么考虑问题,脑子必然永无宁日。如果把活着定义为生活,那么工作其实是生活的一部分。一个人最好的时光往往是在工作中度过的。但工作确实和家庭生活有对立的一面。人的时间就那么多,一边花的时间多,一边的时间必然就少。如果我们相信吃饭是人生最关键的事情,也相信贫贱夫妻百事哀这样的俗语,在没有彻底的财务自由之前,家庭里至少要有一个人要工作优先。这很功利,但没办法。当代中国,家庭的基本模式几乎是固定的:两个独生子女组成家庭,一旦有了孩子之后,要么一人不工作,要么从父母双方获得帮助。而随着上一代人的老去,自身的责任必然加重。在这事儿上大部分人选择权真的不大,必须工作优先,这是一种现实约束。在这个步骤里,家庭要争取自己的选择权,无疑的争取到了财务自由的家庭是幸运的,他们可以重新规划自己的生活模式。这个时候仍然可以选择继续工作,但意义已经不同,并非是因为外部的什么压力才这么做,更主要的是因为自己想这么做才这么做。这是一种值得期望的状态。从这个角度看,在人生这个舞台上,年轻的时候一个人所扮演的角色是带着面具的,只有财务自由后的演出才是本色出演。
• 8.7 观罢六段人生,体验是非成败

结束语