谈程序员的工作与工作的意义问题
之前提到谈意义本身是一种信号,代表着我们有一些不满。因此这里就具体到工作上,谈一谈工作,特别是程序员的工作。
工作的目的是什么？虽然可能有很多种回答,但最通俗的讲,是为了赚钱,具体一点讲,是为了活下来。对于快乐的追求和对于死亡的逃避,在工作上开始正面交锋。对于工作意义的讨论,基本都是在抒发"我工作很不爽但是又必须要工作"这个并不复杂的逻辑链路而已。
因为主题不同,我们很遗憾的在这里必须将工作作为一种前提,而非讨论如何不工作的问题。
由此将对工作意义的讨论,变成如何在工作中过得开心这样一个具体的问题。
编码中的心流
程序员的工作是什么？就古典的回答来讲,程序员可以视作代码的产出者。这种视角就好比在说奶牛吃的是草产出的是奶,将代码当作一种物质化的手工艺品,我们同19世纪叮叮打铁的铁匠一样,产出的是一个个独立而毫无联系的物质性产品。
然而信息时代已降,工作早就从对物质的操作转向了对信息的操作。财务、人事的工作很难有某种物质性的产出,而更多的是Excel表格。
对于程序员来说,我们所面对的更多是通过代码来操作各种抽象概念:数据库、操作系统、浏览器等等。
我们的日常工作是什么？从不熟悉的人看来是将手指在键盘上随机敲击,实际上则是在构造与维护不同的抽象层次,使得一个业务上的问题被足够稳固的抽象层次所表达、所实现。
我们的产品本身也是一个对象,用户对它有很多问题、很多期望、很多要求,这些都是这个对象自身所具备的能力。如果一个产品自己会说话,那么它在完成工作时肌肉是否流畅？是否能多快好省？这些都依赖它底层所支撑的抽象。
心流指的是你处在一种专注的状态,能够全身心投入到问题中。对于我来讲,这更多是指我所面对的问题的抽象层次和我拥有的工具的抽象层次相隔不高。我可以组合一些现有的东西来完成要做的事情。这就好比要去取放在高处的一个物品,于是你组合了近处的几个箱子垫在脚下,轻松地取到了。
编码让人舒服,不是因为代码天然有魅力,而是因为代码更容易被对象化。
对象化才是关键
写代码时为什么容易有心流？因为这里的问题被我们看成了对象,能拆解、能组合、能构造、能验证。
所以真正让人爽的不是"敲键盘",而是:
面前有一个对象
你能描述它
你能操作它
你能看到反馈
你能逐步把混乱变成秩序
程序员最容易获得心流的部分,往往是那些已经被形式化、对象化的工作部分,例如代码、系统、接口、数据结构。
不爽来自尚未对象化
但如果心流只存在于写代码的时候,那它就只是一种狭窄的技巧性感受,而不是一种工作的总体方法。
真正值得追问的是,为什么我们在编码时容易进入心流,而在需求讨论、问题排查、协作沟通这些环节里却往往只感到烦躁。
也许区别并不在于前者是"技术工作",后者是"非技术工作",而在于前者更早地被我们对象化了:我们知道它的边界,知道它的结构,知道该如何拆解、组合、验证。
那些让人不爽的部分,并不是不能进入心流,而只是还没有被我们当作对象来处理。
比如:
模糊需求
反复沟通
性能问题
线上故障
产品分歧
协作摩擦
这些东西让人烦,不一定是因为它们比写代码更难,而是因为我们还没有把它们当作可处理的对象。
许多工作的痛苦,不是来自混乱本身,而是来自我们还没有找到把混乱对象化的方法。
"非编码工作"不是对心流的破坏,而是心流尚未抵达的地方。
恐惧与对象化
我们面对工作时的情绪,尤其是恐惧,并不只是性格问题。很多时候,它来自一种无能感。
所谓无能,并不一定是真的没有能力,而是我们暂时看不到这个问题该如何成为一个对象,看不到它该如何被分解、被操作、被验证。
当一个问题还只是模糊的一团时,它对人的作用首先不是理性的,而是情绪性的。它会让人烦躁,让人拖延,让人恐惧。
恐惧的来源,不只是困难本身,而是这个问题与我们手头对象化工具之间存在过大的距离。我们不知道从哪里下手,不知道可以调用什么,不知道该先切哪一刀。
这和心流恰好构成一组对应:
距离合适 -> 可组合 -> 有反馈 -> 心流
距离过大 -> 不可拆解 -> 无从下手 -> 恐惧
一旦我们看到了分解的可能性,看到了边界,看到了第一步操作,恐惧就会迅速减弱。问题才开始真正成为问题,而不是一团压迫性的混乱。
学习、经验与对象化
从这种对象化的视角来看,所谓看到分解的可能性,很多时候就是学习。
学习并不只是积累一些零散的知识,而是在吸收别人已经完成的对象化成果。我们看别人的代码、看别人的设计、看别人的排障过程、看别人的经验分享,本质上都是在学习别人如何给问题划边界,如何命名对象,如何拆出层次,如何找到第一步操作。
一个问题之所以让人感到压迫,往往不是因为它绝对无解,而是因为我们手头还没有足够的对象化工具去接住它。学习的过程,就是不断扩展这个工具库的过程。
所谓经验,也并不神秘。它更多只是我们使用这些工具是否顺手的结果。同样一批对象化工具,新手需要反复试探才能调用,熟手却能很快看出问题像什么、该先切哪里、该调用什么。经验不是某种额外的天赋,而是对象化工具被反复使用之后变得熟练、自然、低成本。
因此,学习不是给自己增加负担,而是在为未来减少恐惧。你学到的每一种拆解方式,每一个看问题的角度,每一种处理混乱的路径,都会让更多原本压迫性的东西,逐渐变成可以上手操作的对象。
对于程序员来说,比较幸运的是,对象化的成果往往有一个清晰的载体。
举一个具体的例子。假设你日常需要管理 AI agent 的对话记录:列出对话、查看内容、备份到云盘。如果没有对象化,每次你都需要临场发挥:打开数据库,手写 SQL,处理输出格式,拼接同步命令。这些步骤散落在你的记忆里,每次都要重新组装一遍。
但如果你把这些操作写成一组以对象名命名的脚本函数:
agent-list-cx-conv # 列出对话
agent-cat-cx-conv # 查看对话内容
agent-sync-cc-conv # 备份对话到云盘
事情就完全不同了。你只需要 source 这个脚本文件,然后输入 agent- 再按 tab,所有可用的动作就出现在眼前。你不需要记住怎么做,只需要知道有什么可以调。
这里关键的不是脚本里写了什么逻辑,而是它的组织方式:以对象名统一命名,集中存放,可检索,可发现。看名字就知道操作什么对象、做什么动作。命名本身就是索引,不需要额外的文档。
这就是程序员工作中对象化最直接的体现:把经验固化成可调用的动作,并且让这些动作可被发现、可被检索。你和"管理对话记录"这件事之间的距离,从"打开数据库、写 SQL、处理格式"缩短到了"敲一个命令"。
所以程序员的学习,很大程度上就是在扩展自己可调用的对象库。而所谓成长,也可以理解为:你能识别、调用、组合的对象越来越多,你能处理的问题边界也就越来越大。
所谓更好的工作,不是逃离这些模糊部分,而是把它们也变成可进入心流的对象。这样的心流过程,不论是工作还是我们自己的项目,都是我们所要追求的。