程序员的快乐与苦恼

随着大环境的下行，互联网行业也受到一定的冲击，哀鸿遍野。

笔者也没有幸免，培养起来的人马陆续被优化，留下一丢光杆司令，我也回到的业务一线，心里很不是滋味。留下来的人，也不知道这艘船什么时候会沉没… 为了活命而拼命挣扎（内卷）

负面情绪和焦虑不停侵扰，以至于怀疑，当初选的这条路是不是正确的。

捡起买了多年，但是一直没看的《人月神话》, 开篇就讲了程序员这个职业的乐趣和苦恼，颇有共鸣，所以拿出来给大家分享

不管过去多少年，不管你的程序载体是纸带、还是 JavaScript，不管程序跑在高对比(high contract)的终端、还是 iPhone，程序员的快乐和烦恼并没有变化。

尽管国内软件行业看起来不是那么健康。我相信很多人真正热爱的是编程，而不仅仅是一份工作，就是那种纯粹的热爱。你有没有：

• 
  
• 为了修改一个 Bug，茶饭不思
  
• 为了一个 idea，可以凌晨爬起来，决战到天亮
  
• 我们享受没有人打扰的午后
  
• 梦想着参与到一个伟大的开源项目
  
• 有强烈的分享欲，希望我们的作品可以帮助到更多人, 希望能得到用户的反馈，即使是一个点赞
  
• …
  

我们的快乐

《人月神话》：

首先，这种快乐是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到快乐一样，成年人喜欢创建事物，特别是自己进行设计。我想这种快乐是上帝创造世界的折射，一种呈现在每片独特的、崭新的树叶和雪花上的喜悦。


其次，这种快乐来自于开发对他人有用的东西。内心深处，我们期望我们的劳动成果能够被他人使用，并能对他们有所帮助。从这一角度而言，这同小孩用粘士为“爸爸的办公室”捏制铅笔盒没有任何本质的区别。


第三，快乐来自于整个过程体现出的一股强大的魅力——将相互啮合的零部件组装在一起，看到它们以精妙的方式运行着，并收到了预期的效果。比起弹球游戏机或自动电唱机所具有的迷人魅力，程序化的计算机毫不逊色。


第四，这种快乐是持续学习的快乐，它来自于这项工作的非重复特性。人们所面临的问题总有这样那样的不同，因而解决问题的人可以从中学习新的事物，有时是实践上的，有时是理论上的，或者兼而有之。


最后，这种快乐还来自于在易于驾驭的介质上工作。程序员，就像诗人一样，几乎仅仅在单纯的思考中工作。程序员凭空地运用自己的想象，来建造自己的“城堡”。很少有创造介质如此灵活，如此易于精炼和重建，如此容易实现概念上的设想(不过我们将会看到，容易驾驭的特性也有它自己的问题)。


然而程序毕竞同诗歌不同，它是实实在在的东西;它可以移动和运行，能独立产生可见的输出;它能打印结果，绘制图形，发出声音，移动支架。神话和传说中的魔术在我们的时代已变成现实。在键盘上键入正确的咒语，屏幕会活动、变幻，显示出前所未有的也不可能存在的事物。

编程就是一种纯粹创造的快乐，而且它的成本很低，我们只需要一台电脑，一个趁手的编辑器，一段不被人打扰的整块时间，然后进入心流状态，脑海中的想法转换成屏幕上闪烁的字符。
这是多巴胺带给我们的快乐。

我们也有「机械崇拜」，软件不亚于传统的机械的复杂构造。 它远比外界想象的要复杂和苛刻，而我们享受将无数零部件有机组合起来，点击——成功运行的快感。

我们享受复杂的问题，被抽象、拆解成一个个简单的问题， 认真描绘分层的弧线以及每个模块轮廓，谨慎设计它的每个锯齿和接口。

我们崇尚有序，赞赏清晰的边界， 为的就是我们创造的世界能够稳定发展。

我们认为懒惰是我们的优点，我们也崇拜自动化，享受我们数据通过我们建设的管道在不同模块、系统或者机器中传递和加工；享受程序像多米诺骨牌一样，自动构建、测试、发布、部署、分发到每个用户的手中，优雅地跑起来。

因为懒，我们时常追求创造出能够取代自己的工具，让我们能腾出时间在新的世界探索。比如可以制造出我们的 Moss，帮我们治理让每个程序的生命周期，让它们优雅地死去又重生。

我们是一群乐于分享和学习的群体，有繁荣的技术社区、各种技术大会、技术群…

不管是分享还是编程本身，其实都是希望我们的作品能被其他人用到，能产生价值：

• 
  
• 我们都有开源梦，多少人梦想着能参与那些广为人知开源项目。很少有哪个行业，有这么一群人, 能够自我组织，用爱发电、完全透明地做出一个个伟大的作品。
  
• 我们总会怀揣着乐观的设想，基于这种设想，我们会趋向打造更完美的作品，想象未来各种高并发、极端的场景，我们的程序能够游刃有余。
  
• 我们总是不满足于现有的东西，乐于不停地改进，造出更多的轮子，甚至不惜代价推翻重来
  
• 我们更会懊恼，自己投入大量精力的项目，无人问津，甚至胎死腹中。
  

看着它们，从简单到繁杂，这是一种迭代的快乐。

我们的苦恼

《人月神话》
然而这个过程并不全都是快乐的。我们只有事先了解一些编程固有的苦恼，这样，当它们真的出现时，才能更加坦然地面对。


首先，苦恼来自追求完美。因为计算机是以这样的方式来变戏法的: 如果咒语中的一个字符、一个停顿，没有与正确的形式一致，魔术就不会出现(现实中，很少有人类活动会要求如此完美，所以人类对它本来就不习惯)。实际上，我认为，学习编程最困难的部分，是将做事的方式向追求完美的方向调整"。

其次， 苦恼来自由他人来设定目标、供给资源和提供信息。编程人员很少能控制工作环境和工作目标。用管理的术语来说，个人的权威和他所承担的责任是不相配的。不过，似乎在所有的领域中，对要完成的工作，很少能提供与责任相一致的正式权威。而现实情况中，实际(相对于形式)的权威来自于每次任务的完成。

对于系统编程人员而言，对其他人的依赖是一件非常痛苦的事情。他依靠其他人的程序，而这些程序往往设计得并不合理、实现拙劣、发布不完整(没有源代码或测试用例)或者文档记录得很糟。所以，系统编程人员不得不花费时间去研究和修改，而它们在理想情况下本应该是可拿的、完整的。

下一个苦恼 —— 概念性设计是有趣的，但寻找琐碎的bug却是一项重复性的活动。伴随着创造性活动的，往往是枯燥沉闷的时间和艰苦的劳动。程序编制工作也不例外。

另外，人们发现调试和查错往往是线性收敛的，或者更糟糕的是，具有二次方的复杂度。结果，测试一拖再拖，寻找最后一个错误比第一个错误将花费更多的时间。

最后一个苦恼，有时也是一种无奈 —— 当投入了大量辛苦的劳动，产品在即将完成或者终于完成的时候，却己显得陈旧过时。可能是同事和竞争对手己在追逐新的、更好的构思;也许替代方案不仅仅是在构思，而且己经在安排了。

前阵子读到了 @doodlewind 的 全职开源，出海创业：我的 2022，说的是他 all in 去做 AFFiNE 。我眼里只有羡慕啊，能够找到 all in 的事业…

这些年 OKR 也很火，我们公司也跟风了一年; 后面又回到了 KPI，轰轰烈烈搞全员KPI, 抓着每个人, 要定自己的全年KPI; 再后来裁员，KPI 就不再提起了…

这三个阶段的演变很有意思，第一个阶段，期望通过 OKR 上下打通，将目标捆在一起，让团队自己驱动自己。实际上实施起来很难，让团队和个人自我驱动起来并不是一件容易的事情，虽然用的是 OKR，但内核还是 KPI，或者说 OKR 变成了领导的 OKR。

后面就变成了 KPI, 限定团队要承担多少销售额，交付多少项目；

再后来 KPI 都没有了，换成要求每个人设定自己工作日历，不能空转，哪里项目缺资源，就调配到哪里，彻底沦为了人矿…

能让我们 all in 的事情，首先得是我们认同的事情，其次我们能在这件事情上深度参与和发挥价值，并获得预期的回报。这才能实现「自我驱动」

对于大部分人来说，很少有这种工作机会，唯一值得 all in的，恐怕就只有自己了。

所以程序员的苦恼很多，虽然编程是一个创造性的工作，但是我们的工作是由其他人来设定目标和提供资源的。

也就是说我们只不过是困在敏捷循环里面的一颗螺丝钉，每天在早会上机械复读着：昨天干了什么，今天要干什么。

企业总会想法设法量化我们的工作，最好是像流水线一样透明、可预测。

培训机构四个月就能将高中生打造成可以上岗敲代码的程序员。我们这个行业已经不存在我们想象中高门槛。

程序员可能就是新时代的蓝领工人，如果我们的工作是重复的、可预见的，那本质上就没什么区别了。

追求完美是好事，也是坏事。苛刻的编译器会提高开发的门槛，但同样可以降低我们犯错的概率。

计算机几乎不会犯错的，只是我们不懂它，而人经常会犯错。相比苛刻的计算机，人更加可怕：

• 
  
• 应付领导或产品拍脑袋的需求
  
• 接手屎山代码
  
• 浪费时间的会议
  
• 狼性文化
  
• …
  

还有一个苦恼是技术的发展实在太快了，时尚的项目生命周期太短，而程序员又是一群喜新厌旧的群体。

比如在前端，可能两三年前的项目就可以被定义为”老古董”了，上下文切换到这种项目会比较痛苦。不幸的是，这些老古董可能会因为某些程序员的偏见，出现破窗效应，慢慢沦为屎山。

我们虽然苦恼于项目的腐败，而大多数情况我们也是推手。

我们还有很多苦恼：

• 
  
• 35 岁危机，继续做技术还是转管理
  
• 面试的八股文
  
• 内卷
  
• 被 AI 取代
  
• …
  

对于读者来说，是快乐多一些呢？还是苦恼多一些呢？