细节与功利主义:致那些同我一样想突破自己技术层级的朋友们

2019-12-25 09:08:17 +08:00
 xiaotianhu
介绍一下身份背景:年薪离百万很远,人不在美国,刚下公交。
  不好意思串场了,小公司( 10 人开发 team )技术主管,PHP 后端为主,JS/Vue Golang Swift 都写点。野鸡大学机械工程,上不起培训班,野路子自学成才。

  作为工程师,终日的 Trade off 使我变成了纯粹的实用主义者,也或者说因为实用主义的信仰导致我走上了工程师的道路。简单来说,就是崇尚『简单粗暴』,实现了再说。

  有一次有个来面试的哥们,在我问完了一大堆『原理』后跟我说,你说这些我是不太懂,但是你就说做啥,我都给你整的妥妥的,你相信哥。虽然我相信他确实能『整的妥妥的』,但是对原理的一无所知还是使我不耻的,请他走了。


  但是君的一席话却让我很感触。


  我当然知道原理很重要。懂得原理,用起来才会游刃有余,作为 PHP 后端,没看过源码的框架怎么就敢用在生产环境呢?出了问题心里没底。但是对于原理,我也就喜欢『看看别人的博客』,知道个大概,感觉就够用了。比如:
PHP 的垃圾回收,引用计数嘛,都懂的。加一减一,不用了清了,妥。

  其余的细枝末节,更进一步的研究,就感觉是在浪费时间。无非就是把这几句话展开成一篇论文,用赤橙黄绿的颜色来避免循环引用,也不能指导我写的更快写的更好了。而且总觉得有一种文人的酸腐之感,整日研究『茴字的四种写法』。有这个功夫研究一下 golang 它不香吗?

  所以技术一直就停留在『高不成低不就』的状态。曾经我也觉得,小公司,没场景,几十万的用户,我也没招啊。

  最近这半年,跟朋友一起在公司内部做创业项目。负责技术之于,探讨产品的方向,运营的思路,UI 的感觉,参与也很多。体会到了,什么叫『打磨细节』,一个点赞按钮,从写完开始改了四五版,交互的反馈,振动的手感,网络的优化,最后终于趋于完美了。

  突然之间,我对于『细节』这件事儿就有了新的认识。原来自己也做过前端小项目,体验确实差。原来一切细节都是有意义的,人是非常敏感的动物,一切最细微的感受汇集起来,就会让你觉得,『恩,是不太一样』。

  思想和观念是非常有力量的,文字也是。我与大神之间的智商差距是有,但是我不信大到不可弥补;况且,我只要跑赢大部分屌丝,我就已经很知足了。转变观念之后,再去看一些技术的东西,比如很简单的一个事儿,『打开文件』

  各个语言都有这个功能。PHP 它很符合『简单粗暴』的思想,一个 fopen 两个参数,是读还是写,搞定了。但是当我回头再去看『 UNIX 环境高级编程』这本书讲打开文件的章节,发现有很多玄机。之前直接扫了几眼就跳过了的章节(不就打开文件么 搞那么多幺蛾子),再读起来津津有味啊,一个写入缓存到底是 1024 还是 4096 的说道和影响也有这么大。还有一大堆参数,他们存在的历史和意义,都有趣了起来。

  除此之外的另一个心态转变,也是最近思考了很久的一个想法:

  『功利主义害死人』。

  实用主义很容易就会变成功利主义。产品经理挂在嘴边的『先上线再说』,说多了就变成了真理,大家都信了。于是写代码的初心也慢慢变了,最开始无非都是喜欢,一个东西调不通半宿半宿不睡觉也要弄明白,也因此收获了巨大成就感。现在的心态,在 KPI 与真理的驱动下,速度变成了第一位的,那么从 Trade off 的角度而言,当然最简单的成本最低。这个库太复杂?换一个;懒得看英文文档?找个中文说的 6 的;大部分的问题,都有现成的轮子可以绕过,小公司能遇到的问题,不就那么多,前人早就走过了。

  当你急着去做完一件事儿的时候,其实你已经不喜欢做了,只是想尽快结束掉这件事儿而已。

  在这个心态的驱使下的另一个结果就是期望通过一门技术来发财,走上人生巅峰。

  听说大数据火了,年入百万!买一本 Hadoop 学起来!
  挖 语言排行榜 PHP 不行了啊,Go 大法好,学起来!
  新出的 Flutter 好像很屌啊,听说薪资高,得看看!

  至于打开文件到底有几个参数,有甚么关系?面试又不问,也不能加薪,都是 CURD Boy 就别装逼了,发财要紧,好好学习 AI 早日去修福报才是屌丝该有的心态不是。

  到了这一步,就很难享受解决问题带来的成就感了。焦虑的心态也就日益起来,再也看不下去大部头的枯燥的神书了,让李哥王哥的 xx 速成视频来抚慰一下痛苦的心灵是唯一方法了。

  然而在这一波又一波热炒的大潮里,能真正收割红利的,很可能是早就已经布局了的。年薪百万的 AI 大数据大牛,有多少人在大浪还没来的时候就已经开始研究了,只是潮起潮落,来的巧了。做一个赶潮人,又有几个能真的变成弄潮儿呢,至少与我无关了。

  想明白这些,虽然离大神之路还很遥远,但是仿佛看到一曦微光,不再那么迷茫。享受过程,自然也就不再焦虑。一点感悟,共勉之
12185 次点击
所在节点    程序员
102 条回复
crclz
2019-12-25 19:33:53 +08:00
所以说大学还是有很大的好处:你自己可以学感兴趣的,但也会被逼着学一些不感兴趣的枯燥的底层原理;但到头来却很有用。
sockball07
2019-12-25 19:36:58 +08:00
高不成低不就 身边的还是菜鸡 虽然自己也没高到哪去

提升的事在做 可是很慢 时间就那么一点

项目经验却一直得不到提升(情况特殊...

听天由命...😭😭
calpes
2019-12-25 19:40:12 +08:00
定语加的不够多,现在技术的粒度太取决于场景了,个人 blog 到企业级 app 到小型 web app 到一线大厂数十亿级 pv 的业务,这些场景里做的想的根本都不是一样的事情,你不了解的底层技术带来的 bug,在几十万 pv 的小 app 上可能都不会有人发现,但是这个瑕疵在巨量 pv 下会被瞬间放大,损失几百万,这种情况下你不得不吹毛求疵,没得选。
说句题外话哈,我发现大厂里的很多团队事情做得牛逼的最重要的保障,就是招牛逼的人,让牛逼的人去做牛逼的事情,说实话我以前根本没想过这条路行得通,但现在我发现不光行得通而且跑得好像很不错。
laibin6
2019-12-25 20:07:32 +08:00
减少 1%的崩溃率,微信是几百万的用户,小 app 可能是几百个用户
OneMan
2019-12-25 23:13:01 +08:00
有思考是好事
limbo0
2019-12-26 02:20:02 +08:00
确实,工作 3 年的体会,工作的时候还是以解决问题为主,比较感兴趣的东西会 wiki 先记一下,等空闲的时候再去深入了解了解,补充到自己的知识体系里
lyzy
2019-12-26 02:31:29 +08:00
写的真实
nianyu
2019-12-26 08:50:27 +08:00
从实用主义到还原主义, 矫枉过正
jsnjfz
2019-12-26 08:57:27 +08:00
认知提升了
xiaotianhu
2019-12-26 09:16:58 +08:00
@AmberJiang 您这是面的产品经理岗位?
zw1one
2019-12-26 10:46:34 +08:00
才发现自己写代码越来越功利,失去了最原本的乐趣。
encro
2019-12-26 11:27:49 +08:00
@zw1one

实用主义和功利主义,
不会导致乐趣减少,
可能还会增多。

就如我前面说的:

1,为了让公司服务器上少花点钱才研究程序和数据库优化;
2,为了让公司少花点钱请程序员多偷懒才研究框架;
3,为了让公司产品卖好点多发工资才研究用户体验,运营,数据分析甚至心理学;


代码优化跑得更快了,业务更顺畅了,用户更满意了,钱赚多了家人满意了,乐趣难道不更大吗?

这恰恰是发现更大的乐趣。
encro
2019-12-26 11:34:48 +08:00
“先上线再说”不是功利主义的错,
是“用战术上的勤奋掩盖战略上的懒惰”。

因为没有辩证是否能行得通,只能先试试再说,试图用结果证明过程和原理。
而我认为应该象“农民运动考察报告”那样,用思想和调查来指导行动,这样才能坚持多年不动摇,最终取得胜利。
yannxia
2019-12-26 12:08:36 +08:00
@xiaotianhu 你这也要考虑个人性格各方面的,的确销售赚钱快,不过很多人不适合做销售,做销售就是不赚钱,都是 Tade-off 的结果,所以包括细节和功利,都是权衡之后的结果,每一次的选择都是一次权衡,哪里什么对错呢?无非是权衡的时候没有上帝视角,无法获得利益最大化。
milkpuff
2019-12-26 12:25:38 +08:00
写的不错,文笔很好。
asuka02
2019-12-26 12:27:49 +08:00
@encro 全能人才佩服
FrankHB
2019-12-26 14:03:58 +08:00
不是实用和功利的问题,是实用和功利得太烂的水平问题。
真功利到家,就应该对“先上线再说”带来的风险和机会成本锱铢必较,并且保证能对预测失败负责。只不过大多没这本事,就糊弄过去了。
AmberJiang
2019-12-26 16:01:56 +08:00
@xiaotianhu 哭唧唧。。。我只是去面试一个初级数据分析师的职位。。。就被给问到差点怀疑人生😂我就是喜欢写代码才入行的 那人居然说技术不重要。。。
zappos
2019-12-26 22:59:14 +08:00
@xiaotianhu 这么理解是反技术的。考虑一个框架能不能用于生产,首先要考虑他是不是久经考验的,因为你没办法形式化证明他是可用的,那就依靠大数定律吧,越多人用,越少人出错,可用性就越高。

其次是要有充分的技术支持,就是出了错知道怎么办,这个一般是社区支持,还是越多人用越好。

这才是降低风险的方式。

至于每个人项目成员都看过源码,是不现实的,自己拿脑袋想都知道每个 web 程序员不可能都看过 spring 框架的源码,即使是 spring core,而那么多基于 spring 的 web 应用都照常转。

如果要求项目成员至少有一个看过源码,或者负责拍板的人看过源码,这个是合理的。
zappos
2019-12-27 11:44:59 +08:00
计算机就是一面由石子垒成的墙,不可能每个石子都是地基。如果你非得让每个石子都接触地面,墙也就垒不高。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/632044

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX