有想从SWE转DS的吗？

楼主理论/计算化学PhD毕业之后转行在狗家做SWE，做了一年多，做得不是很开心。一直觉得自己基础差，又没有ramp up好，组里的东西做起来一直很吃力，进度还慢。虽然老板很nice叫我不要着急一点一点学，但我还是很struggle。虽然入职以来已经学了很多很多东西了，但是工作中新问题还是层出不穷，每一个都要花很大的精力解决，干了一年半了还是没有进入comfort zone。

我也一直在分析原因。客观原因有很多，比如我们组是infra组，有很多legacy code，所以要学的东西很多很杂，想设计新系统，提交新code需要经过重重阻碍；另外由于我PhD毕业进公司就是L4，所以总是被安排到需要自己一个人承担的项目。但是我入职时只会做算法题没有任何SWE经验，大部分东西靠自己琢磨，项目进度和进步速度都十分缓慢。我后来意识到如果和经验丰富的engineer一起合作一个项目，我的进步速度会快一点，可是我们大组几乎没有这样的项目。

以上那些都是客观原因。如果我尝试改变一些东西，比如换个新一点的产品组，或者找个给力mentor带我，可能会好转。就算不做什么改变，我相信假以时日我也能逐渐进入comfort zone。但是还有最最重要的一点主观原因没有说：我发现我不喜欢engineering。

我在入职一个月就已经渐渐意识到了这一点。刚入职要看大量的doc，接触一大堆新鲜的概念。那时我就觉得，这么多概念好烦，有没有什么提纲挈领的理论性的东西，学会了之后这些乱七八糟的概念都可以从理论推导出来？当然没有这种东西。不管是API设计还是server运维，甚至深入到硬件层面，所有的东西都是人为design出来的。It's all about trade-offs and best practices. 我有一个浅薄的理解，很大一部分现代的Software Engineering之所以被发展起来就是因为我们造不出单个强大的计算单元，所以就得发展出一套在各种level上并行计算的手段。这在我看来就是一个trade-off，和本质的东西差的太远。我那时就发现engineering和science一个本质性的不同。Engineering是经验性的学问。你经验多，知道怎么设计API能既减少maintenance cost又能满足各种client需要，那就听你的，或者听所谓的best practices的。关键这些best practices并不是永恒不变的。当Software Engineering的大环境变了，比如说过个十年，出现了很多新硬件新技术，很多best practices都要变。所以对我来说学习这个领域的知识就没有什么动力。它们完全不吸引我。科学吸引我。学习科学的时候能给我带来无穷无尽的兴奋感，学习engineering一次都没有。

当然，科学再吸引我，我也转行了不是？这里当然有众所周知的现实原因。主观的原因也有，我当时还是觉得自己不适合做research。要创造整个人类社会都没有发现的新知识对我来说太难了。但是我觉得做Data Scientist是一条好路。它既不像做research那么难，又是建立在严谨的统计学基础上，不像engineering是建立在human decision上。(我这里说的是纯data scientist，就是不写production code的工种。) 统计学原理是严格的数学推导出来的，所以永远不会变。最多是大家的诠释变一下，比如是否推崇p-value之类的。至于data scientist每天的工作内容，从我有限的了解，就是要回答别人的一些关于business的问题。比如为什么这个月DAU变少啦，launch这个feature是好是坏啊，在哪里做广告性价比最高啊。我是很乐于做这种像解谜一样的工作，尤其是从数据中找出蛛丝马迹。至于做DS的缺点，就是纯DS的职位需求相比SWE非常少，这条路会比SWE狭窄不少。不过我可以先尝试一下在狗家内部转岗，就算失败了也没什么风险。

说了这么多，我也不知道想要什么回复，主要是看看能不能找到共鸣或者建议吧。也欢迎来自SWE和DS双方对我想法的批评，也许SWE没我想的那么坏，DS没我想的那么好。如果我有什么地方想错了还请各位大佬指出。

作为DS来说一下这个职业一个很现实的缺点：那就是职业上升空间的Uncertainty. 现在DS这个行业非常多的人不知道入行以后应该怎么走，因为没有像SWE/SDE那样有已经发展得非常成熟而稳定的职业Ladder。而且它作为一个cross-functional的新兴职业，站在更偏Business和更偏Tech两个方向的交叉路口，虽然哪条路都可以有晋升途径，但几乎没有一条不偏转DS本来路径上升的途径。但如果非要在其中一个道里往下走，又都有缺点：更偏business方向的不管是people manager还是product manager其实都是不是非得DS能升上去的，SWE也行。纯Tech的话，比如你做DS Tech Lead,  然后呢？貌似你的晋升之路就断了。如果你想要往Tech方向继续往上升的话，好像也只能跳出DS的框架，去走其他更偏Engineering的路，比如转MLE。而且LZ喜欢的这种产品方向的DS其实在绝大多数公司没有太大的Decision power的，几乎都被PM压制的很厉害。而且DS现在也是熟练工，做了一段时间基本也就是重复劳动了，远没有LZ说的那么有意思。而且一边做着重复劳动，还要一边担心自己太水了还拿着高薪，迟早被淘汰或者在大灾难来临（比如疫情或经济危机）的时候因为不如Eng那样是刚需而被第一批裁员。

而且狗家的DS据我所知和Business decision并没有那么贴的那么近，而是更贴近很多公司专门钻研算法和建模的MLE。更贴近Analytics一点的DS，就是LZ说的，没事用统计的知识设计下实验做做假设检验，分析分析DAU之类的key Metrics, 这类分析型DS在狗家貌似叫做Product Analyst, Data Science. LZ一个SWE转PA真的在工资上是很大的downgrade, 你愿意吗？当然啦，关于狗家的分析岗的Tracks我也是道听途说，如有谬误，欢迎大家指正。

感觉楼主更适合当公司的research scientist. 如果楼主内部有机会转DS, 建议转了试试. SWE, 还有CS的很多部分就是很注重empirical study和engineering. 虽然个人觉得这些engineering work还好, 楼主觉得烦有可能是因为Google已经非常体系化了, 步骤冗杂(严谨).

BTW, DS可能也没楼主想的那么好吧. 起码我的认知来说, data scientist是个poorly defined title. 各大公司对于ds的期待不一样. 有些公司ds就是data analyst, 纯粹写SQL和很简单的stat program, 做做表; 有的会做做ab test, 检验下hypothesis和business metrics; 有的在做data pipeline, 洗data; 还有的公司, ds会写ml model(个人觉得这类最少了). 不管是哪一类ds, 工作确实都会比swe更scientific一点. 但是职责的分不清, 积攒的技能也会有些许不同, 之后的跳槽也会受到影响吧. 而且很多ds也是在做重复性非常高的工作, 比如写SQL拉data.

老SDE谈谈体会：完全能理解LZ的感受，我上学的时候也喜欢纯数理的东西，但是觉得自己没有天赋去突破人类智慧边界，性格也耐不住寂寞，所以走了engineering这条路。你对engineering的评论我在大方向上赞同，但细节上还是有些不一样的看法。

> 刚入职要看大量的doc，接触一大堆新鲜的概念。那时我就觉得，这么多概念好烦，有没有什么提纲挈领的理论性的东西，学会了之后这些乱七八糟的概念都可以从理论推导出来？当然没有这种东西。不管是API设计还是server运维，甚至深入到硬件层面，所有的东西都是人为design出来的。It's all about trade-offs and best practices.
这些概念背后本质上的principle和tradeoff其实就那几个，核心还是非常内聚的，best practice是为了实践方便进行的偏特化，LZ作为化学专业其实应该很有体会。。。

> 我有一个浅薄的理解，很大一部分现代的Software Engineering之所以被发展起来就是因为我们造不出单个强大的计算单元，所以就得发展出一套在各种level上并行计算的手段。
需求会永远走在计算能力前面，到时候会有新形式的工程手段来榨取计算能力。我觉得这两个之间的关系并不是本质和皮毛，而是像引擎和传动，是两个完全不同的学问，各自有各自的本质。

> 这在我看来就是一个trade-off，和本质的东西差的太远。
日常写代码确实不涉及本质，但是你刚才说的并行计算这些还是要考虑信息论的本质，数据流的本质，算法的本质等等。也可以把子系统设计和整个系统的最终运行效能类比成蛋白质折叠问题，which is chaotic but fascinating in a different way。

> 我那时就发现engineering和science一个本质性的不同。Engineering是经验性的学问。你经验多，知道怎么设计API能既减少maintenance cost又能满足各种client需要，那就听你的，或者听所谓的best practices的。关键这些best practices并不是永恒不变的。当Software Engineering的大环境变了，比如说过个十年，出现了很多新硬件新技术，很多best practices都要变。
此外engineering的一大乐趣在于play with design patterns and paradigms，这并不必须是经验性的，像我这样的普通人可能只能从历史学习经验吸取教训，但也不乏牛人能预测和解决未来的问题，引领工程思想的进化。

Again，说这些不是为了反驳LZ，我非常能理解LZ或者任何人觉得engineering烦，我只是想分享下我对engineering的看法。

统计专业同感疑惑
本人统计在读深感ds玄学最近想转SWE
. From 1point 3acres bbs盖不了解之事物往往产生美好幻想
最近热爱上了刷leetcode题
觉得难易适中十分有趣
猜想代码比假科学对社会有更多贡献
同问SWE与DS道路的职业可发展性比较
.1point3acres随着年龄经验上涨

DS似乎是新职业
之前金融行业有类似职位quant
不了解DS是否是可稳定长期发展的一种职业
比如是否公司真的有这个长期需求
去雇佣一些DS发现数据中的pattern
我个人的理解是一旦模型建立好之后
更多是维护和解释
就像quant的内卷一样
可能未来一些年会有帮助建立模型的工作
但长期未来并不会需要太多DS来工作
希望有关人士可以帮忙解答我的困惑
并讨论DS行业的未来发展可能性
谢谢

我说说我的理解。
不瞒你说我也挺喜欢刷LeetCode，我还特别喜欢钻研神奇的算法。不过这和engineering的差别很大。这两者的交集可以说是非常小。
在工作中基本用不到高深的算法可以说是老生常谈了。我还想补充的是，算法(如何找到复杂度最低的算法)本身是一件比较理论的事情。而工程上要考虑的远比采用什么算法要多，比如business logic，安全性，API设计，不同类型的client怎么处理，productionize，等等。我是被这些事情烦到了。

shenregister 发表于 2020-12-15 13:33
统计专业同感疑惑
本人统计在读深感ds玄学最近想转SWE
盖不了解之事物往往产生美好幻想

我说说我的理解。
不瞒你说我也挺喜欢刷LeetCode，我还特别喜欢钻研神奇的算法。不过这和engineering的差别很大。这两者的交集可以说是非常小。
在工作中基本用不到高深的算法可以说是老生常谈了。我还想补充的是，算法(如何找到复杂度最低的算法)本身是一件比较理论的事情。而工程上要考虑的远比采用什么算法要多，比如business logic，安全性，API设计，不同类型的client怎么处理，productionize，等等。我是被这些事情烦到了。
至于DS职位的需求确实比SWE少很多，但没有你想的那么少。模型一旦建好就只要维护这个太理想化。真实的世界问题层出不穷，尤其是涉及到business decision，每个问题都不一样。有很多问题还需要做实验才能找到答案。这些活还是需要人干的。

取决于你喜不喜欢uncertainty。

kate123321 发表于 2020-12-15 14:22
取决于你喜不喜欢uncertainty。

怎么说？我放弃research的一个原因确实是不喜欢uncertainty。
我猜你是想说DS会有大量的uncertainty？能具体说一下吗？

bruceless 发表于 2020-12-15 14:24
感觉楼主更适合当公司的research scientist. 如果楼主内部有机会转DS, 建议转了试试. SWE, 还有CS的很多部 ...

Research Scientist和DS好像有所不同。我理解前者要更难一点，需要做出能发paper的成果。DS只要能得出的结论对business有帮助就行了。我还是偏向于DS。

sxhexe 发表于 2020-12-15 14:49
Research Scientist和DS好像有所不同。我理解前者要更难一点，需要做出能发paper的成果。DS只要能得出的 ...

是这样的. Research scientist本质上还是做research(对公司有用的), 顺手发paper. 而DS我觉得和scientist基本没什么关系, 工作内容很大程度是statistician或者data analyst的rebranding, 只是新的job title里带个scientist. 当然我知道我这么说...很多人会不高兴, 先逃了