沟通之痛：如何改变
沟通，越发成为一件重要的事，至少和写代码同等重要；沟通清楚了，能让我们避免一些无谓的需求，少写不少无效的代码。
需求没沟通清楚，写出来的代码，即使没 Bug 将来也可能是负债。不是自己还就是别人来还。
1. 以理服人：对事不对人，切勿意气用事。
2. 以德服人：请公司所谓的经验丰富、德高望重的“老司机”来裁决
3. 以力服人：看双方部门老大或老大的老大，谁更有力或给力。
认识与改变：做出改变的第一步是要能认识到，否则改变不可能发生。
内容
形式：面对面谈话，写作，代码等等
风格：一对一谈话，演讲、汇报和会议等等
换位思考：虽说你想沟通的本质是同一样东西或事情，但针对不同的人，你就需要准备不同的内容。
判断一个程序员是否具备 “换位思考” 的能力有一个好方法，那就是看他怎样向没有技术背景的人解释技术问题。
沟通之难就在于清晰地传递内容和观点。可以尝试
1. 写点你自认为已经熟悉掌握的技术，并交给读者去阅读与评价。
2. 每过一段时间（比如，一个季度或半年）尝试去总结，然后给同事分享下你工作的核心内容，再观察同事们的反应和听取他们的反馈。
沟通改变的第一步就是从考虑接收方开始的，看看接收方能吸收和理解多少，而非发送了多少。
沟通问题的三个方面——内容、方式与风格——的考虑，都是为了让接收更方便和容易。
沟通问题的本质是要方便接收，达成共识，保持换位思考和同理心，改变自会发生。
【补充】
表达、沟通和协作是程序员非常重要的软技能三部曲。
技术停滞：如何更新
技术停滞
习得甚至精通一门技能，最著名的理论应该是 “刻意练习”，如果非要在这份练习上加上一个期限，那就是：一万小时。要点有三：
只在 “学习区” 练习，练习时注意力必须高度集中。
把训练的内容分成有针对性的小块，对每一个小块进行重复练习。
在整个练习过程中，随时能获得有效的反馈。
厚积薄发：日常训练都是在 “学习区” 的刻意练习，上场比赛则是进入 “舒适区” 的自动完成。
技术停滞的原因：熟练程序员的日常工作则是在 “舒适区” 的自动完成，工作之外则是另一种 “舒适区” 的娱乐休闲。
技能保养
保养和提升技能的方法，“刻意练习” 依然是不二之选。
有时我们即使一直保持在 “学习区” 的重复练习，却也可能感觉不到进步，这有可能是因为重复的次数和强度还不够。一天一小时一年也才365小时
重复，是有针对性的强化练习，其本身是练习过程，而非练习内容。每一次的重复过程中都需要根据反馈进行有针对性的调整，以取得练习效果的进步。
而重复的刻意练习总是辛苦的，辛苦就是我们付出的技能保养成本。
技能开发
技能不仅仅会停滞，还有可能会过时。
深度路线学习：解决一个具体问题
痛点驱动式方法:需要学习新技能来解决工作上的一个具体问题,能让你快速排除障碍，解决问题，而非先找到相关书籍，从头读到尾，知道一个整体大概。
广度路线学习：对新技术方向做评估、判断和决策
一般技术书籍的组织方式都是按主题的相关性来编排的，系统体系性很强，但却不是按你解决问题需要知道的内容来组织的。
所以，技术书籍更适合于在你解决问题的过程中用来参考。完整地读技术书籍能增长你的知识，但却无法快速习得技能，并解决你的问题。
十步学习法：
了解全局
确定范围
定义目标
寻找资源
学习计划
筛选资源
开始学习，浅尝辄止
动手操作，边玩边学
全面掌握，学以致用
乐为人师，融汇贯通
沉淀能力
技能（skill）是你习得的一种工具，那么能力（ablity）就是你运用工具的思考和行为方式，它是你做成一件事并取得成果的品质。
技能用熟练了就成了工具，熟练应用工具能快速解决已碰到过的老问题。
而沉淀下来的能力，是为了应对并解决新问题，甚至为了解决新问题，可以去开发新的技能或创造新的工具。
1 代码能力。能够写程序，只能算是技能过关，而能写好程序，才算具备了程序员的基本代码能力。
维护一份公开可跟踪的记录，比如参与开源项目贡献，在 GitHub 上留下你的代码简历。
“架构”显然不是一种技能，而是综合应用多种技能的能力。代码能力是架构能力的底层能力要求。
2. 了解下产品、管理、运营和传播等方面的能力。
一方面，技术能力的提升总会到达平台期，增长变得缓慢，
而了解学习一下其他方面的全新能力，可能会让你找到新的成长点，重新找回快速成长的感觉。
个人综合能力依靠“作品”来体现，完成作品需要有一些产品思维，需要自我规划与管理能力，而推广作品需要运营和传播能力。
如果你是一棵树，能力是根，技能是叶；
持续保养主要的生存技能，合理开发辅助技能，形成自己独有的技能组合，沉淀能力模型，发展能力矩阵。
【补充】
技能是招式，能力是内功
无法实现：困扰与反思
一、困扰
程序员口头禅：“技术上无法实现！”==成为了遮挡我们因不知而畏惧的面具。
“逻辑太复杂，变动太大，这短期在技术上无法实现的。”，只是因为觉得很麻烦，不愿意而已。===成为了我们推脱的借口。
反思
不论是 “不知” 还是 “不愿”，“技术上无法实现” 的口头禅看来都不会给我们带来什么帮助，
它反而阻碍了我们进一步做出更好的产品，从而给客户留下遗憾。
大部分的用户需求，技术上总是可以实现的。这些需求的真正限制，要么是时间，要么是资源。
我们应该把这样的问题放在框架中去思考下：
1. 全局背景:对这一问题涉及主题的相关内容有一个全局性的了解。分析用户碰到这样的问题可能的原因有哪些？
2. 聚焦范围：从全局分类中，聚焦一个范围，然后集中深入调研评估。
3. 定义标准：清晰定义问题解决的成功标准。
4. 深度评估：有了范围和标准，深度评估方案路径问题。有些是你已经轻车熟路的实现路径，有些可能是你从未走过的陌生之路。
评估，可以保守一些，因为一般来说现实总是比理想的路径曲折一些的。
还需进一步斟酌方案是否足够优化，做工程就是要找到一条最优化的实现路径。
即使真的是“技术上无法实现”的需求，也有可能通过变通需求的方式来找到一条可实现的路径。
完成作品：理想与现实
理想：作品与创作
作品最重要的特质是：创作与创意
你从网上复制来一段代码，解决一个问题，这不是创作，也不会成为你的作品。
代码作品，可以小到一段函数、一个类，大到一个库或框架、一个服务，甚至一个系统。
但打磨代码作品的方式，应该是定期对自己写完的代码进行沉淀、梳理和规整，提取可复用的功能，同样的功能只写一次，形成自己专属的编码脚手架和代码库。
在以后的学习实践中定期反思，不断优化其效率和品质。
当你再碰到类似功能的实现时，能直接复用库就复用库，不能直接复用的就在脚手架代码上进行扩展，后续的重心就放在了优化实现思路上。
留下的代码库或脚手架都成为了你的作品。
优秀作品的秘诀就是：非常严格的品味，再加上实现这种品味的能力。
完成作品的收益是什么？
不一定直接从作品中获得经济收益，但在打磨作品的过程中让你掌握系统化的知识和体系化的能力，同时还会让你的作品变得更值钱。
当你给别人介绍自己时，只需要介绍自己的作品，而不再需要介绍自己的技能。
现实：产品与特性
作品要实现直接的经济收益，必须还要走完从作品到产品之路。
要做好技术需要懂业务和产品。懂的是方向不是细节。
技术需要懂的是产品提供的核心服务和流程，并清晰地将其映射到技术的支撑能力与成本上。
技术不仅仅需要支撑满足产品的全部显性和隐性服务特性，还要注意技术的隐性特性，即非功能性需求
显性的错误会有测试、产品甚至最终用户来帮你纠正，但隐性的错误却很难有人能及时帮你发现并纠正。
技术从特性到作品，去支撑产品的体验与服务，这是一条更现实的技术作品实现价值的路。
代码评审：寄望与哀伤
现实中都知道代码评审（Code Review）很有用、很重要，但在项目中却很难落地执行
感性认识
代码评审的初衷是提高代码质量，在代码进入生产环境前经过同行评审来发现缺陷，降低损失概率。
程序员在写程序时力求思考全面，不留死角或盲点，但实际死角或盲点总是存在的。
相互进行代码评审弥补了个人单一视角和认知思考的盲点问题，而且影响编程的姿势和心态【因为知道一定会有同事将检查你的代码而更谨慎】
理性分析
代码评审对于发现潜在缺陷很有用，相比测试能发现的缺陷率高一倍。
一般的代码审查速度约是一小时 150 行，再快就不利于发现潜在缺陷了，而且更适用于长生命周期的产品。
而业务项目，特别是尝试性的创新业务，需求不稳定，时间要求紧迫，并且其生命周期还可能是昙花一现。
困境
困境一，项目期限 Deadline 已定，时间紧迫，天天加班忙成狗了，谁还愿意搞代码评审
困境二，强制推行下去，如何保障其效果？团队出于应付，每次走个过场，那么也就失去了评审的初衷和意义。
困境三，团队人员结构搭配不合理，新人交叉评审可能效果不好，而总是安排经验多的少数人帮助 Review，对其发展未必有利
困境四，有人就是不喜欢别人 Review 他的代码，他会感觉是在找茬。
参考路径
在 Google，任何产品，任何工程的代码，在被进行严格或者明确的代码评审之前，是不允许提交的。
有公司制度和规则的强硬支持，再辅助自动检测和控制工具的严格执行
现实
给自己 Review 是一种自省，自我的成长总是从自省开始的。
代码评审，能提升质量，降低缺陷；
代码评审，也能传播知识，促进沟通；
代码评审，甚至还能影响心理，端正姿势。
代码评审，好处多多，让人寄予希望，执行起来却又不免哀伤，
也许正是因为每一次评审的收益是不确定的、模糊的，但付出的代价却是固定的，包括固定的评审时间、可能延期的发布等。
人到中年：失业与恐惧
人到中年，突然就多了一些恐惧感。
恐惧感：谋生
中年，每个月比年轻那会儿挣得更多了，职位也更高了，生活变得更安适和稳定，这时真正潜伏着的威胁开始出现：
技能的上升曲线可能越过了高点，走入平缓区，甚至也许在以缓慢而不易觉察的方式下降，而我们却安之若素。
中年，像是中场的哨声，提醒我们人生的上半场快结束了，短暂的休整之后，就该提起精神开始下半场了。
所以恐惧感不应是一种束缚，而是一种警醒。
无惧感：舍生【这一段非常好，全部摘记====置之死地而后生，陷之亡地而后存】
假如你在一份工作中，对丢掉工作本身产生了恐惧，那你做工作的形式很可能会走向谨小慎微。
这时工作让你产生了恐惧感，你就将会被工作绊住，只想兢兢业业、如履薄冰地做好份内工作，以保护好自己的位置。但为了保护位置所做的所有努力都会是徒劳的，因为恐惧感绊住了你，这样的工作状态，自己也是缺乏信心的，而一个对自己信心不足人，也很难让别人对你产生信心。最终，几乎没有任何办法阻止别人占有你当前的位置。
而偏偏是要对工作的无惧感才能真正释放你的潜力，发挥你的能力，让你能够留在原地甚或更进一步。
作为程序员，我们只有一个位置：专业阵地。这是一个专业性要求比较高的职业，我们被雇佣并要求成为一名专业人士，所以应该像一个专业人士一样行事。普通劳动者和专业人士的区别在于，普通劳动者主要被动接受指令去执行任务，而专业人士则在其领域内自己生成指令，同时在领域外还会向同事或上级提供来自该领域的输出：专业建议。
普通劳动者是一种劳动力资源，他们保证执行，而专业人士则是保证选择的执行方向是有意义的，执行路径是优化的。作为专业人士，我们需要去坚持和持续地打磨专业力，守住这块阵地。
有时我在想，是专业让人拥有无惧感呢，还是无惧了才能走向更专业？也许，“谋生的恐惧”害怕失去的不过是工作岗位，“舍生的无惧”才能塑造专业的职业生涯吧。
安全感：重生
最可怕的失业就来自变革引发的技能性淘汰（如：国企下岗），
其次是环境引发的萧条（如：金融危机），
再次是技能虽然还有普适价值，但自身却适应不了环境变化带来的改变与调整（如：外企适应不了互联网的危机）。
中年人和年轻人本应在不同的战场上。
年轻时，拼的是体力、学习力和适应能力，是做解答题的效率与能力；
中年了，拼的是脑力、心力和决策能力，是做对选择题的概率。
年轻时，是用体力和时间积累经历，换取成长与机会。
中年了体力下降是自然生理规律，但和脑力有关的学习能力并不会有明显改变。
跟年轻的大脑相比，中年大脑在两个方面的性能是下降的：计算速度和注意力。
其他方面，比如模式识别、空间想象能力、逻辑推理能力等等，性能不但没有下降，而且还提高了。
完全没必要担心 “老了” 会导致学习能力下降。
缺乏安全感，正是源自变化，变化带来的不确定性。
我们没法消除变化，只能把变化纳入考虑，承认变化是永恒的，不确定是长期的。战胜自己人性里的另一面 —— 适应变化
无论世界怎样变化，内心依然波澜不惊，就像大海深处，无论海面如何波浪滔天，深处依然静谧悠然。
简言之，人到中年，转换了战场，重新定位自己的优势，转变核心竞争力，浴火重生，开启人生的下半场。
年轻时，我们打的是突击站，左冲右突；
中年了，我们打的是阵地战，稳步推进；
如今，我们进入了人生的中场战事。这场战事
从谋生的恐惧感开始，给予我们警示；
到舍生的无惧感，让我们摆脱束缚，整装待发；
最后经过重生的安全感，推动我们再次上升。
该不该去创业公司
期望
为什么要加入创业公司，你的期望是什么？也许有下面几种原因：
自由成长==相对于大公司过于拘束，缺乏自由度，专业分工很精细
创业公司能接触的东西更多，需要处理的问题也更多、更杂，让人更容易自由成长为一种解决各类问题的多面手。
变身土豪：加入创业公司就是用你的时间下注，能否撞上 100 倍的机会，很多时候就是靠时运。
最早期的创业公司，大概处在天使轮阶段。作为技术人，以技术合伙人的身份加入，大概拿到公司占比 5% 左右的期权。
关键点在于，从天使轮到上市途中，统计数据上显示会倒下 99% 的创业公司。
如果创业公司进展到了 A 轮，加入可能成为一名高管，分到的期权会少一个量级，大约 0.5%
如果创业公司进展到了 B 轮，加入成为一名高管的可能性更低要求更高，分到的期权会少一个量级，大约 0.05%
如果创业公司进展到了 C 轮，加入基本不会成为高层，分到的期权下降一个量级到 0.005%
追求梦想：创业做的事情正是你梦想的、喜欢做的事情
创业公司通常不希望招一个只要高工资，不要公司期权的人吧。
加入者给期权的正确估值应该是0，因为期权的兑现日期你无法预期，也许是五年…也许创业的失败，一开始不要寄予太多期望。
你应当确保自己的工资报酬至少可以接受，即使合同中没有期权，你也仍然会选择加入这家创业公司。
二、条件
1、创始人创业的目的是什么？期望是什么？大家的目的、价值观、期望差距不可太大，否则必然走不长远
2、创始人以前的口碑和信用如何？
3、公司的核心团队成员如何？
4、对你的定位是什么？避免被title吸引，解决完公司当前技术瓶颈后被弃之不用。
5、公司是否有明确的业务方向？业务的天花板多高？有哪些对手？相对竞争的核心优势是什么？
三、决策
将客观的外因分析+主观的内省 匹配
“满意决策”：前 1/3 的路程就是在决策前充分观察、调研、确定你的满意标准，之后面对第一个满意对象就能够直接决策，然后继续快速前行。
做完决策不纠结，即使后来回头看离最优还有差距，也不遗憾。
【补充】满意标准的建立，让我们有足够的定力，看清楚外部的诱惑，也让我们有足够的动力，推动我们前进，摆平事情。
该不该接外包
赚钱与诱惑
外包的直接诱惑，就是能立刻增加工资之外的收入，赚点外快。
程序员赚钱的方式大概有：
咨询/培训
演讲/分享
投稿/翻译
写书
写博客/公众号：博客是免费阅读，公众号开创了阅读打赏模式
课程/专栏
兼职/外包：外包平台模式，平台发布项目，程序员注册为签约开发者，按人天标价，自己给自己的人天时间估值。
短期的直接收入回报诱惑很大，消耗的是时间成本，疲于奔命导致个人生产率增长的停滞，未来竞争力的下降。
成本与比较
三条建议：
1. 不要让债务的增长速度超过收入。
2. 不要让收入的增长速度超过生产率。
3. 尽一切努力提高生产率。
外包带来的收入是一次性的，不具备积累效应，长期的代价必然是个人生产率的降低，得不偿失。
应该尽可能地在提高个人价值的同时提升价值产出率
值钱与选择
选择做赚钱的事，还是值钱的事？
赚钱的事，核心是当下的利差，现金现货，将本求利。
值钱的事，核心是结构性价值，兑现时间，在某个未来。===以个人价值增值为出发点
为了多赚点外快牺牲当下所有的业余时间，这值得吗？这种兼职外包项目对于自身的价值增值有多大的帮助？这是你需要反问和思考的问题。
真正拉开差距的阶段是在工作的十年到二十年之间，所以前十年不妨把关注的焦点放在个人价值的增值上。
【总结】值得接的外包，它包括下面一些特性：
如果外包项目对你的技术积累有好处，那么收点钱去实践提升下正好一举两得；其实参与开源项目，本质上不就是不收钱的外包项目？它的收益就是让你更值钱。
外包项目的成果具有可复制、可重用性，这样就可以通过大量复制和重用来降低一次性开发成本；而成本和比较优势才是外包模式的核心竞争力所在。
外包项目不是临时一次性的，而是需要长期维护的，而这种维护的边际成本可以依靠技术工具手段不断降低，那这样的外包项目就是一个长期赚钱的 “机器” 了。
去做值钱的事，打造值钱的结构，从知识结构、技能结构到作品结构与产品结构，然后等待某个未来的兑现时间。
技术干货那么多，如何选
循证与决策路径
技术干货：通过分析别人走过的路径，来拨开自己技术道路探索上的迷雾。
循证方式的技术决策路径：基于实践的证据、来自历史项目或亲自试验的经验……
我们去阅读技术干货文章，想从别人的分享中获得对自己技术方案的一个印证。
这就是一种行业的实践证据，毕竟想通过听取分享去印证的，通常都是走过了一条与自己类似的道路。
循证的方式就是：即便你看到了一个更好的技术与架构方式，但也要结合自身的实际情况去思考实践的路径。
切磋与思考方式
切磋不会再纠结于为什么我们不同，而是去看到它的好处与代价。
切磋带来的思考是：你不能看见别人的功夫套路好，破解难题手到擒来，就轻易决定改练别人的功夫。表面的招式相同，内功可能完全不同
切磋，主要是带给你不同的思维方式，用自己的功夫寻求破解之道。
连结与知识体系
干货优先级的选择阅读问题：基于功利性和兴趣
把过去自己所掌握的所有技术总结编织成一张“网”，若一个技术干货分享的东西离我的“网”还太远，我就会放弃去了解。
因为如果不能连结到这张“网”中，形成一个节点，我可以肯定它就很难发挥任何作用，很可能是我看过之后没多久就遗忘了。
我们应该将已知的部分连结上新的知识和实践，形成更密、更牢固的技术体系之网。
从干货中提取知识和经验总结，形成对已有知识的连结，不断加固并扩大自己的技术知识体系之网。
一定要带着问题去织网: 这个技术为什么会出现？能解决什么问题？可用于什么业务场景？适用的条件是什么？特点 (优点与不足)是什么？
总结来说：面对众多的技术干货，从循证出发，找到参考，做出技术决策，决定后续演进路线；
在演进路上，不断切磋，升级思考方式，调整路径，走出合适的道路；
在路上，把遇到的独立的知识点，不断吸收连结进入自己的技术知识体系之网。
技术分歧，如何决策
在一些技术评审会上，程序员就技术方案产生分歧与争论。作为架构师或技术 Leader，站在技术决策者的立场和角度，该如何去解决分歧，做出决策呢？
决策的本质是总成本最小，总收益最大。
“康威定律”：
任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。
康威定律告诉我们系统架构的设计符合组织沟通结构时取得的收益最大。
康威定律，是和组织的团队、分工、能力与定位有关的，其本质是最大化团队的核心能力，最小化沟通成本。
后端的同学和前端的同学经常就一些技术方案产生争论。而争论的问题无所谓谁对谁错，因为同样的问题既可以后端解决，也可以前端解决
争论各自基于局部利益的出发点，让自己这方更省事罢了。
最佳的选择只能是将前后端整体全盘考虑，以成本和效率为核心来度量，应该由哪方来负责这个临界区。
成本与效率背后的考量又包括如下因素：
团队：这是人的因素，关于团队的水平，掌握的技术能力和积累的经验；
环境：能利用的环境支持，公司内部的平台服务或外部的开源软件与社区；
技术：技术本身的因素，该项技术当前的成熟度，潜在的发展趋势；
约束：其他非技术约束，比如管理权限的干涉、限定死的产品发布日期等。
技术没有绝对的标准（数据库设计有范式，就有反范式设计，程序语言有设计模式，就有反设计模式），适合的技术决策，总是在受限的约束条件下，围绕成本与效率做出的选择权衡。
对于一些纯粹的技术理想主义者，追求技术的完美与合理性，初心本不错，但也许现实需要更多的行动柔性。