作者：桔了个仔，南洋理工大学，Datawhale成员
这个问题我犹豫了很久，三个月前就放草稿箱里了，一直没答的原因是，感觉这些年好像没有什么瞬间让我感觉自己水平突飞猛进，感觉这些年的进步都是慢慢进步的，好像没有「突飞猛进」的时候。昨天带我入行的同事离职了，在部门的送别仪式上，我们回忆起我第一天入职时我那么的「小白」，后来怎么独挡一面。于是我在想，如果要总结一个让我的水平提升的关键「概念」或者「技术」，那会是什么。
于是我回顾这些年的技术历程。说实话，在我开始搞算法后，我日均代码量远远低于我之前做游戏时，甚至有的时候，几天都不写一行代码。当然，我并不能代表所有算法工程师，我虽然也是做数据科学工作，但我需要和客户保持联系，理解需求。但无可否认，代码量少的这些日子，我反而做的事情更靠谱，让我更有成就感。
我于是总结出一句话：解决问题不要于拘泥于技术。
当然，仅仅一句话的话，大家可能看得一头雾水，我展开说说吧。
不要拘泥于技术分为三层：
1. 不要执着于使用最新的技术
有的人想走技术专家的路线，那非常好。每天看看arxiv，看看最新的SOTA，那是一个好习惯。但不要太频繁的变更技术方案。你那种想把产品做到极致的思维，我能理解，我也有过，但你真正做产品落地了，会发现，产品是一个系统，你的技术方案变更可能会对其他模块造成影响。
举个例子，我们的模型是XGBoost，不算很复杂吧？由于我们给多个客户部署过系统，我们知道在什么样的硬件条件下运行时间是多少。例如在每日1万条数据的情况下，我们用AWS的t2.xlarge实例，运行时间是1~2小时，符合客户要求。但如果你看到最新的paper提出了一个新模型，决定要采用的话，除了你的技术方案可行性要得到验证，你的技术方案对系统运行时间的影响也要重新评估。如果你的方案确实效果更好，但服务器成本高出几倍，我们该如何说服客户？这都是是一环扣一环的，实际可能遇到的情况可能比我说的要复杂得多。这，就是系统的世界。
统计建模并不是为了获得完美的预测能力，而是用最小的必要的模型来实现最大的预测能力。
更何况，很多情况下，使用更复杂的方案未必是最合适的方案。我之前写过一个回答，讲了哪些深度学习效果不如传统方法。
在这个回答里，我引用了那个著名的「电风扇吹香皂盒」的段子：
某大企业引进了一条香皂包装生产线，结果发现这条生产线有个缺陷：常常会有盒子里没装入香皂。总不能把空盒子卖给顾客啊，他们只得请了一个学自动化的博士后设计一个方案来分拣空的香皂盒。博士后拉起了一个十几人的科研攻关小组，综合采用了机械、微电子、自动化、X射线探测等技术，花了90万，成功解决了问题。每当生产线上有空香皂盒通过，两旁的探测器会检测到，并且驱动一只机械手把空皂盒推走。中国南方有个乡镇企业也买了同样的生产线，老板发现这个问题后大为发火，找了个小工来说“你他妈给老子把这个搞定，不然你给老子爬走。”小工很快想出了办法他花了190块钱在生产线旁边放了一台大功率电风扇猛吹，于是空皂盒都被吹走了。
但这里需要说明的是，不执着于使用最新技术，不代表不关注最新技术。有的时候，公司的需求是一回事，但我们的技术进步又是一回事，如果我们不care最新技术，那么当我们跳槽时，就会很吃亏。
2. 不要只用技术
技术不是职业生涯的全部，尤其是对于做商业产品的算法工程师。作为算法工程师，尤其是做商业产品的，其实有很多时候，技术并不能解决所有问题；有的时候，技术虽然能解决，但是中策，甚至下策，而上策不一定需要使用技术。代替技术的方法有下面四种，一种比一种境界高。
用金钱代替技术。例如你的产品上线了，发现在线上模型训练总是不成功，发现是服务器性能不够，那么你第一件事是优化你的算法还是花钱扩充服务器？如果对于商业价值很高的项目，宕机一天损失可能远远超过服务器开支，这时候，你第一件事买服务器，优化的工作放到日后。
用沟通代替技术。很多人经常方案进展到一半推到重来的情况（设计师尤甚）。对于算法工程师，如果沟通不充分就直接开工，那么很容易做无用功。举个大家都能理解的例子，例如有个银行让你开发个算法识别哪些客户可能逾期，但由于银行数据敏感，不能直接给你，只给了你data schema让你自己模拟数据，你说没问题，回去花了一周写了个模型，准确率（accuracy）是90%，很不错，结果在客户那一上线，准确率99%，你更高兴了，但很快你发现，客户的数据label 0:1的比例是1：99，你准确率99%和瞎猜没区别。事实上，如果你和客户沟通得当，早点理解清楚数据情况，你就不会采用accuracy这个评价指标。
用管理代替技术。这是区别高阶工程师和普通工程师的重要能力。一个项目，如果管理得当，那么可以让一线开发人员轻松点的同时完成更多工作。
- 有的工作是另一个工作的基础，完成A再完成B的总时间可能小于先完成B再完成A。
- 工作是永远做不完的，即使都是技术工作，也有价值不同。好的技术管理人员应该让大家先做价值高的。
用眼光代替技术。做到这个级别，基本就是CTO级别了，充分了解现有技术优缺点，知道什么地方应该投入新技术，什么地方应该采用旧技术，什么地方甚至不需要技术。但毕竟我还没做到这层，这里就没什么经验可以分享了。
更何况，对于算法工程师，除了技术能力，还有很多能力是必须的，如下图，这些能力，组成了算法工程师的「落地能力」。
图来自我之前写的一个被知乎日报收录了的回答。这里就不再重复其内容了。
3. 不要只关注自己领域的技术
抛开非技术的能力，来集中讲讲技术。对于技术能力，你是否以为你关注最新论文，会调参，就完事了。没这么简单。我每次讲算法工程师工作内容时，都会贴这张图：
中间那个小小的几乎都快看不见的黑块，你放大图片，会发现里面写着ML Code，这就是「算法」的部分。当然，别被这个图吓到，这不一定全是你的工作，这里是一个团队的任务，这个团队可能是两人的团队，也可能是几十人的团队，但可以肯定的是，无论你在哪个公司，一个算法工程师都不太可能只做纯「算法」，不要忘了「工程师」三个字。
我作为一个算法工程师，你以为我只写python，偶尔加点scala？不，你可能想不到，我还写vba。我们客户是银行，他们有内部的模型验证团队，我们需要根据他们提供的模板来生成模型性能报表，而且这个报表模板还不能往外网传，那怎么办？只能用VBA写个Excel宏脚本自动生成报表呗呗。毕竟他们提供的可编程环境就只剩excel了，至于python什么的，由于没联网，pip install啥都不行。
所以我建议，作为算法工程师，多学习下周边技术，不要仅仅只会调参，看论文。周边技术是指能为你快速实现验证与部署的技术，并非所有技术都要学习。你作为一个算法工程师，学习linux，可以方便你部署模型；学习spark，能方便你快速处理大数据；这样你有什么新的idea都可以快速验证而不用再求数据工程师帮你反复做ETL。
但，吾生也有涯，而知也无涯。以有涯随无涯，殆已！但你作为算法工程师，去学习安卓app开发，似乎就有点不必要了，除非你确定用得上，或者你是你们公司唯一的程序员（这种情况建议跳槽）。
这是我在自我提升路上的一点总结，希望对大家有所帮助。
我是桔了个仔，一个和猫咪一起写代码的猫奴，更多内容可点击原文查看。
整理不易，点赞三连↓
