IDEA的Runtime 也要升Java 17了 JetBrains Runtime With the IntelliJ IDEA 2022.2 EAP we are moving from JetBrains Runtime 11 (JBR11) to JetBrains Runtime 17 (JBR17). Starting with this build, all IntelliJ IDEA 2022.2 updates will come with JBR17. This will have the following effects: A significant performance improvement allowing faster and smoother IDE operation. Better security, […]

转自，稍有删减 技术人成长的悖论 在程序员界有一个悖论持续在困惑着很多技术人：在写代码的人的困惑是一直写代码是不是会丧失竞争力，会不会被后面年轻的更能加班写代码的人汰换。典型代表就是工作5年左右的核心技术骨干，此时正处于编码正嗨但也开始着手规划下一个职业发展阶段的时候；没在写代码的人困惑是我长时间不写代码（或者代码量较少）我的技术功底是不是在退化，我在市场上还会有竞争力吗，我的发展空间是不是被限制住了。典型代表就是带业务项目的架构师或者团队Team Leader，他们更多的精力是在业务需求理解和拆分，团队事务的管理上。 这种围城现象非常严重，是技术人在职业发展过程中必定会面临的困境。但要回答清楚这个问题，其根源不在于是写不写代码或者代码量的多少，其本质还是要回到什么叫技术能力以及如何提升技术能力这个根节点上来。我把我的一些观察和思考总结下来，供大家参考。 到底什么是技术能力 要解释清楚什么是技术能力还得看透技术能力的本质，从源头上来做剖析。挑选几个程序员日常的工作问题来做个剖析比对，从我们的日常感观中来辨识下哪些是有技术能力的做法，哪些是没啥技术能力的做法。  两类日常工作 重复琐碎类工作 ** 有一类工作是专门处理其他组技术同学对组内业务的疑惑进行解答，我们称之为daily支持。比如咨询你负责的系统在开发环境有一个报错影响了他们的项目联调是什么原因。这种工作的典型特征就是，随时都可能有人来问你问题，还有可能是同一个问题不同的人来问你很多遍。这类工作称归纳为重复/琐碎类工作。这类工作我们来看看几种做法： 第一种：就事论事，把这个问题回答了结束。到这个程度你只是解决了一个具体的问题。很可惜我们很多技术同学都是处于这个层次。 第二种：解答完这个问题后即整理成文档，把排查步骤写清楚，提升自己和同组人的工作效率。到这个程度说明你看到并解决了内部效率问题。 第三种：将此排查问题的方法和逻辑固化为小工具给到咨询的同学去用，让他以后可以自助排查解决，这样既解决了别人的问题也彻底释放了自己和同组人的效能。到这个程度说明你重新定义了效能问题并找到更好提效的办法。 第四种：将此问题背后根因找到，从业务原理或者产品功能上去找解法。将技术工具抽象为业务功能的完善。到这个程度说明你已经从单纯的技术提效看到了架构合理性问题，并尝试在业务上寻求彻底根治的办法。 这四种不同的做法我们可以看出来，即使是这些重复的琐碎类工作，我们也可以从扩大受益面的角度去提炼价值，然后寻求多个层次的解法。在解决问题的过程中自然而然也锻炼了自己多层次的思考和抽象能力。  抽象复杂类工作 ** 还有一类工作是相对抽象和复杂的工作，它的典型特质就是需要只能感受到现象，很难找到根因，没有明确目标和固定解法，需要自己做方案定策略。举个实际中遇到的例子，就是在复杂的系统链路中往往会出现联调效率十分低下的问题，每个研发同学都在抱怨各种各样的问题，但就是没法去根治。面对这样的复杂抽象问题，也有好几种做法： 第一种：找到抱怨的同学，问一问具体的问题是什么，然后针对性解决。 第二种：更加广泛收集问题，然后列出来表格，归类分析并安排负责人跟进解决，最后定期跟踪进度。 第三种：深入分析表格的中的问题并对问题进行抽象，从架构调优和产品功能的角度去寻找原因，并寻找解决这些问题带来的业务价值，并确定目标拆解路径，最后按照任务推进和跟踪进展。 第四种：从更全局角度去思考此目标与年度目标的关系，与组织发展的关系，思考如何扩大此事的效益，思考如何通过这些事的解决锻炼和培养团队同学。 可以看出来这种抽象复杂的工作，其实也有多种做法，看得更加细致是可以看到技术架构的调优，看得有深度可以与目标、组织成长结合在一起。当然也有很一般的做法，那就是纯粹单个问题解决，纯粹是变成项目经理，通过任务列表跟踪进度。  技术能力层次模型 通过上面两类日常工作的分析，我们很明显可以看到有技术能力的做法特征是能够通过现象看到本质，并能够通过对问题的抽象归纳进行技术架构层调优以解决同类问题。 因此我对技术能力的定义是：技术能力是一种以解决某种问题为目标的思路、方法与执行手段，其本质就是解决问题的能力。在编程领域，就是对遇到的业务问题进行抽象、提炼以及逻辑的构建，通过研发工具以提升解决问题的效能，减低人工低效的重复工作。 如果用技术能力这个定义的方法论对“什么是技术能力”进行剖析，我提炼了一些模型来表达。  这个能力模型按照逐步境界阶段分为了三层： 硬核技术能力 硬核技术能力，基本上就是技术的基础功底（如计算机基础，分布式技术，质量意识等）。虽然这个归为是基础类，但这也是技术人的立身之本。工作3-5年的同学基本上都还是处于这个阶段，即需要大量的练习使得自己的技能非常娴熟。 处在这个阶段最重要的就是需要有技术好奇心，要有技术的专研力，通过时间的磨炼持久去学习去练习，使得自己能够成为团队的核心骨干力量。  技术架构能力 技术架构能力，即通过现象看透本质，通过模型、原则来表达本质以解决抽象复杂类问题。这是一种高阶的技术架构思维，基本上5-10年的同学会处在这个阶段。这个阶段更多强调问题发现，问题定义，问题分析，问题解决的能力。 处在这个阶段是需要很强大的认知能力提升，这里必备的素质就是皮实和包容，要容得下不同的观点也要禁得起各种挑战。但这个阶段也有很大的误区，即非常容易被简化为就是要学习很多方法论或者套路。  技术领导力 技术领导力，即通过技术影响力去寻找愿景和目标，带领组织拿取结战略结果。在这个阶段我们要基于深厚的技术架构能力和技术硬核能力。通过技术思维去解决超越纯技术领域的问题，一般来说10+年的同学会遇到这类问题。这个阶段的成长也会更多面临人的底层素质能力升级，需要更多靠领悟而不是纯粹的训练和问题驱动的思考。这个阶段其实也有很大的误区，即很多人只学到了表面功夫而没有深得要领，纯粹就变成是对己就是自我修养的提升，对别人就是PUA。 如何提升技术能力  随着把技术能力层次模型定义出来，其实如何提升也有了一定指南。后续有机会可以分章节来论述这个技术能力的提升过程。但产出详细章节的实践论述前，还有一篇“内功心法”可以分享给大家：  寻找成长的源动力 大家往往对这个问题不以为意，觉得成长是每个人都想要的，但是大家没有仔细琢磨过促进你成长的到底是什么：是你自驱想要享受这个练、思、悟的过程 还是 因为渴望得到周边人的认可/反馈/评价。这两者在你顺利的时候可能没什么感觉，但当你面对晋升失败，项目不利等挫折的时候就会有非常大的差异。 如果你能够找到自己成长的源动力，那么在遇到真正的困难和迷茫时候才能够摆正好自己的心态，寻找突破口，让自己走出困境，得到长足的成长。 常态化的总结与反思 不管是编码类的技术基础学习成长，还是相对抽象的问题解决，还是技术领导力成长。只要是成长，只要能够抓住这两个关键就一定能够成功。 第一个就是反思，能够敏锐地反思自己的不足，然后不断去修正自己的心态和行为让自己蜕变。 […]