简介

来自对极客时间《技术领导力300讲》洪强宁的文章的整理

深度还是广度

理论上先深度后广度，是一条自然的路径。毕竟有太多泛而不精的半瓶水。

程序员是要专精，还是要广度？

1. 对于绝大多数人来说，编程更多的是职业发展道路上一个立身的手艺，在众多专业技术方向上挑了一个自己比较喜欢和热爱的。程序员的发展和众多职位的发展一样，每个人都希望自己能够往”上”走：更专业，更能在职场上发挥自己的作用和影响力，从单兵作战做小事，到带队做大一点的事，再到影响一个领域，影响一个行业。这样的发展单单靠自己各方面都懂，都有涉猎，恐怕是不行的。刚毕业的应届同学可以靠自己的知识储备做自己的标签，久经职场的同学必须靠自己在某些领域做出的成绩做自己的军功章。所以我们越早在某些方向做出自己的成绩，对自己的成长和发展是越好的。每个人也确实需要一个认识自己的过程，但这个过程我想还是越快越好。在这个过程中，我们自己的技术发展就像是一棵树，我们尽可以无限的去展开自己的枝叶，多了解一些不同的方向和知识，但一定记住这是为了让自己的枝头长得更高。
2. 做一件事是要精还是要广？其实相当于赌博里你是要多压，还是要单押。我们的筹码是有限的，当然我们的精力也是有限的，不可能去做所有的选择。那么这时候，问题就变成了如何去组合投资获得最大化的收益。PS：精力投资

广度的必要性

1. 某些职位就要求足够的广度
2. 有的人（比如笔者）兴趣比较发散，不太喜欢只深挖一个
3. 多角度决策，比如学习linux的源码，单单学习java不一定会学linux，单单学习docker也不一定会，但既会java又会docker 的人会有最强烈的冲动去学习linux
4. 高层次审视问题， 比如研发效率提高的问题（笔者研究过一段的持续交付系统），做好之后，虽然公司层面的管不了，但可以先把组内的研发效率提高一下。
5. 做深的人自然有广度，做广了的人，加上一定的主动意识，也会有深度。只有做深了，才能接触到一些偏本质层面的东西，再加上一定的宽度，你会发现本质层面的东西都是一样的。进而有自信忘掉不必要的细节，脑子里不仅要有货，而且扔掉零碎，只保留有价值的干货。脑子里知识多而琐碎，就不能给干货腾地方，干货少，就妨碍你拓展自己的能力边界。
6. 很多抱怨来自于自己的工作范畴之外，不要去抱怨这个问题，解决这个问题。
7. 广度的重点不在广，在消化，在心得体会，在触类旁通，在完善已有的知识体系， 你得确保你对知识的提炼有一定的深度，以至于你根本就不担心忘了细节。触类旁通了之后，碰到一个新东西，应用已知的知识，了解之前没见过的问题，广就是深。
8. 问题解决的多种方式，比如一个零件，可以机床切削，也可以3d打印。

关于学习知识的深度和广度的思考 但实际上因为个人的喜好、岗位的流转、机遇的把握、环境的变化、技术的更替、甚至家庭因素，都会影响一个人对知识的积累。

1. 吸收效率:当一个知识学到一定程度，会越来越难，花相同的时间，很难再达到相同的效果。这个时候，完全可以拓展广度，说不定触类旁通，一个灵感就能让你在原来的深度上一下领悟。死磕难点往往不起作用。
2. 急用的知识优先学
3. 价值突破:人有涯而学无涯，知识永远学不完，但人需要利用知识走好每一个阶段，让自己不断升值。所以从这个角度来说，深度、广度都不是最重要的，而你的价值突破是最重要的。怎么解释？就是说你越容易从哪个方向做出价值，得到认可，就去从哪个方向突破，不要为了学而学。
4. 快速学习的能力:在用人单位或者公司里面，解决问题是根本。深度不是靠系统学习出来的，而是解决实际问题，不断加深经验和认知出来的。
5. 多一个选择多一个机遇，大部分人总认为自己适合做什么，于是往往会按照自己既定的规划去奋斗。但一个人的价值和潜力，往往不是自己能事先决定的，而是外界的场景和机遇发现的。比如区块链，就是结合了金融与计算机的相关知识。

作者的思维方式运用了

1. 一切从实际出发，看重可行性
2. 从“深度”方式 实际的困难入手分析

所以从整体看，要破除 广度和深度 的执念

1. 都有优缺点，要看几天工作环境和兴趣
2. 广度和深度 不是学习知识的区分方式，还不如说要基础知识深度学，应用型业务型知识宽泛学
3. 一个重点的是需要
4. 一个维度是时间，足够的时间、足够的积淀 在广度和深度上都有一定突破。

《大厂晋升指南》P5/P6的核心关键词是完成任务，P7/P8的核心关键词是达成目标，它们的差别在于：任务是从过程角度来衡量的，而目标是从结果的角度来衡量的。P8 提升技术能力的关键是深度和广度齐头并进。PS：所以广度和深度的侧重不是一成不变的。

左耳朵耗子：

1. 把你看到和学习到的信息，归整好，排列好，关联好，总之把信息碎片给结构化掉，然后在结构化的信息中，找到规律，找到相通之处，找到共同之处，进行简化、归纳和总结，最终形成一种套路，一种模式，一种通用方法。
2. 坚持也不是要苦苦地坚持，有循环有成就感的坚持才是真正可以持续的。所以，一方面你要把你的坚持形成成果晒出来，让别人来给你点赞，另一方面，你还要把坚持变成一种习惯，就像吃饭喝水一样，你感觉不到太多的成本付出。只有做到这两点，你才能够真正坚持。
3. 把你新学的知识点关联到已知的事物上来。比如，你在学习 Go 语言，你就把一些知识关联到自己已经学过的语言上比如 C 和 Java。通过类比，你会学得更扎实，也会思考得更多。

周志明：像计算机体系结构、编译原理、操作系统等原理性的知识，对于不写编译器、不开发操作系统的程序员来说，在实践中是几乎找不到直接的应用场景的。可是毫无疑问，这些知识就是程序员知识体系的基石，是许多实用技能和常见工具溯源的归宿。我们花费一定的成本去学习这类知识，目的是要把自己的知识点筑成体系，把大量的、不同的、零散的知识点，通过内化、存储、整理、归档、输出等方式组合起来，以点成线、以线成面，最终形成系统的、有序的、清晰的脉络结构，这就是知识体系。程序员是需要终身学习的群体，当有新的信息输入时，如果能在知识体系中快速找到它应该安放的位置（place it in context），定位它的问题与解题空间，找到它与其他知识点的关联关系，那你接受新信息的认知负荷就降低了。通俗地讲，你就有了比别人更高的学习效率，更敏锐的技术触觉。如果一项知识或技能，你学习起来非常吃力，花费大力气弄懂之后，过一段时间却又迅速地忘掉了，这很可能是因为你既没有实际应用它的场景，也没有在知识体系中建立好掌握它的稳固的前置基础。这种就属于你目前还拿不动的东西，不如趁早放手。你也不必觉得可惜，如果它对你来说是必要的，就一定还会再次出现，想躲也躲不掉。 李智慧：如果这些知识点对于你而言都是孤立的，新知识真的就是新的知识，你无法触类旁通，无法利用过往的知识体系去快速理解这些新知识，进而掌握这些新知识。你不但学得累，就算学完了，忘得也快。所以不要纠结在仅仅学习一些新的技术和知识点上了，构建起你的知识和思维体系，不管任何新技术出现，都能够快速容纳到你的知识和思维体系里面。这样你非但不会惧怕新技术、新知识，反而会更加渴望，因为你需要这些新知识让你的知识和思维体系更加完善。 于航：构建知识体系的方法：

1. 熟读经典，来完成你对某个领域知识的“原始资本积累”；
2. 在第一步的基础之上，再去广泛涉猎更多相关书籍，并进一步查缺补漏，加深理解。

对于某一个特定的知识领域，当你阅读的相关书籍越来越多时，你能从每一本书中获得的新知识可能会越来越少，因此，你阅读整本书所花费的时间也会越来越短。而在阅读“新书”的过程中，里面涉及到的“旧知识”又会刺激你大脑中先前已经构建好的，与这块知识相关的神经元，从而让你对这部分知识的记忆变得更加牢固。随着你掌握的知识越来越多，新知识逐渐变为旧知识，而旧知识又不断变得更加深刻，你对新书的“消化”速度也会越来越快。长此以往，便会形成我们常说的“飞轮效应”。

系统化的知识体系与碎片化的内容摄取，并不冲突。构建知识体系，确实需要大段的、集中的时间，但是一旦建立，体系内的一个个知识点，完全可以利用碎片化的 20-30 分钟来搞定——番茄时间以 25 分钟为单位还是有科学依据的。

广度与深度的切换

阿里毕玄：技术人应如何选择职业发展路线？作为技术人员

1. 在刚起步阶段时，首先需要拓宽自己的技术宽度，对自己所做的项目/产品所涉及的方方面面的技术都应该有所了解，另外对于就是学习工程化，让自己真正具备开发商业软件的能力。
2. 在工程化和知识宽度达到一定阶段后，需要开始根据自己的兴趣和工作内容有所选择，主要是加强在某一领域的技术深度。
3. 在技术深度达到了一定阶段后，需要对自己做出一个选择，就是偏业务方向，还是偏基础技术方向。

许式伟：毕业两年成为首席架构师，我的技术学习方法论

1. 学技术不能过于专精，需要横向理解，向广度挖掘。
2. 任何一件事情，想做到极致，就要当成学科去研究。如果仅仅当成一个简单的任务完成，能取得的成果会很有限。
3. 光有技术远远不够，必须理解业务及其运作方式，思考产品和商业的关系。
4. 选择和信息的对称程度有关，你越不了解一个东西，越会趋向选择保守性的方案，当你对某个领域了解得足够透彻，决策过程会非常自然。

技术的广度非常依赖于积累。你一定要带着问题去想，这个时候你才有记忆力，有了积累，慢慢的你技术的广度就会越来越深。

程序员能力有哪些

在分析问题怎么解决之前，有时候要先说清楚问题是什么。

不管是深度还是广度，程序猿的能力有哪些？ 阿里P10毕玄：Java大牛程序员的学习成长路线

1. 技术能力成长 【方法论】从入门到精通是怎样一种体验 ，现实世界的知识点是分型网状结构，随着你的经验越来越丰富，你会发现知识点越来越多，越来越乱，自己记忆力跟不上了怎么办？这时需要系统的梳理知识点，将修行从外功转向内功。化有为无。在计算机数据结构中，一个网若能简化成树（最小生成树），就能高效地增加、删除、修改、查找任意节点。将知识点梳理成为树，以后遇到问题时就能迅速定位原因，触类旁通，快速应对。而且一旦有新的知识点进入，能很快地分类到合适的地方，加快下次访问速度。其实也只有你自己知道，根本无所谓精通不精通，而是你知道自己该花时间在哪些方面，不该花时间在哪些方面。把树状结构化为线性链表。设定一个个目标，步步为营，攻城略地。从入门到精通这条路，你越走越顺了。

2. 架构能力成长

   1. 只做自己专业系统的架构师 ==> 跨专业的系统的架构师。
   2. 最重要的职责是怎么控制项目的风险，或者说作为架构师，你觉得一个项目中最重要的要掌控住的是，并且从架构上怎么设计这个部分。要根据实际的项目/产品情况来突出重点，确保最重要的几个问题是从架构设计上就去掌控的
3. 技术leader 修炼。首先要心中有数：在什么场景下，可以通过什么样的技术来解决问题，解决到什么程度。

赚多少钱，很大程度上取决于你的“不可替代性”丨21读书天赋的误区

1. 天赋不是你做得最好的那个事儿，是你学1个小时，等于别人学10个小时的那件事儿
2. 除了能力天赋，还有一个更重要的，叫做意愿天赋。判断一件事儿，你有没有意愿天赋，问自己这么几个问题：是不是一上来就特别有信心，是不是本能上就兴奋，是不是很容易专注进去，是不是做好了特别有满足感。
3. 认知格局。认知容易，但你的认知“力度”是否可以支撑你投入真金白银去做，就是另外一个问题了。
4. 这件事儿，和我的未来有什么关系？

成长方式

暨家愉

1. 本能型成长，可以理解为源于自己的意识、兴趣和愿望，或是你想要改变现状，渴望得到进步。本能型成长是最有效率的，过程也是最快乐的
2. 应激型成长的理解是，我们身处在某个环境中，由于外部因素的变化，导致自身不得不进行成长，以适应这些变化。由于不是自愿发生的，应激型成长往往是一个痛苦的过程。

本能型成长由于受本性驱动，往往能够给我们带来更好的体验，而应激型成长则较为痛苦。那么是不是说，我们应更多地依靠本能型成长，促进自己进步达到最大值呢？尴尬的是，这不是一个选择题。外部世界的变化会要求我们必须作出相应的改变予以回应。我们可以给予回应的时间有时候并不由我们自己决定，假如没有在限定的时间完成应激和成长，那么面临的就是无情的失败，甚至是淘汰。

该怎么打破舒适区呢？在这里，我故意使用“打破”这个词，而不是“走出”，怎么理解呢？对于原舒适区的打破，最终会融合原来的舒适区，给我们一个更大的舒适区。而这些舒适区里面的知识，也会慢慢演化成我们军火库里面不同的武器，给我们以后再次打破舒适区提供支持。

滴滴曹乐：如何成为技术大牛？

1. 刻意练习包含了三个步骤。第一，找到你要学习的这个领域体系的范式（pattern）；第二，针对每个范式刻意的反复学习和练习；第三，及时反馈。正确的学习方法是把打羽毛球拆解成步法和手上动作，小碎步，米字步，正反手挑球，放网，正手和头顶高远球吊球杀球等（寻找pattern），然后针对每一个动作反复练习（刻意练习），然后请教练或者录下来看视频纠正自己的动作（及时反馈）；而错误的学习方法是，上来就盲目找人打比赛，以赛代练，这样的进步是很慢的，而且错误的动作形成习惯以后未来反而很难纠正。
2. 工作本身就如此繁忙了，哪里能抽出足够多的时间去学习？工作本来就应该是学习的一部分，是学习中的实践和及时反馈的部分。这里一个常见的误区是，学习的内容和工作的领域没有太多直接的关系。我以前曾经花了非常大的功夫去读Linux内核的源代码以及很多相关的大部头，几乎花掉了我将近两年的所有空闲时间，然而在我这些年的工作里，几乎是没有用处的，最多就是有一些“启发”，ROI实在是太低了，现在也忘得差不多了。如果把学习分成从书本中学，和从工作中学这两种的话，那毫无疑问，工作中的“知识密度”，比起书本的“知识密度”，肯定是要低很多的，因为书本里的知识，那都是人家从他们的工作中抽象总结出来的。这也是为什么大家普遍觉得日常工作“琐碎”。然而工作中每个点滴的琐事与平凡，都是可以抽象总结成为方法论的，更别说工作所在的领域自身的博大精深了。从日常工作中学习的秘诀，就是“行动中思考”。
3. 对于每一个软件工程师，最重要的两个能力，是写代码的能力和trouble shooting的能力。
   1. 提高写代码的能力的核心，首先在于坚持不断的写，但更重要的，在于每天，每周，持续不断的review自己之前的代码；同时，多review牛人写的代码。一旦觉得自己之前的代码不够好，就立刻复盘，立刻重构。更重要的是，多思考自己代码和好的代码之间不同之处背后的为什么，通常这就是为什么这些代码更好的背后的秘密。
   2. 要提高trouble shooting的能力，关键在于要深度复盘自己遇到的每一个问题，包括线上的，包括测试发现的，寻找每一个问题，每一次事故背后的root cause，并且思考后续如何避免同类问题，如何更快的发现同类问题。要对团队内外遇到的所有问题都要保持好奇心
   3. 构建相对完整的当前技术领域的知识体系。一方面是在日常工作中，对每一个接口设计，每一个逻辑，每一个模块、子系统的拆分和组织方式，每一个需求的技术方案，每一个系统的顶层设计，都要反复思考和推敲，不断地复盘。另一方面，需要大量广泛地学习行业内相似系统的架构设计，这其实就是开天眼。除了技术领域本身外，架构师需要非常了解业务上是如何使用我们的系统的，否则非常容易over design，陷入技术的自嗨中
4. 很多时候技术上绕不过去的坎，可能非常复杂的实现，往往只需要上层业务稍微变通一下，就完全可以绕过去。对于一个需求，如果他给出了好几个可行的方案，说这些方案也可以，那些方案也可以，往往说明他在架构师的路上还没有完全入门。架构师的难点不在于给出方案，而在于找到唯一的那一个最简单优雅的方案。

总结起来看，行动中思考，就是始终保持好奇，不断从工作中发现问题，不断带着问题回到工作中去；不断思考，不断在工作中验证思考；不断从工作中总结抽象，不断对工作进行复盘，持续不断把工作内容和全领域的知识交叉验证，反复实践的过程。在工作所在的技术和业务领域中刻意练习，加上行动中思考，就是成为技术大牛的秘诀。其实在成为技术大牛的路上，方法反而是没那么重要的。真正困难的，在于数年，数十年如一日的坚持。太多人遇到挫折，遇到瓶颈，就觉得手头的事情太乏味枯燥，就想要换一个方向，换一个领域，去学新的技术，新的东西。而真正能够成为大牛的，必须是能够青灯古佛，熬得住突破瓶颈前长时间的寂寞的，必须是肯下笨功夫的聪明人。因此，和坚持相比，方法其实并没有那么重要。

管理

研发管理

聊一聊在阿里做了 8 年研发后，我对打造大型工程研发团队的再思考很多项目在做架构设计、代码设计的时候，是没有考虑后续小步快跑的，不能小步快跑地添加新功能、解决新需求的话，就会经常性导致部分需求做了一半要延期的时候，根本停不下来，这个版本根本无法临时放弃需求而继续发版；更严重的是，需求和需求之间还是强耦合的，一个需求做不完，其他需求也不能正常发版。这都是实实在在的技术问题、代码问题，而不是管理问题。

很多研发主管都喜欢有事没事在钉钉、微信里询问一下具体的工作进度，或者拉个会议对一下进度，所以 “已读 + ding 一下“ 对他们来说是一个很好的功能。我们非常不鼓励这种依赖即时通信工具或会议的方式来沟通、了解开发进度，这种方式非常同步，就和同步调用一样。正确的做法，应该是开发同学每天根据自己的情况及时在项目管理工具对自己的任务进行进度更新和总结反馈，研发主管自己按需关注任务的研发进度和情况，彼此没事不要相互打扰。

管理规则与管理责任

梁汝波：10万员工的组织如何保持活力？ 在绩效强制分布的情况下，管理者和一个绩效不够好的同学沟通，可能会这么说：“其实你表现挺好的，但是没有办法，公司有绩效分布的要求，这次只能委屈你一下。”类似这样的情况，其实是管理者没有把真正的管理责任承担下来，而是把压力转到规则之上，这样只是完成了一个管理动作，并没有起到管理效果。我们的做法是，让管理者对自己的管理决策负责，虽然这会让管理者在挺多时候处在一个有些拉伸、不够舒适的状态。

另一个挑战是，由于规则少，特别是明确的规则很少，大家在做决策时就要做很多考虑，要根据具体情况来进行决策。大家要为这些决策负责，经常需要通过讨论、会议，在更大范围内对齐，这样不仅大家的决策压力大，效率也不高。这也让很多人在管理活动中一直处在一个不舒适的状态里。管理者会很有动力去推动公司建立更多更明确的规则，这股力量像重力一样，一直在把公司往更多规则的方向上拉。但另外一方面，我们在现实世界遇到的管理问题复杂度很高，我们没有办法通过一组规则去控制、去刻画或者去应对这些管理的复杂性，我们需要留有弹性，让管理者能够做出合理的管理决策。这个度的把握是很难的，特别是在组织快速增长时，既要保证管理的有效性，又要做到公司不因管理低效而瘫痪，我觉得这也是我们一直在面临的挑战。

在一个大规模的、多元业务且快速发展的全球化组织里，如何做到可延展并且有效的管理？目前字节的做法是：通过文化来增加共识，减少规则；通过基本管理机制来实现管理效率；通过让管理者承担起管理职责来保证管理的有效性；通过数据积累和透明来实现管理反馈和迭代；通过工具系统来支撑这些的实现。在这个过程中，我们要抵抗组织的重力，一直处在拉伸的状态。

陈军：程序员的思考方式基本靠经验或者是自己见过的，归纳法，也就是先看见再相信。而大佬则使用演绎法，就是先大胆猜测一个结论，然后小心验证，也就是先相信再看见。很明显后者适用范围更广，可以处理更多的难题。对时间管理的理解也不同，程序猿也知道四象限管理自己的时间，但是时间管理的本质是目标管理，大佬对和目标没有关系的事情根本不会做，并且大佬善于定目标、拿结果、复盘，而普通程序猿对目标都是模糊的。

如何提高技术Leader的思考技巧？leader不仅要有解具体技术问题的架构能力，还要具备团队管理的能力，更需要引领方向带领团队/平台穿越迷茫进阶到下一个境界的能力。所以通常来说技术Leader的技能是虚实结合的居多，繁杂的工作偏多。

1. 很遗憾很多团队的技术规划都只是基于当前问题，有多少资源，然后采取量力而行的方法在对事项优先级进行排序。这其实不是真正的规划，最多算是计划（如果做得不好，计划都算不上，只能算是列表整理）。
   1. 很多Leader不敢向前思考，担心自己的对未来的判断不对。有这样的担心可以理解但是对事项推动无意义，因为：对上你的信息更细致，对下你的信息更全面，如果你都不能对未来做出好的判断，别人如何能够替代你做出判断；只要你的判断合理有逻辑，能够与大家达成共识，那至少说明这个判断不会太差，也是当下比较好的思考了，未必要追求绝对的正确，况且是不是真的正确只有变成了历史才知道（有时候往往历史也回答不了这个问题）；一个低价值的100%完成的目标 与 一个高价值的90%完成的目标，未必一定是100%完成就能拿高绩效，关键还是要看对组织的价值贡献。
   2. 只有向前思考，没有向后倒推。
2. 没有量化就谈不上优化，所以在定义和推动解决一个命题时，要尽可能地把遇到的问题用数据指标的方式进行量化思考。
3. 很多决策看起来都挺对也很有价值，但出发点可能是基于管理需要而不是一线同学工作的必须。这带来的问题就是迟迟无法落地，变成上有政策下有对策。

cto

CTO就是要给CEO扫清障碍和风险在波浪式发展过程中，技术在每个阶段起的作用不一样。在入轨的阶段，CTO应该是整个公司业务一号位班子的成员，是支持一号位的二号位，班子一起看清方向，把业务带入正轨。一旦入轨之后，业务进入快速增长期，CTO的核心不是看方向，而是怎么做好技术，这时首席架构师会变得非常重要，技术让业务更高速增长、加速成长，业务不要被技术拖慢增速。CTO和团队在一起要有一个面向未来的思考，不只是当下与业务的连接。未来是什么，关键的路径是什么，核心的几场仗是什么，这是CTO的牵引力。面对任何技术风险不能只是看，要亲自去试，需要公司投入一些有价值的浪费。

中台的优点在于可以减少很多重复建设，让业务可以基于中台快速创新，因为重复建设的繁忙约等于效率低下。但阿里巴巴的中台已经非常完善了，开始进入了另外一个阶段。当我做一个新业务的时候，我需要跟这么多中台打交道，需要他们去支撑我，过程中如果有任何一个中台支持不能到位，我的业务可能就做不成。我们现在开始大力推动中台能力进一步升级，改善中台的交付方式，把中台再升级。这里涉及到很多技术架构的变化。

前台，面向业务的，为客户赢;中台，是能力中心，中台的客户是前台，让前台更加高效，让前台更有竞争力；底层后台，是强调技术先进性的，确保业务永续。这个组织每一层都是独立的业务经营单元，现在我们在做一件事情，让每个独立的业务经营单元都有CTO。这个CTO会对这个业务经营单元负全责。实现管理机制的核心就是把每一层之间的界面定义清楚。

CTO的一个核心工作，是怎么能够让自己不要成为团队的天花板，而是把自己当成团队的地板，用人做事。成为CTO还是用人做事为主，而不是做事用人为主。

其它

来自极客时间 《技术领导力300讲》 笔记：深度 / 广度并重，我认为人的知识要形成 T 字形的结构，有一个专长的方向，这是一竖，同时要掌握相关的知识，这是一横，这两个方向是相互促进的。没有一定的宽度，其实你的专长深度是有限的，没有一定的深度，横跨的知识就会很松散，而且很难形成结构，大家应该都有这个经验，你在一个方向感到进步很慢，去涉猎一下相关的知识，很多时候就能帮你打开原来方向的困局。

在整个成长过程中，兴趣是最为关键的，所以follow your heart非常重要，只有在有足够的兴趣或梦想的情况下才能产生很强的自驱，没有足够的自驱我觉得在技术领域基本上是不可能走到高阶的，除了兴趣外，自己的优势也要判断清楚，每个不同的方向，我自己认为还是需要一定的天分的，而所谓的天分我觉得就是对个人优势的判断。