前端这几年--12.技术开发的门槛高吗

最近对程序员这个职业产生了一些困惑，所以一个问题一个问题地记录下来叭~

技术开发到底是门槛低还是高？

对于“程序员”这个职业，或许现在已经被大多数人认知，常常被认为是吃技术饭碗、工资高的一个工种。正所谓内行看门道外行看热闹，这两个标签都只能代表一部分开发。

有工资高的，自然就有工资低的。资本的本质就是商业化，通俗来说就是赚钱，因此只要存在可优化和压缩的可能性，都会被优化，而目前的技术开发大多数服务于资本。

技术开发与研发

实际上，我们常常将“研发”和“开发”搞混。根据维基百科，研发并非旨在立即产生利润，而且通常具有更大的风险和不确定的投资回报。如今大多数互联网产品“研发”会对投入产出比要求更高，也会对盈利预期有所要求，讲究“快速试错”、“快速迭代”，对产品生命周期、准确来说是盈利周期，会有更高的要求，这个不行就撤了做下一个。

维基百科：

新产品的设计和开发往往是公司生存的关键因素。在瞬息万变的全球工业格局中，公司必须不断修改其设计和产品范围。由于激烈的竞争和消费者不断变化的偏好，这也是必要的。如果没有研发计划，公司就必须依靠战略联盟、收购和网络来利用他人的创新。

显然，如今很多大公司更倾向于后者，因为相比预期不确定的产品研发，这种方式可以更稳定地盈利。因此我们也常常会看到，愿意长期投入而不计成本地进行研发的团队很少，因为研发需要资金，更多时候都是通过融资、战略合作来解决资金问题。但这样依然会存在问题，投资方对盈利的预期，是否和产品本身能够匹配。

所以，很多时候我们提到“程序员”，其实大多数都属于开发而非研发。至于做开发是不是一个技术活，说实话，这玩意入门不难，但是做好不易。

自学入门与培训班的红海

正因为入门不难，所以这些年我们也能看到无数培训班的出现。当然，培训效果显然不像宣传那么好，但对于一些对这个行业一概不知的人来说，有人引路和所谓培训是更快捷的方式。

培训班里做的事情，就是将一些网上的文章/博客/课程资源进行整合，然后按照课时整理成每节课/每天的计划，最重要的一点是，他们会针对面试的知识点做较多的培训，也会教学员简历该怎么写。（其实我没怎么了解过培训班，以上是我自己认为一个培训班应该会做的一些事情）。所以，对于知道如何获取资源的小白来说，自学入门也是可以做到的。

很多培训班都会有一些成功案例，多少人拿到了 offer，甚至如果有人进了大公司肯定都得上历史荣耀板了（如果有这么一个板的话）。这些成功案例的确能说明一些事情：这个培训班针对面试的知识体系准备/简历包装比较到位，但实际上开始工作之后，能拿到怎样的表现都只能靠自己了。

其实我觉得培训班里最需要教的一件事，就是要怎么通过搜索引擎，使用合适的关键字，找到有效的问题解决方法。因为在大多数开发的工作中遇到的问题，99% 都可以在网上找到办法解决，至于剩下的 1%，只需要重启 VsCode/App/浏览器/电脑，就可以解决。所以，对自学入门的开发来说，搜索也是直接影响工作能力和效率的一种能力。

晋级/考核与技术能力的关系

对于开发来说，职级则常常被认为是技术能力的标签。

不管是面试/找工作，还是开发与开发之间的交流，通常都会问到职级。什么阿里 P7/P8、腾讯 T10/T11，还有其他公司的（抱歉这块了解得不多），职级一般会与薪酬待遇挂钩，也会被动与开发的技术能力挂钩，所以晋级对开发来说是一件大事情。同样，考核也会和年终奖/待遇挂钩，因此也是开发中的大事情。拿到一个好的考核，顺利通过晋级答辩，可能就是互联网打工人比较开心的事情了。

或许有些人会认为，职级高的人肯定技术能力比较厉害，实际上也未必都是这样的。

我在工作中经历过两次晋级答辩，而唯一让我觉得自己能通过的原因，结论是只是运气好罢了。要怎么理解“运气好”这件事呢？大概就是你恰好在答辩前拿到了一个“容易答辩”的项目，然后做的结果还不错，答辩过程中恰好评委也认为有价值/做得不错，就通过了。

除此以外，老生常谈的 KPI 项目反而到处都是，很多人为了答辩而故意做一些项目（将原本简单的场景搞得很复杂、用高大上的术语包装等等），答辩通过后就甩手不管、让其他人维护，继续做下一个可以用来下次答辩的项目，这样的事情每天都在开发的世界里上演。还有所谓 PPT 工程，有些人没有做出成果甚至还没开始做的项目，只拿一个包装得很好的 PPT 去答辩并且通过了。正因为答辩通过并没有一个固定的标准，因此评委的主观态度占了很大的比例，我甚至见过为了提高答辩通过率，专门组队去找到相关评委的课上刷脸获取好感的。

考核也是如此，考核更多时候是直接上级进行评分排名，因此给上级们留下一个好的印象便很重要，也因此产生了不少的对上管理手段，比如刷脸刷存在感，迎合上级的想法做事情，等等。也常常会产生所谓的嫡系，这个词我也是工作好几年之后才知道的，虽然我个人认为，把自己的事情做好就可以，不需要过度做一些迎合的事情，但实际上这样的事情也每天都会在身边上演，而我能做的也只有管好我自己。

也有人说，不管是晋级也好，考核也好，都属于管理工具。从这个角度来说，晋级/考核与技术能力并没有必然的关系，新人可以将功能实现得很漂亮，高职级的开发也可能写出糟糕的代码。

我见过很多技术能力一般但晋级/考核很不错的例子，以及很多责任心和敬畏之心都差强人意的人甚至都过得很不错。当然这没有高低对错之分，但这样一来，对我来说职级和考核也并不那么重要了，因为它并不能代表你的技术能力，也不能代表你的实际能力。再者，自身的价值没有被团队挖掘和发现，其实这个团队也未必适合自己。

工作能力与技术能力的差别

前面提到，个人认为不管是考核还是职级，都跟自身的技术能力没有确定的关系，那么它会跟什么有关系呢？我认为是工作能力。

工作能力这个词很笼统，实际上它揽扩了所有工作中需要的一些能力。对于开发来说，或许技术能力是工作能力的一部分，但实际上更多的时候，我们的工作中都对沟通能力、理解能力、复盘能力（天知道为什么我要将其称作一种能力）、表达能力、情绪能力（感受他人情绪/管理自身情绪）等等各式各样的职场能力同样有一定的要求。

回到本文的主题：技术开发的门槛有多高？

大多数情况下，团队对技术开发的要求主要是：能快速响应团队需求，高效高质量解决团队问题。个人认为，对于大多数的产品开发过程中，技术能力只占据了一部分，且要求的门槛也并不会很高，尤其在一些团队急速扩招时还会降低招聘门槛。

作为技术开发，大多数时候我们都是谷歌工程师。对于新人来说，遇到奇怪的报错就去谷歌搜索一下解决方案，遇到没听过的东西就去谷歌搜索一下介绍和说明；对于有一定工作经验的开发来说，工作中常常要参考和学习业界方案、研究竞品方案，然后根据自己的项目情况，选择合适的解决方案并将其进行落地。

要把一个项目做成，从项目初期各种沟通和收集信息（沟通能力和理解能力），项目开始前的方案设计和评审（技术能力和表达能力），项目过程中的开发/联调/测试/问题修复（技术能力、沟通能力、表达能力和情绪能力），项目后期的复盘总结（复盘能力、表达能力），这个过程中除了技术能力也同样涉及到各式各样的职场能力，这中间的某一个短板可能就成了你的最大瓶颈，甚至可能因为某一处没有做好而背了低考核。

因此，与其说大多数的开发工作中对技术能力的要求门槛不高，还不如说对于“本该就拥有技术能力”这样的开发群体，更多时候技术以外的其他能力更能直接影响他的工作表现。

很久以前， 我选择做开发的其中一个原因，便是觉得开发应该是一个比较单纯简单的群体，同时工作性质对逻辑要求比较高，这样的人肯定也很讲道理。因为抱着这样幼稚的想法，曾在工作中遇到了许多不愉快的经历。当然这不是谁的问题，只要有利益纠纷的地方，必然都有人情世故。

我常常在想，如果是“研发”岗位而不是“开发”岗位，是不是就没有这么多的问题呢？今晚做个梦试试看。