信息：过载与有效
“忙碌、充实而疲倦”的虚幻假象
在这个信息过载的洪流中，需要的就是在这股洪流中筛选信息并建立自己中流砥柱般的 “知识磐石”。
心智” 这两个字合在一起是一个意思，分开为 “心” 和 “智” 两个字又可以分别解释为：“心” 是你对需要的选择，从心出发；“智” 是对价值的判断，智力的匹配
应用：一击中的
储备了信息，建立了知识，最终都是为了应用。
囤积信息，学习知识，如果不能被应用在改变自己上，那还有什么意义？
没有目的的学习是徒劳的，它仅仅是在我们的头脑中流过一遍，流过的痕迹很快又会被新的信息冲刷干净。不管我们拥有怎样的 “最强大脑”，在面对这股信息与知识洪流时，都几乎可忽略不计。
你得挑选那些真正值得做和学的东西去让大脑满负荷运转，但凡投入决心去做的事情，就需要百分百投入。
这就是专注于少而精的东西，深入了解这些东西，进入到更深的层次上。深可以无止境，那到底多深才合适？
我的答案是：让你的内心对取得的效果感受到满意的深度层次上。它的反面是：但凡心存疑虑，不是那么确定要全力投入的事情，干脆就不做了。
做得多和做得好的感觉很不一样。就像拳击，多，好似不停挥拳，很快就精疲力竭；好，则是看准目标，抓住机会全力出击，一击中的。
【总结】
总结下在信息爆炸的时代，我们该如何有效处理、吸收和消化信息：
信息过载是现实；
疲于奔命是陷阱；
心智模型是方法；
一击中的是策略。
领域：知识与体系====点线面体
点：
ABC 的时代（其中 A 是 AI ，人工智能；B 是 Big Data，大数据；C 是 Cloud，云计算）
如果你总是这样被客观的原因驱动去随机点亮不同的 “点”，那么你终究会感到有点疲于奔命，永远追不上技术的浪潮。
线
当形成的点足够多了后，一部分点开始形成线，而另一些点则在技术趋势的演进中被自然淘汰或自己主动战略放弃。
一个个点，构成了基本的价值点，这些点串起来，就形成了更大的价值输出链条。
【由点连线，形成T型，先向下，再向旁边。先深，后广】
组织力-掌控力-领导力
|
业务和产品
|
分布式架构与设计
|
Java
|
JVM
|
Linux(os)-->docker
|
网络
|
面
线的交织，将形成面。
【补充】SDK 就是 Software Development Kit 的缩写——软件开发工具包
可以把SDK想象成一个虚拟的程序包，在这个程序包中有一份做好的软件功能，这份程序包几乎是全封闭的，只有一个小小接口可以联通外界，这个接口就是API。
有一杯密封饮料，它的名字叫做“SDK”。
饮料上插着吸管，吸管的名字叫“API”。
SDK＝放着你想要的软件功能的软件包
API＝SDK上唯一的接口
当你对整个业务面上的价值点掌握的更多，能抓住和把握核心的价值链条，去为更广、更大的价值负责，那么你就能克服自己的成长发展困境，找到了另外一条出路了。
体
体是经济体或其中的单元。
你的 “面” 附着在什么 “体” 上决定了它的价值上限。如果 “体” 在高速增长并形成趋势，你就可能获得更快的发展。
“体” 的崛起，是时代的机遇。
【总结】
在领域知识体系中，“点” 是利器，“线” 是路径，“面” 是地图；而就我们个体而言，“点” 是孤立知识点的学习掌握，而 “线” 是对这些点的连接，“面” 则构成了完整的知识体系网。
转化：能力与输出
个体
个体的能力输出像出拳
经过职业训练的拳击手，正常挥出重拳的力量可以是体重的好几倍。
身体是一个系统，身体架构是一个体系，这个体系的输出能力便是出拳的力量。
团队
团队的输出就像战争
团队这个体系比较复杂，即使个体的点很强，但仅仅是点的强化，也有可能不断赢了战役，但最后却输了整个战争。
“机器” 体系的三个核心点：
流程规则，建立其运行轨道【如何运转】
工具系统，支撑其高效运行【监视和控制这个体系的运转效率与效果】
规范共识，形成了协调合奏【和谐”运转】
转化
从个体到团队，都是通过搭建体系来积蓄力量，再通过体系的运转来输出能力
共同思维方式是：体系化、工具化。这是一种标准的工程师思维模式
体系，从工程维度看就像生产流水线，而体系的运转就是开动了生产流水线。
搭建并调校出一条高转化输出能力的体系生产线，是真正具有核心竞争力和护城河的事情。
好产品或好结果并不能成为支点，不断产出好结果或好产品的 “体系流水线” 才是。
并行：工作与学习
工作
程序员的主要工作是：编程，产出代码，完成需求，交付程序系统。
Done is better than perfect.
比完美更重要的是先完成。
有同事工作的时间不短，经常加班加点，工作也很勤勉，但每每晋升时却碰壁了。隐藏在背后更深层次的原因是：工作陷入了循环与重复，从此停止了成长。
很多人比较容易被卡在不断地在完成工作，但却没有去反思、沉淀、迭代并改进，导致一直停留在了不断重复的怪圈之中。
学习
持续学习，是让你突破不断循环怪圈的不二法门。
现如今是个信息爆炸与知识过载时代，所以学习必须要有选择性
学习还是要聚焦和主动选择，毕竟你的精力和时间都是有限的。而有选择性的学习就需要找出真正与你近期规划有关的学习路径。
对于学习语言本身我觉得最高效的方法就是看一本该领域的经典入门书。比如，对于 Java 就是《Java 核心技术》或《Java 编程思想》，这是我称之为第一维度的书，聚焦于一个技术领域并讲得透彻清晰。
第二维度的书，比如：《Effective Java》《UNIX 编程艺术》等，这些是聚焦于特定领域经验总结型的书，这类书最有价值的地方是其聚焦于领域的思想和思路。【不要过早地看，否则没什么帮助，甚至还会可能造成误解与困扰】
关于技术学习我们不能简单地蜻蜓点水、复制粘贴、拿来主义，应是去建立你的知识 “金字塔”，形成体系结构，而每次的学习实践都是在不断完善你的 “金字塔”。
Source Code源代码
API Reference（应用编程接口参考）
技术规范 spec
Tutorial（指南）
【补充】
没时间只是表象。实质可能是：
1.没把事情列优先级，大量低优先级事情侵占了时间
2.没列计划，想到什么做什么。表现为：一段时间很多事情做，一段时间不知道做什么。需要列出短期，中期，长期的目标和计划
3.用忙碌来来掩盖自己思想的懒惰，不愿去思考和总结经验。用句时髦的话就是：用战术的勤奋去掩盖自己战略的懒惰
路径
选择走最适合实现个人价值的路。
任何一个你所尝试提升的事情都有一个增长曲线，这个曲线有两种形态：
对数增长形态：这种类型在初期增长很快，但随后进展就越发困难；
建议你在起初的高增长阶段，学习和工作的关注点需放在养成长期习惯上，坚持形成自己的习惯和节奏。
指数增长形态：这种类型在初期增长很慢，但存在积累的复利效应。
指数增长则意味着存在一个拐点的 “突变” 时刻。许多人在拐点发生前就放弃了。
成长这条路从来都不是笔直的，你的“奔跑速度”也不会一直是匀速的。在每一个拐弯处，都应减速，思考，学习，然后再加速，进步。
时间：塑造基石习惯（上）——感知与测量
养成好的习惯能帮助我们更快地成长，而在所有的好习惯中，关于时间的习惯是其中的基础，我称之为 “基石” 习惯
感受时间
测量时间
我会记下一年来经历的所有有意义的事件（除去每日的例行工作），我称之为 “时间日志”。
记录与测量时间的实践：记时间的账，记时间明细，借此以追踪我的时间都花在哪里去了【事件-时间日志】。
过去的你也许不曾是时间的旧爱，但未来的你可以成为时间的新欢
时间：塑造基石习惯（下）
为了更有效地利用好你每天有限的时间，就需要你重新审视并调整你的时间切割与构建方式。
切割时间
转换一下你看待时间的方式
将时间切割成建造你心中“大教堂”的合适“石材”。
记录测量时间，让我对时间的感知更精确，而面对自然产生的每天一块的“时间原石”，每个清晨就要确定：把它切成什么样？由哪些石块组成？哪些是用来建造大教堂的石材？
确定后，将其压在心上，临睡前再记录下今天从心上搬走了哪些石块，以及花了多少时间。
构建方式
适当的构建方式，是指在时间的 “基石” 习惯之上，建立其他的习惯。
任何行动的发生，都需要两种努力才有可能：第一种，是行动本身固有需要的努力
第二种，指决策是否执行这种行动的努力
构建习惯的目的，以及它们能起作用的原因在于：它能消除行动中第二种努力的决策消耗。
如果你只做能力范围内的事，就不会成长。所以，在时间 “基石” 习惯之上构建的习惯应该是你能力范围之外的行动。
点与点之间越近，所耗费的线（成本）就越低。
如果你要构建一个习惯，就要运用好基因中本已存在的关于 “采集和狩猎” 的本能：高度专注，跨出边界，持续交付。
【总结】
要形成时间习惯，要通过有意识的感知和测量来发现时间是怎么流失的。
要完成建设你心中 “大教堂”，要通过切割 “时间原石” 来完成 “时间石材” 的准备。
在养成了时间的基石习惯之上，挑选和构建其他习惯来完成 “大教堂” 的持续建设与交付。
试试：一种“坏”习惯
好的出发点
“试一试” 的初衷本来就该是好的，它表达了一种好奇心，以及尝试走出舒适区的勇气。
“试一试”?“坏”习惯
模糊的终点
试一试”的“坏”习惯的“坏”，在于它的出发点本是好的，但如果终点是模糊的，那就“坏”了。
到底为什么你会想去尝试一种新技术？是你仔细思考后的主动选择，还是说或多或少又被技术潮流所裹挟？
对于新技术如果我们不想将其作为职业，建议了解三件事：作为提升我对于这个热门技术的判断力。
它的原理与应用场景；
它的前世今生；【知道哪些方面已经有了成熟的方案，哪些地方还在青涩的探索期】
它如今已抵达的边界【如何定义清楚需要，形成合理的技术方案】
试一试，需要有更清晰的终点。：
验证猜想。引入一种新技术或框架，验证 API 的调用结果或运行输出是否如你所想，即使最终否决了，那你也获得了判断的依据与知识。
收获结果。定义清楚你尝试的这件事，到底能收获怎样具体的结果。比如：考试，尝试的收获就是要通过。
体验过程。有时候结果并不确定，比如，创业的结果未必就一定是成功，那么这样的尝试难道就没有意义了吗？有的，因为创业的超低成功率，所以，体验过程恐怕多于收获最终结果。
理解现实。你尝试一个新东西或学习一个新知识，有时未必真是为了将来有朝一日能用上它，而主要是为了完善你的知识与认知体系，然后再去理解现实为什么是这样的。
现实的路径
“试一试” 的路径是有限的，毕竟终究离不开现实的约束。
面对现实==工作需要
理解现实==从学以致用的角度很快就过时了，但知识并不是完全孤立的，有相互的联系与连接点。
以自己的知识体系为中心，有选择地尝试对你更有意义或价值的事。
【总结】
试一试，不仅要有一个好的出发点，还需要一个清晰的终点，在这个终点你可能：验证猜想、收获结果、体验过程、理解现实。
而在起点和终点之间，你需要选择一条更现实的路径，通过不断地尝试，走出自己的体系。
提问：从技术到人生的习惯
提问这个习惯，我有三个层面的理解：
如何问？
问什么？
为何问
如何问？提问之术==《提问的智慧》
提问的第一个原则：提供足够的信息，让人能够回答。
提问的第二个原则：提供更多的选项，让人方便回答。
草率的问题是懒惰的问题，通过搜索引擎就能简单获得；
草率的问题是模糊的问题，让人没法回答。
更有意义的提问是把解答题变成选择题，提供你的选项，展现你探索了哪些路径
只索取而不愿思考和付出的提问者，要么什么也得不到，要么只会得到 RTFM（Read The Fucking Manual） 或 STFW（Search The Fucking Web）。
提问的第三个原则：提供交换价值，建立讨论基础，表达感谢态度，让人乐于回答。
提问本是一种索取，要让人有更多的回答动力，还需要付出。付出一种态度，表达感谢；付出一份可供交换的视角，建立讨论的基础。
问什么？求解之惑
有时一个好问题，比如何问更有价值和意义。提出新问题，也许会导向未知的宝藏，它可能是获得新知的起点。
1. 改变你提问的习惯
2. 当遇到暂时没有答案的问题时，先记录下来。在成长这条路上，不是碰到了问题，就能立刻或很快找到答案的。
定期地回顾下，曾经困扰我的问题
先从一个记录问题，积攒 “问什么” 的习惯开始，不断去积累并留下一些东西，将来再定时去回顾这些问题，也许就会得到意外的收获。
问题的上、下文；
问题的具体描述；
问题的解决思考和思路；
问题的解决方案和具体技术或办法；
问题解决后留下的思考或其他延伸的疑问。
为何问？价值之道
为何而问，就是发问于我们的价值之道，最终指向的目的是：认清自我。
选择决定命运，什么来决定选择？价值观。
3. 第三个习惯：为何而问？获得答案，认清自我，选择自己的价值之道。
【总结】
如何问，是关于提问的 “术”，考虑让人能够回答，方便回答和乐于回答；
问什么，是关于成长的 “惑”，去积累问题，寻找答案，并分享出来，从而完成了价值的积累、传递与交换；
为何问，是关于选择的 “道”，价值观的选择决定了不同的道。
【补充】
沟通的关键在于倾听
提问的关键在于痛点
偏好：个人习惯的局限与反思
习惯形成：习惯是个人的偏好
每个人做事情都有些个人习惯，程序员写程序也会形成一些个人习惯或者说癖好
比如，工程的目录结构、类的命名模式、接口的参数定义，甚至注释和签名的方式，都是特别在意的地方。
共识达成===看待问题共同的思考方式和角度
代码规范
一些编程的好方法可能比较难用规范去描述，慢慢形成了所谓的 “编程智慧”
设计模式。遵守设计模式能让你少踩坑，但灵活地采用合适的模式又是另一种智慧了。
术语约定。约定了术语，总是能让口头的概念和落在代码上的东西保持一致，减少沟通歧义，从而更高效。
单元测试。这比任何的代码评审都来得可靠，哪里该写多少测试用例，哪里可以不写，这又是智慧了。但不要刻意为了追求覆盖率而去写，覆盖率的技术统计方法其实是很唬人的，有些覆盖率很高的项目，该有的 Bug 还是有的。
随时重构。对于技术债务，每个月付点“利息”，比好几年后“连本带息”去还要感觉轻松得多。
这条的特殊点在于，这可能是大部分程序员都认可的好方法，但却不是大部分人的习惯。因为技术上的债，实在自己还不起，总是可以推脱出去给下个“倒霉的家伙”，但从长远角度看，这样的推脱不会让你获得成长，甚至还会阻碍你的发展。
分辨反思：编程的好方法？还是个人的习惯
提供规范的设计和接口文档
结对编程：两位程序员坐在同一工作台前开发软件。依据两个程序员具有相同的缺点和盲点的可能性很小
宽松版：确保每一个程序员写的每一行代码，都能有一个配对的程序员去进行检视
【总结】
要学会区分，进行分辨和反思，哪些确实是值得学习与推广的好方法，哪些仅仅是自己的个人习惯，特别是在你成长到开始成为技术管理者之后。
写作：写字如编码
程序员群体有个共同的弱点，那就是写得了代码，解决得了问题，但却不能很好地展现自己的能力。
三类最常见的展现手段：写作、画图和演讲
写作：写字如编码
把每一篇文字当作一个需求，把写作当成在编码的过程去完成这个需求，它会非常类似于程序开发的整个过程，包括需求、设计、实现、测试和交付五个阶段。
需求：程序的需求，对应于写作的主题。===考虑谁读你的文章，他们关心些什么
在大脑的潜意识里都会考虑主题的问题，等有了灵光一闪的时刻，就随时记录下来，形成一个主题列表。
这个主题列表，就有些像产品的需求特性列表了，呆在需求池里等待被 “实现”，也即，“写出来”。
要持续地写作，你得养成关于提问和记录的习惯，挑选值得写的主题。
定义写作的主题，就像定义产品的灵魂，你得确定一个产品的目标、定位，以及面向的读者人群。
想一个你关心，其他人也会关心的话题来写。关注你的主题，而不是想办法去显摆自己的文字。
设计
概要设计:软件程序系统的设计主要是架构设计，系统或子系统的拆分、交互逻辑、边界等等。
形散而神不散。其中的 “神”，包括了文章的核心主题观点，以及围绕主题展开的逻辑结构、文字附着的延展线条等。
详细设计:
围绕主题想表达的观点，考虑需要添加哪些支撑观点的素材，以及设计整理、引出和排布这些素材的方式。
为了让文字更有阅读的趣味，还需要有适当的故事，因为人们都喜欢读故事，而非说教，那故事又该如何切入与布局？这也是需要考虑的点。
平时的阅读记录笔记，留下索引，必要时再根据笔记索引的关键词去搜索。
实现
招式” 的积累与应用，无论写程序还是写文字，都没有什么捷径可走，只能多看、多写、多练。
写作和写程序都需要一段能实现不被打扰且专注的时间。在这个过程中，你有一段专注、忘我甚至像是做梦的过程，与自己的思维深处对话。
在这个过程中，你也可能会产生意外的大脑神经元连接，获得一些更高质量的思考，灵光乍现的启发，以及更好的文字表达。
测试
对写完的文字再读一遍，进行再编辑和优化，就像软件开发中的测试过程。
要在一个冷却的状态下进行，站在一个读者或编者的视角去重新审视这篇文章。
通常发生在写作完成后的一天或几天之后。这中间的间隔，我称之为写作后的冷却时间
交付===发布
交付，就是发布这篇新写的文字，让它面对读者，获得反馈与验证价值。
从作者的角度出发，交付的目的之一是希望有一些更有价值、值得思考和讨论的声音出现。
写作与文字的价值实现分两部分，写完后就完成了对自我的价值实现，而交付后才算完成了对他人的价值实现。
【注意】
在技术讨论会上，参会的大多是技术人员，那么技术细节、实现方式都是可以谈的；
但是，在工作总结与汇报会上，由于参会的大多是业务领域专家与领导，直接汇报成果、问题、解决措施来得更加直接。
学习很苦，坚持很酷。
