“残酷” 的事实

下面这些文字来自我在知乎的回答：“在真实工作中的编程是怎么样的，与学校里有什么不同？”。

入行愉快。

首先，一言以蔽之，用两个字来概括，就是 “残酷”，但是，好在是加引号的。有的不但残酷，还很无奈；有的则是在残酷的同时，还很有趣。搞工程和学校里的象牙塔大不相同，这也许老早就知道，但是绝对不是七八年前我想象的模样。你可以把它当成我没睡醒的呓语，也可以当成我喝多的胡话，或者是心情太差的时候写的吐槽檄文。反正，它们就在那里，事实就在那里。

总的来说，学校里面编程，或者在工作之余编程，是很有趣的，没有 manager 给你各种压力，也没有各种大神（比如 TMP、PM、SE 等等我都搞不清楚干嘛的职位）给你指点江山，你可以自己爱咋弄咋弄。当然，没有了这些 “残酷” 的痛苦，你没法进化，没法超脱，没法升华。

就从一毕业开始的荒唐的面试说起吧。国内的公司问的更杂一些，知识性的问题也问，有时我反而觉得更务实。而外企则很喜欢考察 “能力”，我加引号是因为他们觉得他们在考察能力，实际却不见得。因为他们只是在考察 80% 的算法+数据结构，以及一点点系统设计，一点点扯淡能力，再顺道看看颜值如何啊，八字合不合啊，星座属相啥的而已。因此，这其中前 80% 东西都是可以准备的。而应试，恰恰是中国人最擅长的东西。我记得有朋友在我的 blog 里面回复道，特别鄙视刷算法题和面算法题这样的做法。我想，我可以和你 “同鄙视” 的，但可惜我没有那么崇高，而且他应该是没有很多去大的外企公司面试的经历，否则，应该去一边骂这个该死的面试方式，一边自己偷偷刷题去了。还有人说，FLAG 又如何，某 ACM 拿奖的，某算法特别好的，某题刷特多的，但是工作却不出活儿啊。嘿，这样的人，我还真见过，也听人说过，但问题是，人家，钱，拿，得，多，啊？人家不爽了就可以跳槽啊？人家一跳就是不错的薪水啊？

既然聊到算法，那就继续下去。好吧，残酷的事实是，绝大多数软件工程师的日常工作，和算法的关系其实并不大。当然，和 data analyst 这样的职位比我们还是好很多，那个职位简直就是仅次于产品工程师的神级角色了，学经济学宇宙学物理学化工的，只要数学属性可以，只要会讲故事，就可以扯到伟大的数据分析上面，就可以表示 “本人具备成为优质数据分析师的潜质”（好像也没有什么不对嘛，analyst 们请不要打我）。好吧，话题再扯回来，面试考察的正是平时工作用不着的东西，换言之，原则是 “什么用不着就考什么”，首当其冲的就是算法，而真正用得着的呢，以一句 “Googlej 得到的别考” 搪塞过去了，于是这些自我感觉良好的公司中，工程师日常工作就是在和 Google+StackOverflow 战斗中度过的。尤其是 MS，这家自我号称地球上最没有 taste 的公司，面试简直是为 ACMer 准备的，有的组简直是 “来了就做题，做完就闪人”。Google 问的算法题还算有新意的话，是那 Facebook 是对普通算法题要求 bug free 就让人和不解，bug free 能说明什么问题，说明熟练，说明题目做得多，还是想说明一个人脑子这个 hash table 里面存放的题量大？

工作有多有趣？这是个好问题。其实，每当我们从一家公司跳到另一家公司的时候，也总会有这样那样的幻想，会对下一个让自己发挥的 “舞台” 有所憧憬。但是很多时候，我们面对的问题，都是 “知识谜题”。说白了，就是那些 “不知道的打死也不知道，知道的困难解决毫无难度” 的问题。来来来，这样归纳一下，假设一个工程师每天的工作时间是 100% 的话，20% 可能要吃饭喝水打望上厕所刷推刷微博吹牛逼闲聊，30% 的时间要开各种傻里吧唧的会（这个估计够保守了吧），剩下 50% 的时间想干正事儿了，发现大部分都在干各种 operation 的工作，说白的就是编译构建部署安装搭环境改配置打补丁，余下总数的 10% 才是真正研究问题写代码的时间，发现各种乱七八糟奇形怪状的问题，各种在学习新技术的时候，看着那些玩具代码和 hello world 的时候，根本不可能想到的狗血问题全部冒出来了。就改了一行代码，居然这东西就不 work 了？就加了一个小小的 feature，整个系统居然就挂掉了？于是，从外往里连蒙带猜，连分析带搜索，连 Google 带 StackOverflow 地试错，重要在某个人生中重要的时间点发现，又是一个知识谜题，又犯了一个二了吧唧的错。搞完这些东西，终于把自己写的那一点点小代码，像橡皮膏一样贴到项目组负责的这个庞然大物上了，嗯，it’s working it’s perfect。

别急，哪那么容易让你到达成功的彼岸？代码修改了要反复测试啊，测试的时候要考虑各种情形，调用一个 API 的时候说要接收一只老鼠作为参数，必须要考虑如果对方传过来一头大象怎么办。搞完这些东西，才可以去尝试 code review 这个苦难重重的关卡。发出去以后，等啊等，等啊等，居然没人 review 啊，那好吧我去催，挨个催。结果，幸福来得太突然，十行代码，二十条 review comments，一度让自己对自己的人生观和价值观产生了怀疑。但是，仔细看了之后，发现其中 19 条是关于各种缩进符号命名大小写注释空格的，只有 1 条是具有实际的建设性意见的，终于松了口气，又是一轮改+催的流程……

更可恶的是，当你折腾完这些乱七八糟的东西以后，心里居然没有啥成就感，就那么点破事儿，居然整那么半天？于是你在第二天的 sync up meeting 上说，俺昨天做了 xxx，yyy，发了个 code review，里面代码修改其实只有 10 行。这就是一天又苦逼又繁忙的工作产出啊。更更可恶的是，有牛逼哄哄的同事 A 跳出来说，你这么搞是大错特错的，理由 1 理由 2 理由 3，还有最核心的理由 4，退一步说还有理由 5，就在你心里想我擦妈蛋你这个马后炮为啥不早说的时候，又有一位牛逼哄哄的同事 B 跳出来说，如果用开源的/公司内部的/免费的/别的组做的/我曾经参与开发的，框架 abc/库 def/组件 ghi/工具 xyz，问题可以瞬间解决，言下之意，就是你眼瞎了，脑残了，活白干了，当初应该屁颠屁颠地跟在他后面求指导就好啦。

别高兴得太早，到了线上，还会有更多历练人生的有趣事情等着你。比如项目发布，比如 on call（改线上问题）。有的问题紧急啊，就意味着你要拿着一个传呼机一样落伍的几千年前才用的东西睡觉。它也许早上响，也许晚上响，也许深夜你做美梦的时候响。总之，当它响了，你就得爬起来立即处理，看看是不是 service 又挂了？是不是你天天整的那个破玩意儿又不能访问了？还是哪个用户欠抽搞了个 false alarm？说不定这个问题还真是由你提交的代码引发的呢，那就是 bonus 啦。所以不用怀念学校里那些美好的熬夜打游戏的美好时光，你会迎来新一轮的熬夜改问题的美好时光。

来回折腾若干次以后，环境终于搞定了，code review 终于审过了，代码终于 push 了，集成测试终于跑过了，部署到线上终于没问题了……但是，淋漓畅快的成就感呢？在崇高和伟大之间对神一样的设计反复的斟酌呢？对代码像艺术品一样的华丽丽的无止境的追求呢？

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》