笔者按，数据科学家的工作是否如你想象一般，每天建模型，调整参数，充满了乐趣和挑战?在 Dessa 的数据科学负责人 Ian Xiao 看来，或许并非如此。他认为，数据科学家的工作往往是非常「无聊的」，在决定踏上这条道路之前，我们必须对此做好心理准备，建立自己的应对机制。以下是他的全文。
TLDR：很多人选择数据科学(或机器学习)中令人兴奋的东西来激励自己和他人。但我们必须面对一个现实：真正的工作往往是「无聊的」——与人们认为浪漫的东西相比是无聊的。感到无聊会造成紧张，它最终会导致数据科学领域工程师的高流动性。我想和大家分享我的实际工作以及如何应对「数据科学的枯燥」。我希望能帮助你——一个有抱负的数据科学家，去设定正确的期望。所以，一旦你决定从事数据科学的职业，你就要长期从事这项工作。享受它吧!
分享你的方法?我想强调的是，每个人都需要有一个应对机制。花 2 分钟告诉我你的故事，也许接下来我们可以分享我们各自的应对方式，应该很有趣。
1.故事时间
我年轻英俊的表弟 Shawn 最近来到了加拿大，他来这里攻读计算机科学硕士学位。和许多学生一样，Shawn 对机器学习很有热情，他想在两年后毕业时成为一名数据科学家(或从事任何与 ML 有关的作)。
作为一个真正关心 Shawn 前途的哥哥，我决定分享从我的数据科学生涯中学到的最谨慎的知识——这不是《哈佛商业评论》所描述的「21 世纪最性感的工作」，它枯燥乏味，令人筋疲力尽，令人沮丧——就像其他职业一样。
我有义务告诉 Shawn 真相，即使真相令人失望。这将有助于他对自己的职业选择做出明智的决定(更重要的是，我将避免凌晨 3 点接到我母亲和叔叔的电话，他们肯定会给我上关于家庭、责任和诚实的课)。
作为一个聪明、自驱、充满好奇的年轻人，Shawn 想让我详细说明「无聊」具体指的是什么，于是我写下了这篇文章。
此外，我们还讨论了 ML 的主要趋势，以及如何在这个领域脱颖而出。我将在一些后续文章中分享这一点。如果你感兴趣，请接着往下看。
2.设置一些上下文
作为一名数据科学经理，我正在财富 100 强企业带领团队部署 ML 系统，管理客户关系，并做一些技术工作。
这里先谈谈一些更重要的定义。ML 系统是一种解决业务领域问题的解决方案，它有一个 ML 组件，并且具有与人类或机器一起工作所需要的所有其他非 ML 系统内容。
部署意味着获得驱动实际业务操作的解决方案。例如，设置用于训练和验证 ML 模型的实验不是部署;设置通过电子邮件发送每月产品报价的推荐引擎是部署。部署 ML 系统面临的问题与构建一个好的 ML 模型截然不同。如果你感兴趣的话，可以在这里阅读更多内容。
也就是说，我指的不是那些加入谷歌(google)或其他高科技公司，成为初级开发人员和技术经理的人。这些公司确实做得很好，但我认为它们只代表「前 1%」。其他财富 100 强企业往往在技术成熟度、应用速度以及对工具和工程人才的投资方面落后。
3.让我们开始吧
简而言之，当我说数据科学很无聊时，我指的是当人们意识到浪漫的期望和现实之间的差距时的那种压抑感。
大多数年轻的数据科学家希望把大部分时间花在构建和改进神秘的 ML 模型上，或者将时间花在用绚丽的可视化技术展示开创性的商业见解上。当然，这些确实是你工作的一部分。
但是，随着企业成熟度的提高，他们更加注重实际的经营价值。这意味着企业希望部署更多的 ML 系统;他们不太关心他们有多少新模型或漂亮的报表。因此，数据科学家被要求做非 ML 工作。这让他们感到很无聊。
让我们进一步具体化数据科学中的「无聊」是什么样子，如果我给你展示我从周一到周五的典型一天，你将发现那是非常无聊的。因此，我将把我的工作分类，突出展示预期与现实的对比，并分享我的应对机制。
我将使用「我们」为主语，因为这些例子是从和团队的经验集合中提取的。这些例子可能并不详尽，但我认为它们会说明问题。
3.1设计(占据 5-10% 的时间)
这指的是我们整个集体一起努力获得「高」智力来解决问题和提出高明的想法。这些想法可以包括新的模型架构、数据特性和系统设计等。很快，我们就会陷入低谷，因为由于时间限制和优先级的原因，我们需要采用最简单(通常也是最无聊)的解决方案。
期望：我们实现的想法，可以在著名的 ML 期刊，如 NIPS，谷歌的人工智能研究博客等上面刊登，甚至可能赢得下一个诺贝尔奖。
现实：我们执行的事情能很好地完成工作。我们为一些值得装帧的漂亮白板画拍照。
应对机制：1)和我领域外的朋友一起喝酒时继续谈论疯狂的想法;他们可以残忍地让我停止这些疯狂、愚蠢的想法;2)把疯狂和聪明的想法作为辅助项目来做;3)结果是，大多数疯狂的想法并没有真正起作用或者只是比简单的想法稍微好一点。所以 KISS 原则(保持简单愚蠢，Keep-It-Simple-Stupid)总是给我安慰和结束。
3.2 编码(会花费 20-70% 的时间，具体取决于角色)
这里没什么好说的。在这个阶段，我们戴上耳机，喝点咖啡，伸展手指，锁定屏幕，打出漂亮的代码行，让魔术发生。
我们的代码通常分为五类，各个代码行数占总代码行数的百分比为：数据管道(50-70%)、系统和集成(10-20%)、ML 模型(5-10%)、支持调试和演示的分析(5-10%)。这与其他人的观察结果大致一致。
如你所见，我们大部分时间都在处理无聊的非 ML 内容。尽管 ML 组件非常关键，但现代的框架和编码语言(例如 Keras, XGBoost, Python 的 sklearn 等)已经将许多复杂的东西抽象出来了。这意味着实现我们需要的结果不需要沉重的代码库;工作流已经很好地标准化和优化了(做低级优化是不同的，但它可能只是 1% 的情况)。
预期：你将花费大部分时间开发和优化 ML 组件，其他人将负责其余部分。
现实：没有人希望 1)做你不想做的事情，2)你把所有的好东西都留给自己，3)你在一个已经很好优化的工作流程上花费了不相称的时间。
应对机制：我们都会根据自己领域的专业知识做出决策，并在对他人发挥支持作用的同时成为自己领域的主要开发人员(例如，贡献想法、进行实际开发或 QA)。这样做可以让我们在向他人学习的同时发挥自己的优势。更重要的是，它有助于避免为了做「性感的工作」而产生矛盾。
3.3 QA、Debug 和修复 Sh*t(至少 65% 的时间)
在我看来，这是任何技术开发工作中最无聊、最痛苦的部分，开发 ML 系统也不例外。
在 ML 中，有两种类型的「bug」：糟糕的结果和传统的软件问题。糟糕的结果是指低分数模型(例如，准确性或精确性)或不敏感的预测(例如，基于商业经验的概率非常不准确)。代码没什么问题，只是结果不合理或不够好。传统的软件问题包括诸如代码损坏或系统配置等问题。
预期：我们只需要处理糟糕的结果，并想出更聪明的方法来建立更好的模型。这件事情还是有点吸引人的，看到由于一些好的想法而提高表现是非常值得的。
实际情况：在我们花在 QA /debug/apply 修复上的时间中，大约 70-90% 是在传统的软件问题上。通常，在建立端到端的模型训练和验证流程之后，我们可以相当快地获得足够好的结果。然后，我们经常将建模的优先级降低，以关注系统问题。
应对机制：我使用 github 的 Issue 特性将其游戏化并保留一个「奖杯板」。当我关闭 issue 时，我会立刻分泌多巴胺。看到我们「征服」的问题，我感到更加自豪。当然，我更自豪的是，当我点击「go」时，一切都神奇地运行起来——这在大学里的编程作业中只发生过一次。我将终生记住这种感觉。如果它在现实生活中再次发生，很可能是出了问题。
3.4 应对突发事件(10-50% 的时间)
对于任何交付团队的经理来说，这都是一场噩梦，而不是数据科学。不管时间线是怎么安排的，总会有事情发生，让你偏离正轨。具体来说，这些突发事件可以分为三类：a)外部问题，如范围更改、上游系统依赖性和客户投诉;b)内部团队问题，如恼人的 bug 需要比预期长得多的时间才能解决;人们需要过渡来适应新的工作内容得到新的工作;人员配备，性格冲突等，C)我自己的无知等等其它问题。
期望：从头到尾按部就班;来自客户、老板和团队的热烈掌声和拥抱。
现实：意想不到的事情通常发生在最不方便的时候。没有什么万全的办法来避免这些问题，这令人沮丧。
应对机制：1)将项目的时间线乘以 2-2.5 倍，以便在涉及到深层次的技术问题或跨团队活动时留出足够的缓冲空间;2)在内部设定进度时要有紧迫感;3)我在脑海中大声发誓，好吧，在适当的情况下，有时会口头发誓;4)呼吸、微笑和倾听，5)与团队一起探索所有可能的选择，并根据可行性、需要的努力和阻力确定优先顺序，6)如果这些都不起作用，不要等待，寻求帮助!7)执行。其中许多机制本身并不是应对机制，但它们是良好的做法，且一直运作良好。
4.总结
我想强调的是，每个人都需要有一个应对机制。
所有这些都是想告诉你，现实世界的数据科学是困难的。有志于从事 ML 职业的人应该认识到，除了建立模型之外还有很多事情要做。你最终会感到无聊和沮丧，就像你对任何职业一样。这是正常的。但最重要的是，你应该建立一个应对机制，这样你就可以长期留在这个游戏中，享受一路上的小奖励和最后的胜利。
本文转自雷锋网，如需转载请至雷锋网官网申请授权。
