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

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

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

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

# 技术开发与研发

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

维基百科 (opens new window)

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

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

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

# 自学入门与培训班的红海

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 结束语

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

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

部分文章中使用了一些网站的截图,如果涉及侵权,请告诉我删一下谢谢~
温馨提示喵