咱们在这儿不谈判交际媒体上的影响力，这需求动用品种繁复的运营和技能手段。本篇文章里要处理的问题非常简略：怎么才能让他人跟随你的主张行动。
影响力无关权利
上级对下级的影响力就必定天然建立吗？尽管权利阶梯存在，但并不意味着权利肯定有效。由于强制力尽管可以确保工作得以发生，履行效果却并不掌握在 leader 手中。咱们都明白假如团队成员并不认可和了解接下来的愿景，他们会做的只是取悦般地服从罢了：我不会花心思把它做得更好，它的成功与否也与我无关。
咱们每个人必定见过一品种型的角色，尽管他们不具有特别头衔，可是他们的定见总会被认可，他们的主张常常被选用，甚至你会发现当同事们遇到麻烦时榜首时间想到的找他们寻求帮助——这便是影响力的魅力。相反，我相信在咱们每个人的职业生涯中，有很多司理以及领导是被咱们所厌恶或许两面三刀地对待的。我曾经阅读过一本非常好谈领导力的图书：You Don’t Need a Title to Be a Leader，这个标题在这儿稍作修改依然建立：You don’t need a title to have influence.
咱们在影响谁
在讨论怎么影响「他们」之前，咱们首先要搞清楚「他们」究竟是怎样一类人群——只不过是一群程序员不是吗？——这恰恰是他们的特别之处。与传统文职人员或许蓝领工人都不尽相同，尽管软件制造如今看来是与劳动密集型工业无异，“极客精力” (geek) 的特质依然保留在他们的骨子里。
假如你在 google 中搜索 ”how to manage geeks”，有一篇经久不衰的文章会出现搜索结果前列:Opinion: The unspoken truth about managing geeks. 这篇发布于09年文章里观察到的现象以及得出的定论现在看来毫不过期。选用文章中的原话一言以蔽之就是：
IT pros will prefer a jerk who is always right over a nice person who is always wrong.
与其他行业的人员比较不同之处在于，程序员服从的并非某个头衔或许某套流程，这儿服从的本质上是对他人发自内心的尊重，而尊重来源于对一个现实的判断：你可否把工作做对。这个前提是如此地重要，以至于让工作中的其他内容都显得黯然失色。正如我在引用的原文中所说的那样，哪怕你是个混蛋也无所谓。在该前提下程序员的种种行为用传统的职场观念来衡量起来是匪夷所思的，例如程序员之间的争持通常围绕的是更好的处理方案是什么，而不是谁来做以及怎么能干得更少；上级的主张也不会是有必要遵从的金科玉律，他们会按照自己的主意实施，不幸的是他们的主意永远都是对的。
与需求巧言令色巴结其他职位的角色不同，赢得程序员尊重的标准答案仅此罢了。可是关于外行而言假如你意识不到这条潜规则的存在，你会在和程序员打交道的过程中步履维艰。
当咱们意识到这个现实之后，便有了刻画影响力的方向。
刻画影响力
把工作做对并无窍门可言，它等同于在考验你的综合才能。你对业务了解要正确，用代码表达业务要到位。可是这听上去像是人人都应该做到及格线，只是昭示着你来到了这个圈子罢了。咱们怎么借此来扩大咱们的影响力呢？
我的主张是「专精」：你的答案要比他人更挨近正确才行。
刚刚咱们一直在回避一个问题，即关于「正确」的界说。当咱们在聊「正确」的时分，咱们其实聊的是实实在在的东西，代码的正确性包含它的复杂度、可维护性以及履行功率等等。而且它们是肯定的，在处理同一个问题时假如你的代码行数更少、运转时间更快、可读性更好，那胜出便名副其实。
假如上面的叙述还过于笼统的话咱们无妨看这么一个例子：假如有人主张在你所在的前端项目中引进端到端测验，你会怎么考虑？「正确」要处理的榜首重问题是要不要做；第二重问题是我应该怎么去做。
在处理榜首重问题时，咱们需求知道：
- 端到端测验是什么？
- 项目中有什么问题是有必要使用端到端测验来处理的？
- 端到端测验是仅有的方案吗？单元测验是否也能到达相同的效果？
- 端到端测验是否适用于咱们的项目？
这四个问题看起来平平无奇，但每一个问题的背后都包括巨大的信息量。例如最终一个问题当在考量端到端测验在项目中的可行性时，咱们既需求对这项技能的横向（与其他测验技能之间的差异）和纵向（目前的技能生态和业内实践）常识都有所了解，对当前项目的现状也要掌握得一览无余，由于维护本钱昂扬的端到端测验并不适用于快节奏的交给项目。
假如提出主张的人只是偶然间在某篇文章中读到了「端到端测验」这么一个时髦的技能词汇（buzzword）而抛出来讨论，恰巧你又有实践端到端测验的经验，而且不认为当下是一个引进端到端测验恰当机遇，那么你便可以有理有据的辩驳他，影响力所以在此显示。
从这个影响力落地的例子不难看出达到「专精」并无他法，它等同于你在某个领域内常识堆集的厚度。而怎么达到这个方针呢？咱们其实是在尝试回答一个纯粹又古老的问题：怎么让自己重新手生长为专家？每个人都有自己的答案。
让声响被听见
去他的“酒香不怕巷子深”——假如你现在现已「身怀绝技」，请必须要让他人看见。没有对话施加影响力自然也就无从谈起。那怎么被看见呢？每天的工作按部就班，团队内的技能趋于稳定，没有时机给到我。
我的主张是不要被动地等候时机，而是为自己发明时机。
你要相信缺陷是永远存在的，咱们每个人都在编码过程中经历过妥协，过去的妥协便是未来的改进之处。作为每天触摸代码一线人员识别到它们并不难，识别并修复它们是最好的时机。你无妨挑选一些你擅长的领域先把自己出资进去：之所以称之为「出资」是由于你或许需求动用到工作之外的时间去整理它们、寻找处理方案以及准备资料压服我们。
并非每一次提议都会得到支撑，你的预期是应该把拒绝作为常态。这种拒绝大部分时分不是来自关于你主张的否定，而是没有满足的资源把你的提议落地。可是没有联系，在和团队共享的过程中正确性现已得到了我们的肯定，影响现已发生。反观整个过程也是你技能生长的痕迹。
假如你甘愿等候时机，那么你需求考虑这样一个问题，当时机来临时你可否捉住它？现状并不是看到时机之后我再去完善我的常识系统，而是我不断地堆集常识系统去静候每个时机的来临。
- 测验覆盖率治不好你的精力内讧
- 昂贵的质量
- 了解流程
- 帮助团队生长是仅有的出路
- 开源社区的暗面
- 上一年做 Tech Leader 犯过最大的错
- 技能写作的困境
- 拥抱原则与面对现实
- 代码与质量的考虑与随笔
- 从对 Vue 中 mixin 的批判，到对模块间依靠联系的讨论
