download：SpringBoot2.X+Vue+UniAPP，全栈开发医疗小程序
重塑影响
影响力与权力无关
上下级的影响力一定要自然建立吗？权力阶梯虽然存在，但不代表权力绝对有效。因为强制力虽然可以保证事情能够发生，但是执行效果并不在领导者手中。我们都知道，如果团队成员不认可和理解下一个愿景，他们所做的只是讨好和服从:我不会费心去做得更好，它的成败与我无关。
我们每个人一定都见过一种类型的角色。虽然他们没有特别的头衔，但是他们的意见总是被认可，他们的建议经常被采纳，甚至你会发现，当同事遇到困难的时候，他们是第一个求助的人——这就是影响力的魅力。相反，我相信在我们每个人的职业生涯中，都有无数的管理者和领导者被我们讨厌，或者被我们乖张的对待。我曾经读过一本非常好的关于领导力的书:你不需要一个头衔就能成为一名领导者。这个头衔在这里仍然适用，只是稍加修改:你不需要一个头衔就能拥有影响力。
我们在影响谁？
在讨论如何影响他们之前，我们应该先搞清楚他们是什么样的人——只是一群程序员，不是吗？-这正是他们的特别之处。不同于传统的文员或者蓝领，虽然现在软件制造看起来和劳动密集型行业没什么区别，但是“极客”的特质依然留在骨子里。
如果你在谷歌搜索“如何管理极客”，一篇经久不衰的文章会出现在搜索结果的顶部:观点:关于管理极客的不言而喻的真相。这篇发表于2009年的文章所观察到的现象和得出的结论，现在看来并没有过时。总之，文章中的原话是:
IT专家更喜欢一个永远正确的混蛋，而不是一个永远错误的好人。
与其他行业的人相比，区别在于程序员不服从某个头衔或者某套流程。这里的服从本质上是对他人发自内心的尊重，尊重来自于对一个事实的判断:你能把事情做对吗？这个前提如此重要，以至于作品中的其他一切都黯然失色。正如我在引用的原文中所说，你是个混蛋也没关系。在这个前提下，用传统的职场观念来衡量程序员的行为是不可思议的。例如，程序员之间的争论通常集中在什么是更好的解决方案，而不是谁来做，如何做得更少；上级的建议不会是必须遵循的金科玉律。他们会按照自己的想法去实现。不幸的是，他们的想法总是对的。
不像角色需要讨好其他岗位，赢得程序员尊重的标准答案也不过如此。但是，对于外行来说，如果没有意识到这种潜规则的存在，就很难和程序员打交道。
当我们意识到这个事实，我们就有了塑造自己影响力的方向。
塑造影响力
做对事情没有什么诀窍，相当于考验你的综合能力。你要正确理解业务，用代码表达业务。不过，听起来大家应该都考上了，这恰恰说明你已经来到这个圈子了。如何利用这一点扩大自己的影响力？
我的建议是“专业化”:你的答案要比别人更接近正确的答案。
我们只是一直在回避一个问题，那就是“正确”的定义。当我们谈论“正确”时，我们实际上是在谈论真实的事情。代码的正确性包括其复杂度、可维护性、执行效率等等。它们是绝对的。在解决同样的问题时，如果你的代码行数更少，运行时间更快，可读性更好，你就值得赢。
如果上面的说法太抽象，我们来看这个例子:如果有人建议在你的前端项目中引入端到端测试，你会怎么想？“正确”首先要解决的问题是做还是不做；第二个问题是我应该怎么做。
在解决第一个问题时，我们需要知道:
什么是端到端测试？
项目中有哪些问题必须通过端到端测试来解决？
端到端测试是唯一的解决方案吗？单元测试能达到同样的效果吗？
端到端测试适用于我们的项目吗？
这四个问题看似不起眼，但每个问题背后都蕴含着海量的信息。比如最后一个问题，在考虑一个项目中端到端测试的可行性时，我们需要同时了解该技术的横向(与其他测试技术的区别)和纵向(当前技术生态和行业实践)知识，对项目现状有清晰的认识，因为维护成本高的端到端测试不适合快节奏的交付项目。
如果提出建议的人只是偶然在一篇文章中读到了“端到端测试”这个流行语并抛出来讨论，而你恰好有实践端到端测试的经验，又觉得现在还不是引入端到端测试的合适时机，那么你可以用合理的理由反驳他，影响就在这里展现出来了。
从这个影响力落地的例子，我们不难看出，没有别的方法可以做到“专业化”，相当于你在某个领域知识积累的厚度。而如何实现这个目标呢？其实我们在尝试回答一个纯粹而古老的问题:如何从新手成长为专家？每个人都有自己的答案。
让声音被听到
去他妈的“酒香不怕巷子深”——如果你现在有“特长”，请一定要让别人看到你。没有对话的影响，就谈不下去。怎么才能看出来？我每天按部就班，队里技术趋于稳定，我一点机会都没有。
我的建议是，不要被动地等待机会，要给自己创造机会。
你要相信，缺陷永远存在。我们每个人在编码过程中都经历过妥协，过去的妥协就是未来的改进。作为每天接触代码的一线人员，认出他们并不困难，是识别和修复他们的最好机会。你不妨选择一些自己擅长的领域，先投资自己:之所以称之为“投资”，是因为你可能需要花工作之外的时间去整理、寻找解决方案、准备说服大家的材料。
不是每个提议都会被支持，你的期望是拒绝应该是常态。大多数时候，这种拒绝并不是来自于对你的提议的否定，而是来自于缺乏将你的提议付诸实施的资源。不过没关系。在和团队分享的过程中，正确性得到了大家的肯定，影响已经发生了。另一方面，整个过程也是你技术成长的痕迹。
如果你宁愿等待机会，那么你需要考虑的问题是，当机会来临时，你能抓住它吗？现在的情况不是我看到机会后完善自己的知识体系，而是我不断积累知识体系等待每一个机会。