手写算法的工作，是怎么样的?

楼主是没听说过调包侠的说法？真正手撸算法的人又何止二三十 k ，那都是专家。

算法是和 paper 结合起来的，你先问问自己有没有多读读 paper 。
读的多了，自然也就想写的多了。

觉得自己像 CRUD boy 的原因是，你的工作价值没有得到证明。当你深刻的认识到你写的每一行代码，每一个决策都会影响到千万级的用户以后，你应该会有些新的体验。

证明用 matlab 写的多，不手写。

在实验室复现过大佬 paper 吗？

差不多就是这样，现实生活中我没见过牛逼到手动从零开始推演的。

现在已经不是技术为王的年代了，你能想到的算法别人都写过了

我做反馈控制算法（类似于现在 AI 方面的神经网络），因为需要适配不同的设备，所以需要手写算法的情况还蛮多，就你的疑问简单说说个人（领域）经验。

- 那些手写算法的工作是怎么样的？会像大学数学课一样写满几个白板，然后彼此热烈讨论思路吗
还是下班的时候也会拿着纸不停的写着证明公式?

通常决定使用一个新的算法是从实际情况的缺陷以及对该缺陷解决方案的猜想开始的，用一个或者多个粗糙的模型的模型来简单验证大方向。在这个过程中不会经过严谨的数学证明，没有“写满大白板、纸”那么夸张。比如积分号能否交换、余项能否忽略、是否有特殊取值在数学上要写清楚的，在算法考察中一律当作显然、期望为 0 的扰动、系统误差等。总体以解决问题、能用为导向。

至于往后会不会升华成研究论文，这个说不定。有的同事有余力，上头需要科研指标，想起来了可能会写写报告。但大多数情况下是被本人烂在肚子里面。

除非开发 tf 、torch 这种机器学习框架了，或者搞 slam 的验证自定义公式，手搓一堆矩阵变换
做产品业务的程序员都是调包侠，开发算法库框架的程序员才是真正手写算法的，但是后者没业务产出咋提晋升加薪呢？

大多数研发都是应用层面的，所以就是调用各种 API ，CURD 之类的。其实就算是调 API ，用哪种数据结构和算法也是有讲究的，这其实会涉及到你对算法的理解的。如果代码的设计标准是程序能执行就可以，那确实会觉得是调包侠，快排和冒泡都可以排序啊。但如果提高对程序的要求，就会倒逼去了解各种算法和数据结构了，然后做测试和选择。虽然没有手写算法，但会让你觉得自己不仅仅是个调包侠。

就算手写算法，也是有论文在前，手写算法去实现 ... ...

有兴趣可以去看看 MIT 6.824 这门很经典的课，给你提供了 MapReduce 、Raft 之类的算法论文，实验内容就是自己去实现论文中的算法

10 多年前可能还真有手写部分高性能算法的，因为当时的新语言缺乏相关的高级数据结构和算法（以及开源库），例如当时的 golang

绝大多数码农都是搬砖技术工，参考工地干活的人，他们并不需要懂水泥、空心砖的制作方法也可以砌墙。