程序员进阶攻略-笔记-051~061(完)
技术债务，有意或无意的选择
代码既是资产也是债务
技术债务：在程序设计与开发过程中，有意或无意做出的错误或不理想的技术决策，由此带来的后果，逐步累积，就像债务一样。
程序员经验的缺乏
公司没有鼓励程序员去关注技术债务，只是不断地生产完成需求的代码
技术债务分类
战略债务，是为了战略利益故意为之，并长期存在。公司或业务高速发展的阶段，主动放弃了一些技术上的完备与完美性，而保持快速的迭代与试错性。
特点是，负债时间长，利息不算高且稳定，只要保持长期 “付息”，不还本金也能维持下去。
战术债务，一般是为了应对短期紧急情况采取的折衷办法。这种债务的特点就是高息甚至是高利贷。
疏忽债务，一般都是无意识的。程序员的成长性债务，随着知识、技能与经验的积累，这类债务会逐步减少
公司主动创造一个关注技术债务的环境，这类债务就会被有意识地还掉。
管理
架构师更多关注战略债务===长期持续地关注系统的资产负债表。
开发工程师更多关注某个功能实现层面的代码债务
测试工程师，会关注质量方面的债务
架构升级===还技术债
管理债务的目标就是识别出债务，并明了不同类型的债务应该在何时归还，不要让债务持续累积并导致技术破产。
清偿
战略债务，业务高速发展期保持付息【加机器扩展】，稳定期后一次性归还。【业务到了一定规模、进入平稳期后，再一次性清偿掉这笔实现负债，降低运营成本。】
战术债务，快借快还。坚持成长性归还策略，一旦发现过去的愚蠢的代码，就需要主动积极地确认并及时优化，清偿债务。
一般，把需要以周或月为单位计算的债务算作大债务，
大债务的归还，比如：架构升级，就需要仔细地考虑和分析机会成本与潜在收益。大债务归还要分三步走：
规划：代表愿景，分析哪些债务需要在什么时间还，机会成本的损失与预期收益是多少。
计划：代表路径，细致的债务分期偿还迭代计划。
跟踪：代表过程，真正上路了，确认债务的偿还质量与到位情况。
只需一个程序员两三天时间内归还的债务算作小债务
小债务的归还，基本都属于日常的重构活动，局限在局部区域
信用
程序员一个重要职责就是，维持好资产与债务的平衡关系。
如果系统的债务失衡导致技术破产，需要被迫大规模重构或重写时，程序员的信用必将受到关联伤害。
程序员的信用，更多体现在面对技术债务的态度和能力——有意识地引入债务，并有计划地归还债务；无意识地引入债务，发现之后，有意识地归还。
无债务的系统是不存在的，程序员应把技术债务当作一门工具，而不是一种负担，那么可能就又获得了新的技能，得到了成长。
面对债务，做一个有信用的程序员；将其当作工具，做一个有魄力的技术决策者。
选择从众，还是唯一
想要取得成就，就会面临竞争，几乎所有的成就，都是直接或间接通过与他人的比较来评价的。
众争：局部竞争，一个部门等等
如果你永远都在看周围的人在做什么，和他们保持类似，那么你就很可能处在这群人中的一个平均水平区间。
你只需要稍微付出一些努力，就能超越平均水平；即使想要脱颖而出，也只需要持续地多付出一些努力。
有一句话：“以大多数人的努力程度之低，根本轮不到拼天赋”，这就是众争层面竞争关系的本质。
先努力拉开差距，再去找到少有人走的适合自己的路。
稀少：走的人少，意味着宽阔，也意味着荒芜
2% 的人创造内容，而 98% 的人消费内容；写作，就是这么一件少有人走的路。
写作不受地域的限制，最厉害和成功的写作者可以直接与你竞争。写作也可以通过专业化和差异化来划分领域，从而缩小你的竞争范围。
要么写点值得读的东西，要么做点值得写的事情。
写作本身就是一个关于选择的活动，而值得写的东西，本来也是稀少的。
选择少有人走的路，通常也意味着你要大量地尝试，考虑自己的长处加上刻意的练习，虽不能保证成功，但却在创造可能性。
稀缺
稀少的事情，你可以有计划地去持续做；但真正稀缺的东西，比如：机会，却不会随时有。
所有的日常计划都应该是备用的 B 计划（ Plan B），而真正的 A 计划（Plan A）就是变化
当一件事情来到你面前，如果不能让你产生 “哇～噢～” 的感觉，那么就可以坚决地说 “不”。当真正稀缺的 “哇～噢～” 时刻来临时，才可能有机会注意到并全身心地投入进去。
稀缺时刻不会经常出现，所以才需要备用计划，既然是备用的，也是可以随时抛弃的。
独一
独一无二的路，要么是没有竞争的，要么是别人没法竞争的。
How can I carve myself out a niche that only I have?
可以理解为：我如何为自己谋得一个独一无二的位置？
独一，可遇不可求；遇，也先得有遇的基础，它包括：异常的努力，不错的运气，非凡的能力，也许还有特别的天赋。
走众争之路，拼的是努力，只能成为平均的普通人；
走少有人走的路，拼的是选择、勇气和毅力，可以让你遇见独特的风景，为稀缺的机会创造可能性；
走独一无二的路，真的是要拼天赋了。
选择工作，还是生活
处境
每个阶段会有每个阶段的生活目标。不能错把平衡当作目标，实际平衡更多是一种感受。
认清自己当前阶段的目标，定义清楚这个阶段的平衡点。
一个阶段内，就不用太在意每一天生活与工作的平衡关系，应放到整个阶段中一个更长的周期来看，达到阶段的平衡即可。
通过短期的逃避带来的平衡，只会让你在更长期的范围内失衡。
结合当下的处境与状态，没有静态的平衡，只有动态的调整。
关系：学会享受工作，工作是生活的一部分！人是可以从工作中获得乐趣的
工作与生活的关系，短期的每一天总在此消彼长地波动，但长期，应该是可以动态平衡的，两者没有明显的分界线
生活包括了工作，有时候甚至是非常艰辛的工作，我们可以从整体长期的角度去主动选择一种平衡的生活，某几年重心在工作，某几年重心在恋爱结婚。
紧要的是，去过你想要的生活，而非不得不过的生活。
比例
选择工作在生活中的比例问题，是一个关于优先级和价值观的问题。
用 100 或 120【用 100 还是 120取决于你的事业心和野心】 减去你的年龄来得到你工作应该占用生活的比例
早期的高投入，是为了将来需要更多平衡时，能获得这种平衡的能力
掌控自己能把握的，剩下的再交给时代和运气。
不是通过努力工作来过上想要的生活，而是先设定了想要的生活，自然而然工作就会成为生活中合适的一部分
【总结】
缺乏真正的目标时，就只好盯着感受，把平衡当作了目标，由此带来了平衡选择的困扰；
不同的处境与状态，会有不同的平衡点，需要做出规划与选择；
短期只有此消彼长，长期才能动态平衡；
早期年轻时的高投入，换取将来平衡的能力与选择权。
享受这独一无二，有去无回的人生过程。
所谓个人成长就是认知升级。
第 5 部分=====寻路：路在何方？=========关于方向、角色和自我定位的探索
侠客行：一技压身，天下行走
未来的不确定性通常正是让我们感到焦虑的一个主要原因。
门槛
技能的门槛高低，决定了让我们产生恐慌和焦虑的水位线。
产品经理技能门槛低。
程序员有一定门槛===10000小时定律
医生硬技能门槛之高让人完全兴不起翻越的欲望
行业的最低技能门槛要求挡不住很多人热情地涌入，而技能成长的天花板也感觉并不高，如何能不恐慌与焦虑？
模型
技能模型才是区分不同专业人才特点和价值的核心关键点。
人生只有一次，你无法点亮所有技能，只有唯一的一种点亮路径选择塑造独一无二的你。我们需要主动选择去建立自己的技能模型。
工程师思维的大道，就是先创造一个好模型，然后想办法实现这个模型，工程师关心的是能不能用这个模型创造出东西来。
当只拥有一些零散的技能点，而且这些技能点还会随着时间流逝而过时，我们当然会感到恐慌与焦虑；
但如果能够将这些技能点组合成我们独有的技能模型，提供独特的价值，从此独步江湖，甚至开宗立派，想必也就没那么恐慌与焦虑了。
知识体系和技能模型有什么区别？
知识体系本质也是一种知识模型，但技能模型更深一个层次，因为技能是对知识的应用。
知识模型构筑了理论边界，技能模型是实践的路径。
路径
程序员作为工程师的一种，必须得有一项核心硬技能，这是需要长时间积累和磨练的技能，要花大力气的，而这个大力气和长时间，也正是这门技能的门槛。
也就是你用那 80% 的功夫反复磨练出来的最后 20% 的技艺。
我们大部分普通人，拥有的是有限的时间与才华，面对的是无限的兴趣和技能，同时修炼多个核心硬技能是不明智，甚至是不可行的。
构建核心技能模型其实是关于才华和技能的战略，《达芬奇诅咒》推荐了三个标准：
1. 你确实喜欢
2. 你在这个领域有天赋
3. 这个领域能挣到钱
应先深度修炼“一门”核心硬技能，建立门槛，能进入前 20% 就更好了。
只看语言不太好判断。要和领域结合，两种语言技能解决同一领域的不同问题
然后，围绕核心硬技能适度练习和发展一些辅助技能，这些辅助技能大多属于软技能【比如沟通，表达，展现等】，也有部分硬技能，只是没有核心技能那么硬，通常起到放大和加强核心技能的作用，可以发挥指数效应。
用武功类比于技能模型树，内力是根茎，招式如花叶，时间流逝，落花残叶，冬去春来，复又发新。
【总结】
程序员这行的技术门槛没想的那么高，所以就此易引发恐慌和焦虑；
建立你自己的技能模型，才能提升门槛和核心竞争力；
避开 “达芬奇诅咒”，围绕核心硬技能，发展“一主多辅”的技能模型树。
江湖路：刀剑相接，战场升级
刀剑相接：杀人术
一个程序员修成 “杀人术” 大概需要多久？按照一万小时理论，如果你在某一领域每天持续学习和实践练习十小时，最快也要三年。五年成术已算理想。
此后，技能增长曲线已经进入了对数增长的平缓期，过于单一的技术维度成为了我们的瓶颈和焦虑的源头，该如何去突破这样的瓶颈点？
认知升维：化形
爱因斯坦说过：“我们不能用制造问题时同一水平的思维来解决问题。”
程序员经常陷入一种平面思维方式，比如桌面前端式微，移动端崛起，尝试突破转到服务器后端开发，但是两个领域基本是独立的，关联性很弱，而且交叉的区域也很薄，也就意味着很多经验和能力要重新积累。
应该升维我们的认知结构
五年成术是立足于一点，成立身之本；
而下一阶段不该是寻找更多的点，而是由点及线、由线成网、由网化形。
围绕一个点去划线，由一组线结成网，最后由网化成形，“化形” 表达了一种更高级的知识和技能运用形态，比一堆离散的知识技能点有价值得多。
这个过程几乎没有终点，是一个持续学习、不断完善的过程，最终结多大的网，成什么样的形，全看个人修为。
升维化形，化的正是技能模型，而这套模型基本决定了你的功力高低。
战场升级：十面埋伏
到底是应该更宽泛地看书学习建立理论边界，还是在实战中领悟提升？关于这点，你需要选择建立适当的平衡，走两边的极端都不合适。
在学校的学习更多是在建立理论体系
在工作前五年的成术过程则更多是偏实战。
再之后的阶段又可能需要回归偏理论，提升抽象高度，从具体的问题中跳出来，尝试去解决更高层次、更长远也更本质的问题。
而从更现实的角度来看，你的环境也会制约你能参与实战的经历，导致有些东西靠实战可能永远接触不到，不去抽象地思考是无法获得和领悟的。
“十面埋伏” 这样的技能维度显然比 “霸王举鼎” 要高出不少，而升维后的技能，也需要升级后的战场才发挥得出来。
技能的成长速度总会进入平缓阶段，并慢慢陷入瓶颈点，然后也许你就会感到焦虑；
而焦虑只是一种预警，此时你还未真正陷入困境，但若忽视这样的预警，不能及时进行认知和技能升维，将有可能陷入越来越勤奋，却越来越焦虑的状态，结果走入 “三穷之地”（包括如下三种“穷”）：
结果穷：技能增长的边际收益递减；
方法穷：黔驴技穷，维度过于单一；
时间穷：年龄增长后你能用来成长的时间会变少，分心的事务更多，而且专注力会下降。
认知和技能升维带来新的成长收益，同时防止了单一维度的死胡同，而年长的优势正在于经验带来的理解力和思考力的提升。
【总结】
刀剑相接的战场，我们靠 “杀人术” 也即硬技能求生存，但时间久了就会有瓶颈；
技能升维，需要认知结构先升维，“我们不能用制造问题时同一水平的思维来解决问题”；
升维后的技能，也需要一个升级后的新战场，走上理论结合实践的 “谋战” 之路。
御剑流：一击必杀，万剑归心
拔刀斩
拔刀术，其核心思想是一击必杀，利用瞬间高速的拔刀攻击对敌人造成出其不意的打击。讲究的是快，也即速度和锋利度。
程序员学习和练习编程，面临一个个程序问题能否一刀见血，一击必杀。
拔刀术正是我们第一阶段的技能模型，现实中似乎越到后面越慢，似乎永远也到不了一击必杀，这就是已经进入了第一阶技能的瓶颈区间了。
尝试下技能升维 —— 从 “拔刀” 到 “御剑”
御剑术
“刀” 就是你的知识、技能和经验。
理解、掌握并应用好一种知识和技巧是你的 “拔刀术”
但分享传递并教授指导这种知识和技巧才是 “御剑术”,而 “剑” 就是你面前更年轻、更初级的程序员。
从 “拔刀术” 到 “御剑术”的关键点是：如何剥离自我，通过他人来完成设计和实现，并达成解决问题的目标。
万剑诀
从 “拔刀术” 到 “御剑术” 是习惯的打破；从 “御剑术” 到 “万剑诀” 则是量级的变化。御剑术” 是修行 “万剑诀” 的必经之路。
万剑诀是一项高杠杆率的技能，包括：=======“万剑诀” 的核心要诀
一个人可以同时影响很多人。
一个人可以对别人产生长远的影响。
一个人所提供的知识和技能，会对一群人的工作造成影响。
同时影响多人的路线========团队管理和领导者之路；
影响长远的路线========乐于分享、传授，这可能是一条布道师的路线；
通过提供知识和技能来影响其他一群人的工作==========可能是一条架构师的路线。
“万剑诀” 和 “御剑术” 的共通之处在于都以人为剑，观察、揣摩每把剑的特性，先养剑再御剑最后以诀引之。
若 “拔刀术” 是自己实现的能力，那 “御剑术” 和 “万剑诀” 都是借助他人使之实现的自信和能力，只是后者相比而言规模更大，杠杆率更高。
“万剑诀” 的重心在追求问题解决的覆盖面，而面临每个具体问题时就需要依赖每把剑的锋利度了。
拔刀术，是亲自动手斩杀问题，难处在于维度单一，后期进境陷入瓶颈停滞；
御剑术，是指导他人解决问题，难处在于打破习惯，剥离自我；====通过引导的方式，让新人得到分析问题的能力。
万剑诀，是借助他人使之实现，难处在于剑的养成。
其共通之处，都是基于长期的编程和工程训练，建立的系统化思维能力，创造模型来解决问题，
而变化在于模型的适用对象不同，导致需要不停地调试合适的 “模型参数” 来适配问题，并且不论是技术框架还是人的 “模型参数” 都是在变化之中的。
三维度：专业、展现与连接
个人发展的方向分成了三个维度:
专业 Profession：价值内核
展现 Presentation：价值输出
连接 Connection：价值交换。
程序员往往倾向于在专业维度不断发展提升，却忽略了另外两个维度
专业 Profession
专业能力：包括知识和技能
硬知识与技能
软知识与技能
专业行为：包括规范化的工作流程和作风，严格的职业纪律与操守。
敏捷专家肯特·贝克（Kent Beck）说过一句话：“我不是个优秀的程序员，我只是一个有着优秀习惯的普通程序员。”
专业产出：最终产出的结果是稳定的，可预测的，处在一定品质标准差范围内的。
展现 Presentation
展现专业能力：包括代码、架构、认知、决策；
展现专业行为：包括沟通、交流、表达、协作；
展现专业产出：包括作品、方案、洞察、演示。
展现形式：
代码：Github 等开源站提供了最直接的围绕专业能力中编程能力的所有展现形式、证据和历史；
交流：在日常的即时通讯、邮件、会议、交谈与协作中，展现了关于专业行为的一切；
演讲：有关专业产出的重要形式，如汇报（业绩产出）、分享（作品与影响力产出）；
写作：文字作品，一种长尾影响力的产出形式。
连接 Connection
10：【强链接】好朋友==社交关系中最强的连接。
50% 以上的社交时间都值得花在每个阶段最好的这 5 个朋友身上。
100：彼此还算认识，并且在一定程度上也彼此认同对方一部分价值的人。
1000：一千个铁杆粉丝即可生存。所谓铁杆，就是不论你创作的是什么，他们都愿意支付买单。
10000：拥有一万个关注者（如：微博）或订阅者（如：微信公众号）。
可以传播你的观点并得到反馈
100000+：体现了一个信息、观点与影响力的传递网络。
强连接交流情感，弱连接共享信息。
建立连接的关键在于：给予
建立连接得先提供价值，而且还得源源不断。
专业是价值，展现是支点，连接是杠杆。
三人行：前辈、平辈与后辈
“三人行，必有我师”。原意中的“三”是虚数，泛指多人，意思是身边的任何人都可以成为你的老师，拥有值得你学习的地方。
成长的路，本是一条越走人越少的路，但若有伙伴同行，你会走得更远，走得更久。
成长路上的三人行，指代身边的三类人，它们是：
前辈：可能就是你的上级，是比你更资深和有经验的人，是走在你前面的人
同辈：是你的同事，你们在不同的领域各有所长，甚至在同一领域做得比你还好，但不管怎样肯定是让你尊敬的人
后辈：可能是你的下属，他们也许正在走你曾经走过的路，可能正在做你一年、两年或三年前做过的事，而且可能做得比当时的你更好
你应该有一个动态的列表，在成长的不同阶段将这三类人中的典型代表放在这个列表中仔细观察：
如果你在身边都找到了这三类人的典型代表，你观察他们，便是以他们为尺来度量自己；
你学习他们，便是以他们为模来塑造自己；
你加入他们，便是从后辈的重复中去反思过去，从同辈的领域中去扩展当下，从前辈的脚印中去引领未来。
前辈
观察他们的路径，哪个更适合自己，哪个人的哪些方面让你更想要去模仿。
最适合作为前辈代表的人，应该在你前方不远处，因为这样的观察、模仿和借鉴才更有意义。
前辈的价值在于：他们走过的路，你不用再去摸索，只需快速顺着走下去。
在断点之后，前辈在没路的地方留下的 “脚印” 也解决了非连续性的跨越问题。
前辈的另一个价值在于塑造环境，而环境决定了整体的平均水平线
同辈
同辈，本是那些与你并行前进的人。
“同辈压力”==同辈间普遍存在竞争，很多时候我们的进步就是被这种压力逼出来的，这样压力转化为动力，同辈就成为了动力源。
参考视角==最高分的同学是如何学习的？
每一个同辈都可以拥有自己独特的领域，同辈之间应该互相观察，并能相互沟通、交流与合作。
领域，是一个你自己的世界，在这个世界中，你不断地提出问题并找到有趣或有效的解决方案。
每个人都能拥有一个自己的领域，在自己的领域内去耕耘、创造、提升，纵向提升这个领域的深度，横向扩张领域的维度，当和其他人的领域发生交集时，取长补短，也许还会产生意外的收获。
同辈，除了竞争，也有碰撞与交流，它会成为你的催化剂。
后辈
人，似乎不犯一些错，就成长不了，也许这就是成长的成本。
后辈们，既可能重复犯下曾经的错误，也可能走出更好的路径。通过观察他们的来路，可以反省自己过去的错误，看到了更好的路径。从而从思想上修正过去，以更好地作用于现在和未来。
【总结】
成长路上三人行，有前辈、同辈和后辈。
前辈塑造环境，开辟道路，留下脚印；
同辈之间有竞争，也有交流与合作，既带来压力，也激发动力，催化能力；
后辈带来反思，也提供支持。
前辈探路开拓，同辈携手并行，后辈参考借鉴。
三角色：程序员、技术主管与架构师
程序员与寻路
一个好的程序员首先要能写得一手好代码=====单兵作战能力极强
能够承担整体的系统设计工作
技术主管与过渡：技术主管（“Tech Leader”简称“TL”）是从程序员到架构师阶段的过渡角色。
技术主管（Tech Leader）：技术主管是开发团队中的某位程序员需要对整个开发团队负责时所承担的角色。
既要对最终交付的软件系统负责，另外也会像一个程序员一样去开发实现系统。
一般一个技术主管约 70% 的时间可能花在了开发任务分解分配、开发实践、代码审核和风险识别上
30% 的时间则花在为了保障系统按时交付所需要的各种计划、协作、沟通和管理上。
技术主管（经理）更多还是偏重于技术工作
经理（Manager）：一个人的工作角色中至少有百分之五十以上的时间是花费在管理事务上
技术主管的职责：
1. 完成了具体开发任务的评估、分解并分配，保证软件系统及时交付
2. 负责设计整体代码的结构和规范，必要时引入能提高整个团队生产力的新工具
3. 推广代码模板，总结最佳实践
4. 关注整个团队研发水平，提升团队能力
5. 解决技术分歧：对事不对人地去把问题搞清楚，分析各自方案的利弊，必要的时候甚至能够提出第三种更好的技术方案，以帮助开发团队达成共识。
优秀程序员转变为技术主管所面临的最大挑战之一：====避免陷入到实现功能的细节中
他们即使拥有比团队里所有其他程序员更高超的开发实现技能，对所有开发任务拥有最强大的实现自信，也需要转变为另一种 “借助他人使之实现” 的能力和自信，
因为技术主管是一个承担更广泛责任的角色，必然导致能够专注有效编码的时间会相比以前减少很多
技术主管继续往前走，如果偏向 “主管” 就会成为真正的管理者（经理），如果偏向 “技术” 就会走向架构师。
架构师与取舍
技术主管的角色与架构师有一些职责上的重叠，在一些小团队中甚至完全重叠
如果把技术主管想成是站在楼顶看整个系统，那么架构师此时就是需要飞到天上去看整个系统了。在需要时飞在空中看清全局，落地后发起凌厉一击。
1. 技术主管的抽象和封装层次更多考虑的是语言函数、设计模式、代码结构等事务
架构师是站在整体软件系统高度，考虑不同子系统之间的交互关系、技术的合理性、需求的完整性、未来的演进性，以及技术体系发展与组织、产品商业诉求的匹配度。
2. 架构师在技术领域内有更高的专业力和影响力
架构师要发挥更大的作用和价值就需要去构建自己的非权威领导力，而这需要长期的专业力和影响力积累。
在更大规模的系统上，架构师还要去涉猎更多的跨领域知识，需要和其他领域的垂直架构师（比如：数据架构师、网络架构师、业务架构师、安全架构师等）做深度的沟通交流，以辅助决策判断。
成为架构师会拥有一个更立体的知识、技能矩阵，这是你的得，获得了一个面，在某些点上必然面临被超越的结局（会减少在编码实现的时间，甚至编码能力会退化）。
一个有经验的架构师应该能够很好地表达某些技术指导原则，借助他人使之实现，并且了解和把握什么时候该插手，什么时候该放手。
这就是架构师从技术 “实现力” 到 “掌控力” 再到 “决策力” 的能力变迁。
【总结】
程序员： 【技术职责】 【组织职责】
代码设计
代码实现 协作配合
代码评审
【技术主管】技术主管，像是上阵拼杀的将军，身处一线战场，自身武艺很强，又具备一定的领导和组织能力。
程序员
研发任务管理：工作量评估、排期 协调沟通
任务分解、分配 招聘面试
风险识别 教练指导
技术效能提升：代码规范制定和推广 复盘总结
生产力工具研发和推广 团队建设
最佳实践总结和推广
【架构师】
技术主管
高维度的系统设计、抽象和封装
产品技术蓝图绘制 跨技术和非技术团队的接口协作
关键技术决策
三视角：定位、自省与多维
视角的选择，对解题的难易，关系重大
定位：是一个时间视角，回顾初心，定位未来。
十几年的学校生活都是老师安排功课度过的，但现在你已经不在学校了，你要安排你的未来。
进入职场的功课都是自己给自己安排的。任务来自主管的安排，功课来自自己的安排。
如果你每天的工作就只是完成被安排好的任务，那么你自己的成长就会非常缓慢
自己才是职业生涯的管理者，要想清楚自己的发展路径：远期的理想是什么？近期的规划是什么？
而今日的任务和功课又是什么？今日之任务或功课哪些有助于近期之规划的实现，而近期之规划是否有利于远期之理想？
主管在你职业发展的路上，除了大部分时候给你安排任务，偶尔也可能给你创造机会，而机会出现时你能否抓住，全在今日之功课上。
定位的视角，是关于一条成长的时间路径，它关乎：昨日初心，今日功课，明日机会。
自省，自我的视角，关乎自身，是一个观察自己成长路上行为的角度。
套用 “海尔迈耶系列问题” 来自省：
你学习这项技术的目标是什么？清晰地表述出来。
这项技术现在是怎么做的？有什么局限吗？
这项技术有什么创新之处？为什么它能够取得成功？要是在项目中引入这项技术，谁会关心？
如果这项技术能成功，会带来怎样的变化？
采用这项技术的成本、风险和收益比如何？你需要花费多少资源（时间、金钱）？如何去评估它的效果？
如果有回答不上来的，说明你对这项技术掌握并不充分，那就还不足以应用到实际项目里。
技术成长也可以反思：
这项行动的目标清晰吗？
行动的方法有可参考的吗，局限在哪？
我能有何创新之处？
完成这项行动，会给我带来怎样的变化？
我要付出多少时间、金钱和精力？
行动过程中我该如何评估？
行动结束的标准是什么？”
这就是自省，从埋头做事，到旁观者视角的自我反思。
多维，是一个空间视角，关乎如何选择不同维度的成长路径。
程序员写了几年代码，觉得太枯燥乏味，就想着是不是可以转管理，这不叫多维度的发展路径
打造多维度竞争力的前提是，要先在一个维度上做得足够好，让其成为你赖以生存的维度，这个维度就是你的核心基础维度，是其他维度得以发展的根基。
其中，“足够好”的程度，可能就是指我们常说的 “精通”。===先足够深，然后拓展到其他地方
精通包括两层：
第一，“无他， 惟手熟尔”；
第二，在一个领域形成自己的体系和方法论。
精通面前在第一层面上你达成了品质和效率，然后在第二个层面上，抽象出了当前维度的 “解”，
那么就可以通过 “启发式” 方法应用到其他维度，具备了向其他维度扩展的基础，从一个细分领域到另一个关联领域的 “精通” 能力。
所谓 “启发式” 方法，就是 “在某个视角里，使用这个规则能够得到一个解，那么你受此启发，也许可以把这个规则用在别的问题上，得到别的解”，
而规则就是你在一个维度里抽象出来的方法论体系。
【了解】
《程序员修炼之道：从小工到专家》列举了程序员真正面临的一些问题：
与软件腐烂作斗争
避开重复知识的陷阱
编写灵活、动态、可适应的代码
使你的代码 “防弹”
捕捉真正的需求
无情而有效的测试
无处不在的自动化
工程师思维：对问题领域的建模和求概率解
简言之，多维的路径，其实是从一个核心基础维度去扩散开的。
工作之余，专业之外
程序员的主流成长发展路线，是一个明显的“T”形线路。
有时候，要想产生真正的成长转变与发展突破，就不应自我局限于当下的工作内容和技术专业。
工作之余
工作的内容和环境的限制把你困在一定阶段的时候，工作之余的内容将发挥很关键的作用。
工作之余的安排：
1. 看看程序设计相关的书、文章和博客；===接收和学习知识
2. 参加一些技术主题论坛或会议；====接收和学习知识
3. 写写技术博客；====总结和提炼知识
4. 创建自己的业余项目（Side Project）。====实践所学，获得新的技能或加强旧的技能经验。
创建自己的业余项目是每一个程序员都应该做的事
世界在被代码改变着，而我们在创造着代码。
仅仅是因为好玩，他开发了一款操作系统，连想都没想过，这会让自己有一天成为开源世界的领袖级人物。
只是想创造一个很酷的东西，所以他动手，坚持，因而有了让这个世界上的每一个人都可以免费地获取人类所有知识的百科全书。
成功者和其他人最大的区别就是，他们真正动手去做了，并且做了下去。
Github 上维护自己的业余项目，不断练习重构优化和维护自己的专属工具库
全职工作的内容是你的职责，它支付你的账单；业余项目的内容则是你的兴趣，它满足你的好奇和探索之心。
在做业余项目中最大的收获是：完整地经历一次创造。
大部分的业余项目最终都失败了，但这没什么关系，你已经从中收获了趣味与成长。
专业之外
专业是你的核心领域，而专业之外则是你的辅助领域；核心属于硬技能领域，辅助属于软技能领域===“T”线中的横向延伸部分
1. 创造与洞察
工程师，是一个创造者，创造模型来解决问题，但又不应该止步于此
业余项目要能取得成功就需要得到真正的用户，而获取用户就需要洞察，洞察用户的需要。
不要成为做快餐的 “厨师”。也就是说，不要像外卖接单一样，别人点什么，你就做什么。
应该搞清楚你正在做的事情的价值和出发点，你不仅仅是实现代码，还要想想为什么要实现它。当你多想了后一步，在实现的过程中就会有更多的洞察。
2. 表达与展现
当别人要来判断你的能力和水平时，通常都不是通过你写的代码，而是其他的表达与展现方式。
如果，你有好作品，就值得好好地展现，甚至还要不遗余力地推销它。
3. 沟通与决策
沟通一般有两个目的：一是获取或同步信息；二是达成共识，得到承诺。
技巧的核心就是换位思考、同理心，外加对自身情绪的控制
决策，是在优劣相当的情况下做出选择，更多的决策难点发生在取舍之间。
即使是一个坏的决策也比始终不做决策要好，因为在行动的过程中比“陷”在原地有可能产生好的改变。
决策和沟通有时是紧密联系的，大量的沟通之后可能产生决策，而决策之后也需要大量沟通来落地实施。
总结：工作之余你可以有多种选择，但若被工作环境所困，导致专业力进境阻碍，可以开启业余项目来突破这种限制；
而业余项目带来的诸多益处，从此也为你走向专业之外打开了一个新的视角与空间。
程序员进阶攻略-笔记-051~061(完)相关推荐
- 程序员进阶攻略-笔记-021~030
信息:过载与有效 "忙碌.充实而疲倦"的虚幻假象 在这个信息过载的洪流中,需要的就是在这股洪流中筛选信息并建立自己中流砥柱般的 "知识磐石". ...
- 程序员进阶攻略笔记01-10
有人有天赋,有人凭兴趣,有人看前景. 在人生的不同阶段里,我都喜欢做"复盘",一方面审视过去的自己,另外一方面思索未来的方向. 选择开发语言:对一门语言掌握到通透之后,再学习其他语 ...
- 程序员进阶攻略-笔记-041~050
沟通之痛:如何改变 沟通,越发成为一件重要的事,至少和写代码同等重要:沟通清楚了,能让我们避免一些无谓的需求,少写不少无效的代码. 需求没沟通清楚,写出来的代码,即使没 Bug 将来 ...
- 《程序员进阶攻略》学习笔记
整个专栏分七讲,下面总结作者感触颇深的内容. 一.征途:启程之初 1.有时选择对了合适的路,比光顾着赶路要重要得多. 2.技术的选择,都是赚取长期回报,短期的波动放在长期来看终将被抵消掉,成为时代的一 ...
- 程序员进阶攻略11-20笔记
三阶段进化:调试,编写与运行代码 阶段一:调试代码 Debugging 逐渐降低使用Debug 功能的频率 阶段二:编写代码 Coding & ...
- 程序员练级攻略(2018)-陈皓-笔记整理
程序员练级攻略(2018) 开篇词 入门篇 零基础启蒙 正式入门 修养篇 程序员修养 专业基础篇 编程语 ...
- 程序员练级攻略（2018) --左耳朵耗子
2011年,我在 CoolShell 上发表了 <程序员技术练级攻略>一文 目前,我在我极客时间的专栏上更新<程序员练级攻略(2018版)>这篇文章有[入门篇].[修养篇].[ ...
- 高效学习 程序员练级攻略
感谢内容提供者:金牛区吴迪软件开发工作室 文章目录 一.高效学习 1.端正学习态度 2.面对枯燥和量大的知识 3.深度,归纳和坚持实践 4.学习和阅读源码 5.源头.原理和知识地图 二.程序员练级攻略 ...
- 《Java程序员全攻略：从小工到专家》连载八：加入什么样的公司
加入什么样的公司 "怎么样,蔡佳娃?听了这么多介绍,心里有点谱了吧?" "嗯,听师兄你这么一说,我想了想,还是优先要追求一下欧美的IT公司.追不到也没关系,至少知道自己不 ...
最新文章
- 一口气用 Python 写了13个小游戏，摸鱼达人！
- 什么是python语言的动态类型机制_python的内存管理机制
- struts2中实现文件的上传
- mysql创建索引小案例
- POJ3889-Fractal Streets【分形,递归,分治】
- 谷歌浏览器如何设置flash访问权限
- python-循环控制-continue
- wpf,后台触发按钮点击以及拖动
- ssas 分区 设置_分区SSAS多维数据集的好处
- Spring的AOP特性
- [游戏制作]-C语言实现井字棋（三子棋）游戏简单版
- 在虚函数 声明中写override的作用
- collapsar(collapsar网名什么意思)
- 分段函数的期望和方差_概率论与数理统计的公式及定义总结
- Swagger怎么没有你要的model？一个注解帮你解决
- 多因子模型 —— 因子正交化处理
- uni-app,原生APP，关于苹果APP集成Sign in with Apple（通过Apple登录）后，APP内注册需要强制绑定手机号，审核被拒问题
- 打开小地图并标记目标地点
- 华农计算机科学转专业,转专业门槛有多高? 每8名新生就有一个想转专业
- Xcode效率提升(快捷键等)