两万字长文：聊聊程序人生

北京时间晚 10 点钟，我在 Clubhouse 上聊了一下程序人生以及大家感兴趣的技术话题。以下是我聊的主要内容的一个复盘，主要把大家的问题及回复的部分收录进来，没有包含之前聊了半小时的程序人生的历史。其中的问题以及一些探讨我做了精简，也补充了一些在语音聊天时无法附上的图片。文章很长，大约 2w 字，阅读需要谨慎.

以下是聊的主要话题，大家可以有选择地跳到相应的问题去：

• Q1：我想独立完成一个产品，技术上该怎么提升？
• Q2：你是怎么找到好玩的项目的？
• Q3：公众号技术文章如何拿捏风格？
• Q4：如何记日记？
• Q5：看过的或者学过的技术，如何在需要的时候找回来？
• Q6：在工作中如何使用 Notion？
• Q7：程序人生未来写什么？
• Q8：未来开个育儿经的房间？
• Q9：如何看待 clubhouse？
• Q10：该问题已失效
• Q11：如何看待递爪？
• Q12：微信上也可以语聊，为啥用 clubhouse？
• Q13：如何看待产品破圈后调性下降？
• Q14：如何让自己尝试的技术能够深度使用？
• Q15：大公司很难引入新技术，元芳，你怎么看？
• Q16：如何避免搬砖？
• Q17：如何定义搬砖？如何形成反搬砖的文化？
• Q18：如何处理有限的资源和产品质量之间的冲突？
• Q19：团队做大，人才密度是肯定下降的，不能要求人人都有主人翁的心，能不能用精细的流程来避免搬砖？
• Q20：feed parser 那样的改动就不能做自动化吧？如何更好地做流程自动化？

以下正文。

---

Q1: 我想独立完成一个产品，技术上该怎么提升？

A：首先你要看你对自己的一个定位，刚才最后你提到你希望你自己能独立完成一款类似于像视频通话这样的产品 —— 如果定位是这样子的话，你可能所需要的学的东西会稍微杂一点。如果说你单纯的把自己定位成一个前端工程师，后端工程师，或者 ML 工程师，那就去学习各自的技术栈。但围绕着如何一个开发者如何能做出一款自己的产品这个角度来去定位的话，你得需要掌握 1）一个跟用户界面开发相关的语言和它相关的技术栈。2）掌握一门后端开发的语言和这门开发语言背后的 web 的开发栈。

然后你在掌握了就是前端的和后端的基本的技术之后，当你做产品的过程中一定会遇到很多的问题。所以我们要带着问题去学习。当你去为了一个目标 —— 一个可能你现在很难够到的目标 —— 构想一个产品，然后去实现这个产品时，这个过程中你会发现你缺很多其他的知识。比如数据采集，数据分析等等。这些知识我怎么样去弥补？在开发的过程中，我用什么样的架构？假设我没有接触过前端的开发，那前端开发这个领域里面究竟有什么样的流派，然后他们都各自使用什么样的架构？什么样的架构是大家公认比较好的？这个架构我自己是不是认同？带着这些问题，你会有很多需要去深挖的东西。甚至你可能需要去看一些大咖们写的书，比如 clean architecture。然后看 clean architecture 的思想怎么样跟做一个具体的产品去映射。这个实现的过程就像一个旅途，你需要很多人的帮助 —— 这些人可能是 YouTube 或者 B 站的 up 主，可能是 medium，hackermoon 甚至程序人生的博主，通过吸收和消化这些你为了解决具体问题而寻找的助力，这些东西就内化成你自己的东西。

这个过程是一个相互缠绕的学习过程，它不是说我先去把相关的知识，相关的书籍读一遍再开始，而是边做边学，边做边探索，然后总结，内化。就像一个一个飞轮一样不停的不停的在往前滚，然后在这个过程中你会不断的去会探索到新的领域。当到达某个程度的时候，你会面临某个技术是自己做还是找供应商。我在「供应链管理」一文中说过，现代软件越来越复杂，一个人乃至一个团队不可能解决所有的问题，造所有的轮子。比如 ClubHouse，它实时语音用了声网的技术，而 pubsub 用了 pubnub 的技术。当你在产品中遇到 pubsub 这样的技术问题时，你会有几条路：1) 自己构建 2) 找开源实现，比如 http://nats.io 3）上云服务，如：pubnub，pusher，aws SNS 等。去用第三方的 SDK 构建你的产品是一个很好的思路，你可以学习到那些优秀的 SDK 是如何构建它们的接口的。很多软件用起来舒服的第一个要素就是它的接口定义地很好，接口的抽象把细节隔离地很好，然后又能把该提供的能力都提供给你。比如我们每天都在用的 Git。Git 就是一个非常优秀的软件，它提供了high level的 API 给大家使用，然后也提供了非常 low level 的深入到 blob 级别的 API 给你充分的自由。

Q2：你是怎么找到好玩的项目的？

A：这是个好问题。这涉及到一个信息来源的问题。我平时会逛一些各种各样的软件网站，比如说我会订阅很多种语言的邮件列表，然后每周这些邮件列表发送时，不是说所有的文章我都会去看，我只是会扫一下他们的标题，看看有什么感兴趣的东西，然后我在深入了解。我一周会逛个两三次 hacker news 和 github trending。在 github trending 上我会过滤一下我所关注的语言，看看有什么有意思的新的项目出来。这就是我很多新的想法，新的东西的一个很重要的来源。比如说像 Erlang/Elixir。这个技术我最早接触还是在途客圈时代。我读了「七周七语言」那本书。我的朋友和同事驰远他说他的同学 Falood 在做 Erlang，我当时肃然起敬。当时无缘招募 Falood，但人生就是非常奇特的，后来 Falood 就加入了 Tubi。那是我第一次接触 Erlang，后来大概是 2015 年我在 hack news 里面看到了 Erlang 的创始人 Joe Armstrong 写的他自己是用Alexa的一些心得(老爷子很不幸地在两年前去世了）。当时他的那篇文章把我带入了 Elixir。我觉得这是一篇很有意思的语言，集合了函数式编程，强大的并发处理能力，以及宏编程这几种能力。后来我就发现 Elixir 语言在当你把 Macro 和并发能力结合起来的时候你会你会有一些意想不到的收获。比如说我之前写的文章介绍我在 Tubi 如何做 policy engine，见「policy engine 的前世今生」。通过使用宏，我把数据从数据库中读取出来，生成几十万个上百万个函数，然后完全用语言本身的 pattern matching 能力把参数 dispatch 给合适的函数，从而达到微秒级别的访问速度。如果让我换另外一个语言的话，这件事情可能就就很难去做，或者说得用另外一种方式去做。所以这是这是为什么我会去探索 Erlang/Elixir。我后来在 ArcBlock 期间开始探索 rust，我尝试用Rust 去解决一些深层次的技术难题，（通过 Rust 和 Elixir 的 FFI）进一步提升 Elixir 的能力。我过去写的多东西也是受到了 hacker news 和 github trending 上面很多项目的影响，比如 noise protocol。所以我觉得大家也可以去围绕着自己的核心的技术能力去订阅一些不同的邮件列表，尤其是你自己语言的相关的邮件列表，看看这个世界上其他人都在做些什么都有一些什么有趣的项目 —— 也许某个项目就可以在你下一个无论是个人的还是公司的项目里面去使用到。

另外偶尔可以去看一看各个开发者聚集的地方，大家都在讨论些什么。Reddit 是一个不错的源泉。我时不时回去 r/rust 看看。当然，还可以通过订阅程序人生获取一些不同的信息的来源。

Q3：公众号技术文章如何拿捏风格？

A：谢谢，对，我觉得这是一个很好的问题，我在写文章的时候，我会刻意注意自己的文章，不要太过于干涩，所以会引入一些小小的引入一些段子，然后用一些网络用语，因为我是觉得大家一天到晚面对机器，面对技术本身，如果读到的东西又是非常非常干涩的话，可能会有点吃不消，所以我会在文章中稍微加一些俏皮的东西。这一点我在像其他领域的人学习。

比如说你怎么样把法律这件事情能解释地娓娓道来，那罗翔老师就给我们展示了一个极其生动的例子 —— 他生动的制造了一个法外狂徒张三。

当然我没有罗翔老师的那种能力了，但是我也想文字本身生动，再加上能再带一点点优美，那么是对这个文章本身干货的一个最好的补充，所以我在朝这个方向去努力，但确实这件事情本身是非常困难的，、段子这些东西偶尔说个一两次，可能也就罢了，说多了大家也会觉得很无聊，那么我可以夹杂一些我的思考，思想在里面，甚至在夹杂我的思考思想的过程中，我可以放一些名人名言，我会掺杂一些我在电影中的，对某个电影中产生的共鸣，读书读到的优美文字。如果把这些东西和我要写的东西结合起来，可能会产生非常不错的效果。

当然要达到这一步的话，你平日里面可能需要有有比较多的阅读，有比较多的积淀。比如说你没有看过了不起的盖茨比的话，你可能也没办法去把文中的某个场景去跟这个盖茨比里的场景去连接起来。我自己写公众号，也写了有七年多的时间了，也慢慢累积了一些我个人的套路，素材，行文方式，以及表达方式。

另外一个方面，就是如何避免把技术写成流水账。这块我觉得是是一个表达方式的问题，其实是你怎么样把你的思想以一种就是更好的方式组织起来，这个可能是一个写作能力的方面的问题 —— 我们如何提高自己的平日的写作能力，把一些对事件本身的描述避免流水账。

比如说我要做的这个东西，首先它的核心部分是什么，我肯定是要把核心部分的探索放在最重要的位置，围绕他服务的文字要最多。然后另外当你传递一种思想的时候，你可能想好你的听众是谁，你怎么样去一步步阐述：首先为什么你要这么做，然后你做了些什么，最后才是你怎么样一步步做到这儿的。当人们因为为什么你做这件事情，或者为什么要来讲这么一个主题，产生共鸣的时候，后面的阅读就会比较比较自发，比较舒服。但如果说我们上来就在陈述这个事情本身，从第一步到第十步是怎么做的，看完了文章之后，大家还没有解决掉一个关于 why 的疑惑的话，可能就读起来会比较觉得干并且吃力。

Q4：如何记日记？

A：首先我现在还保持着日记的习惯，但我的日记不一定是真的日记，更像是一个一天有趣的事情的一个简单缩略。我现在写日记的方式略有不同：我在notion里面建了一个template，或者说，一个Marco，然后 macro里面放了一个九宫格，每周点击一次，自动生成这周的日记模板。

你可以想象一下它是一个九宫格页面，每天一个格子，然后做一个总结，大概是这样一个日记的形式。

这个形式也就意味着我每天记载的内容就是一小块，我一般一天日记会非常简短，可能每天我就花个5分钟左右的时间去写。写什么呢？我会记录这一天我过了之后有哪些事情值得我回忆。哪怕就写几个字一两句话可能就足够了，因为半年之后，我翻开你的日记，我看到这个东西就会就把自己可能埋藏在记忆深处的这个东西和写的内内容连接起来了。

因为我们的大脑的运作是，很多事情久了它就不会停留在大脑皮层，而是被放到深度记忆区，你需要的就是一个指针，通过这个指针，把深度记忆区里面的记忆唤醒。我的日记大部分起的作用就是这样。因为很多时候我们只要把一天中最记录最重要的东西记录下来，对我来说那就就够了。

我记得在看朗读者时，当时许渊冲老先生跟董卿聊的时候他说过一句话，我记忆特别深刻：他说 —— 生命不在于你活了多少日子，而是你记住了多少日子，所以我们要做的事情就是让你过的每一天都值得回忆。我当时听了这个就特别有感触，某种程度上我记日记的目的可能就是恰恰为了这个目标而记录。所以我并不是每一天都会记日记，我可能一周里面会空空出来好多天，因为那些天并没有发生特别多让人值得怀念的东西，但是有时候可能一周我的日记都是填满的，因为这周发生了太多的事情，无论是喜怒哀乐，无论是公司层面遇到的挫折，还是我很不爽的某些事情，还是我很开心，自己的很有成就的事情，我都会把他们写下来。

Q5：看过的或者学过的技术，如何在需要的时候找回来？

A：我的方法就是我在开始看某个东西时，如果我可能觉得未来我在某个场景下会去使用它，我会在我的笔记的对应的主题下面，如果说没有那个主题的话，开个主题，然后把链接放进去，然后把它的一段介绍贴进去，比如说我在 Github 上 Star 了很多很有意思的做搜索的项目，比如说现在在 Rust 上面比较火的一个叫 meilisearch，一个叫 Sonic，这些东西我现在并不需要，所以我现在可能不见得会用到他们，但是我会放在搜索的主题下面，下次我要深入了解探索这个方向的时候，那么可能会深入探索。

这是我自己的一个方法，它跟前一个话题其实有点相关，现在我们面临的信息是越来越多，这些信息你怎么把它连接起来，我相信每个人都可以有自己独特的方式，我的方式就是我把它记到 Notion里，因为是我自己的笔记本，我知道我自己记录的方式，所以很容易超找到。

不光是 Github repo，还有我在 Youtube 和 B 站上看过的视频，我都会放在专门的页面里面，做成 database。在看的时候我会 Cmd + Ctrl + Shift + 4 截屏，然后将其粘在页面里。

除了收集之外，还要主动去思考，通过思考，也很容易把你学过的东西，Star 过的项目串起来。

因为我曾经在文章《探索 Notion 的实现》中也讨论过，如果自己要做一个 notion 的话，应该怎么样去做，还有什么问题需要我去去解决。我觉得平时大家有很多这种思考是非常必要的，我之前也跟我的小伙伴 1: 的时候，提到如果多少年之后成为一个什么样的人，比如架构师，那么其实你需要做的就是你平时对你所用的东西，你感兴趣的东西，保持一份好奇心：你看到一个一个产品，就要去想这个产品背后的逻辑是什么，它的功能是怎么样实现的。如果我自己要实现的话， 这一块功能，那块功能我该用什么样的工具实现，我是自己实现，还是我拿第三方工具，我有哪些工具可以使用。这样你就可以把平日里看到的东西和你的思路串联起来。

你可以顺便多想一些，比如：如果真得要实现的话，实现到一个什么样的程度，大概花多少钱？这些东西我觉得可以反复可以在自己的脑海里面去探索，你不一定去做，因为很多时候我们遇到的东西太多了，真正值得你去深入下面去做的，一年可能也就是两三个，因为你的时间精力毕竟有限。大部分的时候你即便不做，你可以去想，因为想本身想的过程就本身已经足够好了，因为你在思考的时候你会你会遇到问题，这个问题即便你不是去写代码解决，你也可以通过去搜索，你可以去看看别人是别人的解决方案是什么，甚至你可以对这个产品本身做 reverse engineering，去验证你的想法和人家做的是不是一样。我记得当大家在吐槽 notion 总是很慢的时候，当时我看了他的 API，我就觉得当 notion 发展到某个程度的时候，他的慢是不可避免的，因为它大量的这种和服务器端的通讯过于低效，它又无节制的允许你分享内容，允许你分享给非常多的人。我们知道 clubhouse一个房间的上限是 5000 人，这些都是产品上的考量，而 notion 几乎我现在还没有试出来一篇文章分享的上限。

这些东西其实都是你在思考，你在使用 reverse engineering 的时候，你会发现这是一个问题，他没有解决好。那我该怎么样解决呢？我的方法是不是好，如果好为什么好，如果不好的话，还有什么更好的解决办法等等。这个循环往复的过程会让你的进步会很快，很多人说我在大公司里面或者在公司里面，我作为一个程序员就是一颗螺丝钉，每天能接触的事情就那么一点，那是因为很多时候有一个更广阔的世界我们可能还没有去发现。

Q6：在工作中是怎么使用 Notion 的呢？

A：我自己个人有一个 notion 的账号，在工作中有一些临时的记录，比如说开会 action item 的 follow up 等等，这些东西我会我用 notion 去记录，包括每天工作中有一些想法，这些我会用 notion 去记录。我在 notion 里面专门有一个区域是「工作」，我会把工作和生活区隔开。我们公司有部分团队也在尝试，在 notion 里管理项目，管理大家的交流，其实是一个不错的选择。

Q7：程序人生未来写什么？

A：一开篇的时候我讲，到了 16 年 17 年的时候，我把公众号的主题切换到主要就只写技术和产品相关的东西，产品的话大概就占个10%， 20%的比例，那么未来我还是会继续以这样一个方向去写，因为写到现在，说实话我已经不太在乎有多少粉丝，我有没有可能写出 1 万加的文章。现在真的就很淡了，反而是我把写作作为一个我技术的出口 —— 一个平日里面我获取的那么多内容的这么一个出口。我记得村上春树描述过他为什么去做写作，大概意思他说一件事情必须要兼具入口和出口，人活的久了就会会主动或者被动的接受很多的东西，得出很多感慨，这些东西都是入口，如果你像一个黑洞一样，你不断的去吞噬一些东西，你就会在泥沼里面陷得越来越深，如果你只有入口没有出口的话，总有一天你的大脑就会炸掉，所以我们才有跟别人去倾诉，对吧，如果不能向亲近的人倾诉，就向陌生人倾诉，这是出口，写作对我来讲大概就是这么一个出口。它对他对我的读者的好处是可能某些文章某些句子能帮助读者们去点亮思维，能给他们带来更多的想法，对我来讲是一个复盘，一个出口。所以我会还是会继续写这种比较深度的技术文章，我会把我的口水文的比例会减得非常得低。

对于我来讲，现在更首要的是写一篇文章，我要对得起我自己付出的时间，通过写作，我把对自己所掌握知识，有一个夯实的过程。就像柳传志说的「撒一层土，夯实，再撒一层」。

对于我在这个过程中用的工具，比如说文字，我以前是就在 vscode 里写 Markdown，用一个 github repo 来保存。当要发布的时候，我把 Markdown 构建成一个个 html 页面，然后用浏览器把页面打开，整个拷下来粘到公众号的编辑器里面。现在我用 notion，因为平时碎片的东西就往 notion 里面塞，比较方便，尤其是截图我一截，往里一粘就可以了。绘图的话，我主要现在用两个工具，一个是 plantuml。这个工具是你可以通过一些预设的语法来做各种各样的 uml 图。我在我之前写的一篇 《那些年，我追过的绘图工具》里面介绍过。最近我使用的一个比较多的绘图的工具叫 excalidraw。这是一个开源的项目，我觉得是一个非常好的 visio 或者lucidchart 这样的画复杂的流程图的一个开源的替代品，它用起来真的非常的简单，他把你的能力就限制在几种图形，和几个线条下面，让你可以聚焦在你自己所要表达的东西本身。它提供了很方便的快捷键，用熟了可以让你非常高效的把你的脑海中想要做的东西绘制出来。这个工具我未来会打算写上一篇，因为我觉得它真的是一个非常不错的工具，值得大家无论是工作还是学习去使用。我现在工作中的很多图也是用它来它来画。

另外一个就是大家可能一直忽略的效率工具是 makefile，它开箱即用，可以帮你自动化很多工作。

Q8：未来开个育儿经的房间？

A：我觉得很多时候优秀都是在人前展示出来的状态，背后还是有很多的心酸和和痛苦的。不过这也许是个好提议，我可以考虑一下。但其实说到育儿，绝大多数的时间是我老婆花心思在上面的，我就是一个当果树上已经长好了果实，摘果子的那个人。很多时候我在朋友圈里面秀的状态是我老婆在背后默默无闻做出来的功劳。

Q9：怎么看 clubhouse？

A：这几天带给我一个最大的感受，这很像是一个在咖啡厅里朋友们，之间一起就是随便聊聊什么话题，大家其实都是在不经意的做思维的输出的时候去影响到其他人。最近因为我自己也发了一篇关于我对 clubhouse 认知的文章，很多看了文章的朋友就会给我在微信里面转一篇品玩写的十万加文章，问我怎么看。

我觉得这个东西其实就是每个人有不同的看法，我们大家和而不同。我一般会回一句话 —— 一句我在很早之前好像在卡耐基大全里看到的一句话 —— 两个人从监狱的铁窗里望出去，一个看到了地上的泥土，而另一个看到了天上的星星。

很多时候大家活在一个不同的维度，不同的世界，看到的东西自然不同。我不觉得 clubhouse 是一个大家为了长粉高谈阔论或者是干什么的这样一个地方，反而我觉得他非常贴近我们的生活，就像我们现在这样的一种闲聊，也许聊一些有用的话题，也许聊一些没用的话题，那愿意听的就可以在上面旁听，听一耳朵；不愿意听的就可以静悄悄的离开，谁也不会对谁造成打扰，我觉得这是其实一个蛮好的状态。当然任何一个社交网络都会在它发展的过程中加入各种各样的噪音，这种状态能维持多久，它多大程度上能在用户不断破圈的过程中去做好用户的区隔。我觉得与其建一个像新浪微博那样的嘈杂的广场，倒不如建成一个又在一个就像在 minecraft 上面建成的一个又一个的小的市集。我觉得如果 clubhouse 能把这个区隔做好的话，未来前途还是还是很大的。

我觉得 clubhouse 爆红的一个很大的因素，也是因为在疫情下面大家憋得太久，很多本来原来能通过线下跟朋友之间喝咖啡喝酒聊聊天能解决的东西，现在突然大家都没有了出口，或者说出口一下子以指数级去降低，那么自然我们需要找到其他的出口，其他的出口，不是 clubhouse 也会是旁的什么。目前我觉得 clubhosue 是一个非常不错的，非常有意思的这样一个出口，也许未来国内会有相应的产品，很安稳的生长在 qiang 之内，那么也许我就会用那样的产品，最终一个产品它能帮助大家促进交流，产生共鸣，帮助大家去去得到不一样的思维，能看到不一样的东西，我觉得本身这就是一个很好的产品。

Q11：如何看待递爪？

A：我不是递爪的用户，但是我大概看了一下递爪的产品形式，我觉得跟 clubhouse 的产品形式和想要维护的一个社区的氛围还是有很多的不同。

比如说在递爪里面进入和退出是一个相对成本比较大的事情，而club house就很轻松，看到一个有趣的主题，你点一下就进去，并且你立刻收听到内容，你想说你举个手可能很快就能得到得到回应。你哪怕是作为一个嘉宾，你退出之后不聊了，也是一个很很自然事情，你不需要有任何社交负担心理压力的。在递爪上至少从我看别人文章的介绍上面，我并没有看到这种东西。

其实我们需要的是一个 clubhouse 这样和线下交流非常类似，负担很小的这么一个东西，也许接下来会出现类似的产品，

Q12：微信上也可以语聊，为啥用 clubhouse？

A：但是聊的体验和聊的体验就非常的不一样，首先如果你用视频聊的话，有人数的上限，你用语音聊的话，大家还得去抢麦抢话筒，那不是一个非常实时的聊天的方式。我觉得存在就有它的合理性，我们暂且可以去看他下一步会，走到什么样的这个程度，会有什么样的发展。

其实我觉得作为程序员，我们自己也可以去去想未来这样的东西它怎么样去发展，在用户端它在怎么样去发展，它对企业能带来什么样的好处。两层意思：通过类似 clubhosue 的软件企业和用户的交流能带来什么样的好处，以及在企业内部是不是能够成为一种新交流方式。比如说他是不是是可以成为一个在企业端的 zoom 的替代品，我在我的文章里面也有提到，因为大部分 zoom 的会议，当人一多之后，大家都是把摄像头关掉，其实就是一个语音的东西，是不是我们可以产生一个更好的形式，一个更轻便的形式在企业端去使用，尤其现在大家远程工作越来越多，未来即便疫情结束了，可能很多的团队还会继续使用远程工作这种习惯，但是远程工作和在同一个办公室，里面工作最大的不同就在于人和人之间的距离。在办公室里面工作我需要我要找到你，我跟你聊两句，这是一个很自然的事情，但是远程工作的时候，我无论是在slack里面聊，还是 zoom 会议，都太有侵入性。

用语言的话，用聊天本身的话，我觉得非常自然的可以拉近大家远程办公之间的距离，比如说大家可以建一个这样的群，平时就挂着，大家都不说话，a跟b想想讨论什么话题的，时候投一嗓子，如果b说 ok我现在有，时间我们聊聊，大家就两个人就拉一个单独，的房间就私聊，非常像我们平时在办公室里面办公对吧，两人需要讨论的什么问题，一合计就跑到一个小会议室里面，就开始弄。当然目前 clubhouse 的产品形态，并不是为这种方式服务的。

另外，我是觉得我们在在批判一个东西的时候，先去看它的合理性，先去想我还能做些什么，应该为他感到开心，为有这样的一个东西出现感到开心，就像一个小孩子一样，永远保持那种好奇心和想象力。我正好昨天晚上 —— 我们家是这样，周一到周日晚上的时间我都会安排跟我孩子做一些事情，周五的时候我们会看纪录片，周六的时候晚上会看看电影 —— 昨天晚上正好我们看了小王子这部片子，我非常推荐，大家如果没看过的话，就看一下。它是一个法国的动画片，2015年出的， b 站上面就有，大家可以去看。通过看小王子，我最大的感触就是：大家在不断长大的过程中，实际上是个不断丢失的过程。小孩子知道他们在寻找一些什么，他们把时间花在那些洋娃娃身上，等到我们变成大人了，我们对于一件事情的好奇心变低了，对于各种各样的星星，我们就把它们封存起来，进而把它们碾碎。我们永远是一个批判的态度，在看待事物的时候，先说他有什么不好，而不是先去看这个东西，五彩缤纷，非常美丽，很有意思。

我真得觉得我们需要把我们自己的真诚童心，藏起来的这部分要把它重新放出来。之后，你会发现生活会变得美丽很多。在看电影的时候，我对其中有几句话印象特别深刻，比如：

• 一个人只有用心去看，才能看到真实，因为最重要的东西是用眼睛是看不到的
• 所有大人都曾经是小孩，虽然只有少数人记得
• 你的玫瑰花，你在你的玫瑰花上耗费的时间，使你的玫瑰花变得如此重要

扯远了。

Q13：如何看待产品破圈后调性下降？

A：我觉得一个产品它必然最终是不断破圈的，但是就是圈和圈之间可以有足够的防火墙把他们隔离开。一个圈子如果说无论是从推荐系统的角度，还是在产品运营的层层面去做好，足够的区隔，是不同圈子的人，他们想发生关系的时候可以发生，关系，不想发生关系的时候，我就静静的呆在自己那个圈子里面，那就是比较理想的状态，因为我们的社会本来就是这样，三六九等是自然而然形成的，社会的圈子你很少会跟一个不在你圈子里的人发生很深度的对话。所以无论是知乎上发生的，微博上发生的，可能是跟破圈之后，就是防火墙做的不够不够好，或者说可能是我们自己变了，我们自己变得挑剔，那些真正我们口中所谓的下沉的人是他们在上面玩的很欢，让他们觉得这个东西很好，只不过是他们可能没有那么多的话语权，他们没有把他们的声音表达出来，最终导致感觉好像是一个产品破圈之后，这个产品的调性就没了，我承认是肯定会存在这种这个问题的，但是破圈对产品本身是好事。当然对产品最早的使用者可能不一定是好事。

Q14：如何让自己尝试的技术能够更深度地使用？

A：这是一个非常典型的就是做技术的人会遇到的困惑，我也会有这种困惑，我的解决方法就是把它写下来，两两层写，一层是我把我尝试过的好玩的，东西我写成文章，这是一层写下来；第二个是我把我好尝试过的好玩的东西，真正把它应用到一个产品里面，就是第二层写。你刚才讲的困惑是更多是在第二层，那就是我尝试的东西在工作中用不到，怎么办？我不可能为了这样一个兴趣我去换工作？

我可以举一个特别典型的例子，当然很多人可能说是因为我的屁股坐的位置（VP）决定了我的这个例子可以成功，我们先不妨讲一下这个例子，还是跟 Elixir 在 Tubi 的使用有关。之前 Tubi 的整个技术栈用 NodeJS 和 PHP 来构建的，elixir 并不是其中一个选择。我在喜欢上 Elixir 之后，我很想把它用在产品中，我做了很多小的project，但是没有机会在 production 里面去使用它，你知道对于任何一家公司来讲，去在 production 去尝试一个新的技术都是非常有挑战的，挑战不仅来自于技术层面，更多的来自于大家对未知的恐惧：你怎么样去说服别人，这个东西一定是好的呢？你怎么样去说服别人，这个东西用在生产环境中就不会出错？当一切原本运行还算良好的东西，突然被这样一个东西去替换，自然是会有很多人会有反对的声音，即便我当时是一个 VP of engineering 的角色，我也不能轻易的做这样一个结论，说大家必须用 Elixir 来写后端，就是因为我觉得他很有前途，因为我觉得我很喜欢他对吧。无论你的职位再高，除非这个公司就是你自己一手打造的，你有绝对的权威，或者说你从 0 开始的，你直接拍脑门就拍了这么一个方案。不是这样的情况下怎么办？我觉得可以从一个很小的入口去，找它适用的场景，比如说从 Elixir 的角度来讲，我当时找的入口就是做的 policy engine，具体是怎么实现的，这就涉及深入的技术话题，大家可以去看我的相关的文章，但是当时我主要想尝试的就是它的性能能不能带来指数级的增长。往往一个新的尝试都是从一个 POC 开始，就所谓的 proof of concept，你去写一点东西去看一看它相对于已有的东西有一个什么样的提升，我们原来的 policy engine也是我自己优化过的，用的 NodeJS + Jason。Jason 是一个解析器，我之前用它处理复杂的policy的运算，每次响应是毫秒级的，那么我就在想那我在我如果用了 Elixir 有没有可能把它提升一个量级，后来的结果是大大出乎我的意料，就是它提升的不是一个量级，是两到三个量级，从毫秒级提升到了微秒级。所以这种提升就非常的可观，当你能把你的某一个服务，它的服务的一个非常频繁使用的功能提升 100 倍，1000 倍的时候，带来的收益是无与伦比的，那就意味着到用用户侧你的 API 的性能一下子变得特别的好，这个是后来我们用了新的 policy engine 之后，我们原来首页的加载速度从十秒变成了一两秒钟，这就是一个非常大的飞跃。所以如果说你想引入一个新的，技术技术能带来一个甚至几个量级的提升的时候，那么想要把它推广出去的障碍就会小很多了，所以这是一种方式，就是你怎么样把你所学的东西去应用到你的公司里面。

当先从一个小的点，做了一个很重要的替代。你要做 benchmark，benchmark 之后你把结果拿出来对比，这个数字永远是比任何描述都容易去打动人，因为一个比如说20 微秒，一个20毫秒，那么这个差距谁都能看得出来，这就是你最好的武器去让你把你想用的技术去应用过去，但是这样的机会往往是可遇不可求的，能找到这样的机会是最好的，它需要很多的思考和实践。

如果找不到这样在工作场景里应用的机会的话，退而求其次就是找自己的 pet project 里使用的机会。在应用的过程中，你如果能把它沉淀下来，输出成文字，哪怕输出成给自己私人访问的文字，也很好。这还是刚才谈到的指针的概念，就是你找一个指针，把指针指向这段知识。之后当你的知识进入到大脑的遗忘区的时候，你靠着指针还能把它拽回来。很多时候我还会回过头去看我自己公众号的文章，有些有些想法，有些东西我依稀记得我好像写过，我好像就是做过，但是我不记得我当时的这些方法，我用了哪些工具，这个时候我就可以在我的文章里面做一下搜索，就可以很快定位到我之前写的文章，从而又回忆起使用场景。

Q15：大公司很难引入新技术，元芳，你怎么看？

A：我觉得最终还是任何公司最终还是看 ，现在有一个投资，我们去决策要不要做这笔投资。那么要做到什么程度，完全看它能带来多少回报。如果这个回报仅仅是对开发者有意义的一组数字的话（比如 performance benchmark），可能还不足以打动除了技术技术层级之外的人，我们可以进一步的把这个东西转化成对用户体验的影响：它对用户的收益是什么，能带来什么样的 UA 的提升？再进一步，能不能把它转化成对收入的影响，这个就是非常厉害的武器了，比如说我们最近做的某些功能，影响了很多收入或者是节省开支方面的这个东西，如果技术最终只是报一个性能优化的报告，可能高层甚至都不会把它正眼去看，但是如果你说ok我做了某某东西，一年给公司省下来了五百万，这个东西绝对是能上到 BU 老大，甚至CEO 的法眼。因为平日里面不是有那么多机会，给你省这么多钱的。这就是这就是我觉得在公司里面，你做事情可以拥有的高光的时刻，这种高光的时刻是很难得的，我觉得有这样的机会就去抓住它，哪怕最后的结果是公司的安全团队和基础设施团队评估了半天之后，说对不起，这个东西我们因为 xyz 的原因，还是不能去去使用它，那也ok，至少你有了这么一个这样的体验，你拥有了新的影响力。

Q16：周围的人都在搬砖，自己不想，如何影响他们？

A：如果你是一个工程师，你想去影响团队的文化，想让这个团队有更多的对各种，知识各种东西的兴趣的话，我觉得可能凭一己之力会比较困难，尤其你不在一个管理的岗位上面。但是还是有很多方式的，比如说当你进入到一家公司，一个团队的时候，你能给团队带来一些什么呢？如果你自己是一个喜欢思考的人，但是周围的人都是搬砖的，我觉得你第一步可以做的事情是：你可以倡导在团队内部做一些分享的活动，很可能一开始做分享的人只有你，你可以把你自己学到的东西，把你思考的东西分享给大家，把这个东西形成一个团队的习惯，慢慢的这种方法就会去影响到一些人，就会帮助他们去做出改变。在这种缓慢的潜移默化下，团队文化可能会稍微去变一点。

我在 2005 年加入 Juniper 的时候，也是一个毛头小子，毕业才两年。我在团队中没有什么话语权，但是我这个人相对来讲喜欢分享，所以我会时不时地在我自己的团队里面，我我跟我老板 1:1 的时候会跟他提这种团队内部举行这种分享会，比如说在周会上面，我们可以花个20-30分钟，来讲一个有意思的技术话题。如果他愿意的话，我甚至可以帮着来从团队里面去收集技术话题，这个时候往往你在承担一部分 leadership 的角色，对吧。虽然干的是一个很不起眼的小事，但这个小事确实让你离 Leader 更进一步了，一旦你把这件事情做成一个很有规律性的东西，那么对你的团队人来说，它是一个有收益的事情，对你的老板来讲更是一个非常有收益的东西，因为这是团队的亮点。尤其这种亮点是日积月累之后，非常可观的亮点，比如说如果说我们一周分享一次的话，一年就是 52 次，52次，你把这个东西可视化了之后，再进一步为每一个分享打上标签，生成分类的按季度对比的柱状图。老板拿着这个东西跟上面的人去讲，这个就非常非常有说服力。

增进团队中的这种分享的氛围，是解决大家把工作当成搬砖的第一步，接下来就是我们在平时的工作中，怎么样让这个工作本身更多的把它从单纯的写代码的搬砖往更高的层级去拔，这就需要很多你对技术的领悟和技术的认识了，比如说在代码的 repo 中，里面有一些架构上面的问题，我们是不是可以专门就是开一个主题去研究架构的更迭，怎么样让让这个架构变得更好，变得更加清晰流畅。如果产品的 unit test 做的非常不完善，那么是不是可以开一个话题，大家去讨论一下怎么样把 unit test能做得更好，想办法用你的个人的能力和影响力去说服管理者，再通过管理者自上而下的把这些话题慢慢的去展开，去优化。我觉得这是一些在工作中避免，大家逐渐形成一个搬砖文化的一些我的想法。

Q17：如何定义搬砖？如何形成反搬砖的文化？

A：搬砖与否，因为其实我觉得很多公司的，程序员都会有这样的感慨，就是我的工作好像就是在搬砖，我的工作好像就是在被动处理产品经理的想法，他们不管最终这个产品本身会给技术带来多少的技术债，都要求必须要在规定的时间，以规定的方式来完成，这就会让大家产生一种搬砖的无力感。我觉得这是很多公司在文化上面形成的一种氛围，很多时候需要靠时间来慢慢去把它改变。

我讲一下对于 Tubi 来讲，我们有一个很重要的工程师文化，就是我们希望我们招的工程师，或者说我们的工程师本身要有极大的热情，想成为一个非常牛逼的工程师。怎么叫牛逼的工程师，我觉得这可能也是我们每一个技术人应该去追寻的方向，

这是第一个对我们所做的事情，不光知其然，还知其所以然。

第二个就是你要对你所做的，领域产品有强烈的主人翁的意识，ownership，就说这个东西好像就像我的孩子一样，我不知道大家有多少有孩子，你对你的孩子付出的努力跟对，别人家的孩子付出的努力，那是完全不是一个概念的。

第三个就是你的方案，你提出来的方案一定是要能够，落地，能够交付的这样一个解决方案，不是天马行空的画一个大的 picture，画一个非常酷的 architect，最后谁落地，反正我就提方案你们来落地，我们不需要这样的人。

第四个就是你要对产品中的槽点要零容忍，你的产品经理提出来的一些不合理的产品的需求，你要能给他打回去，你如果打不回去，你要能让你的经理去打回去。当然你要有充足的理由，充足的数据来说明这个事情不对

第五个就是你对重复的任务和bug是一种零容忍的态度，我们工程师为什么会产生一种搬砖的感觉，除了刚才讲的产品上面你有很多问题，你无力去打破，还有一个在工作中我们可能有太多不停重复的任务，因为产品的需求截止日期太严苛，导致于我们只能着眼于以现在，没办法着眼于未来，没办法把这个东西抽象在一个更高的层次上面去抽象，把它做成某一个service，或者做成一个就是能涵盖包含了这个场景下面一系列场景的解决方案。

对这一点我举一个例子：我刚来 Tubi 的时候，当时我们有一个工具，是一个 feed parser，我们有大量的来自于第三方的电影的源，每家都有自己的 feed 的格式，当时我加入的时候工程师写的代码非常庞杂，每一个 feed 写一个class，我们有几十个上百个 feed，他的 repo 下面就有几十个，上百个这样的 class 来处理。这样的工作是非常重复的机械的，工程师应对起来非常痛苦，别人接手也很痛苦。大部分时候，普通的工程师就像这个例子一样，来一个任务，我就接一个任务把它解决了。一个（我觉得）牛逼的工程师的处理方法应该是这样的：我当时的接手的时候我做了一个中间层，我定义了一个非常简单的语言，它是用Json描述的，你可以把它想象成一个 adapter：从数据源那边取什么样的字段，mapping 到最终想要内部表存储的数据的什么字段，他们之间 mapping 怎么样去处理，怎么做各种各样的转换。当时我定义了这么一个中间的语言，然后为这个语言写了一个 parser，这个语言很容易扩展，需要新的功能的时候，我就在 parser 里添加。之后的事情就很简单了，我把一个需要几万行代码维护的，一大堆 parse 的 class，变成了一个几百行的 parser，再加上一堆 JSON 描述的配置文件：几十个上百个配置文件。配置文件甚至可以交给没有技术背景的人去来写。这个做完之后，新来一个 feed 的话，我自己可能5分钟就能写一个配置文件搞定。这就是着眼于长远的需求，对重复的任务零容忍。

当我们工作中在第一次做这种事情的时候，我们可能会选择比较直接的方法，但当我们第二次做的时候，就应该考虑我是不是该找到一个合理的模型，去解决这个问题本身。还有 Bug。我们在代码中会不可避免的出现 bug， 对于 bug 我们究竟是找一个方法把它绕过去，还是说我们追根刨底去找到 bug背后的源头，想办法去解决它呢？我们应该选择后者。

第六点是：当你成为某个领域的专家之后，你应该还是保持一个非常开放的心态，随时愿意切换你的技术栈和方法论。你不会去抗拒任何不同的思想。比如说我是一个函数式编程的粉丝，我就鄙视一切面向过程编程的所有的方法论；我是一个 react 的开发者，我就对 vue 充满了不屑和鄙视，认为它是初级程序员的专利，是那些理解不了 react 的人才会写的东西。我觉得我们程序员不应该有这样的心态，我们还是要像小王子里面说的那样，像一个小孩子一样，对什么东西都保持天然的好奇心，愿意把自己的那些「星星」都放到天空中，而不是把它包裹起来藏得很深。所以有必要的话你应该愿意去切换技术栈，切换方法论，有更好的方法，你会愿意去尝试，你会愿意去用数据来说服自己和别人：这个东西值得我们去去投入。

最后一点是你要总是能够让你的团队变得更强。你自己强还不够，你怎么样能用你自己的强大，你的影响力，无论是技术的影响力还是其他方面的影响力，让你周围的人变得更强。

这是我们 Tubi 对牛逼工程师的定义，当然大家感兴趣的话，详细的内容可以到我们中国团队的官网http://chinateam.tubi.tv 上面去看。我不是说为了给 Tubi 打广告来讲这么一个东西，是我觉得这种文化是我们一直追求的文化。

为什么很多公司很难追求这样一个文化呢？很多时候工工程师所做的东西，说它是一门艺术，我觉得也不过分。同样一个需求，你有无数种解决方案，什么才是最好的？最怕大家就是陷入到一个老鼠赛跑的陷阱里面，来一个需求，我解决一个需求，来一个需求解决一个需求，最后麻木的机械的，就像我刚才描述的场景来一个 feed，我写几百行代码去，最后一个月下来或者几个月下来，我写了好几万行代码，虽然数量上很有成就感，但其实我做的事情就是一个搬砖的事情，没有任何进步。所以工程师需要足够的时间去内化他所学的东西，去深度地考虑产品，在无数个可能的解决方案中去寻找潜在的最好的方案。

所以这是一个悖论，就是产品的需求，我明天后天下周我就要这么个东西，而很多时候不是你给我一个固定的时间，我就能把这个事情完成的。而且一旦你给了我一个固定的时间，我能采用的方案，大概率是众多的方案中不那么好的，或者说仅仅是为了解决问题而解决问题的方案。在这种时间的压力下，会导致工程师没有安全感，因为我没有时间去充分思考，我没有时间去探索，产品中有无数的bug，我没有时间去处理，我没有时间去追根跑底，我只能去一个的想办法把它绕过它，找一个「快而脏」，而不是一个终极的解决办法去敷衍。所以这需要时间，需要给工程师一个足够足够长的时间去来出来消化这个东西，让工程师足够有足够的权威，能够 push back，说这个东西我觉得不合理，你产品还没想清楚，你想清楚了之后在跟我谈，为什么我说你没想清楚，因为 case1，case2，case3 等等这些东西你没有考虑到，这些场景下我们该怎么样去处理，你没有想，所以这个东西我不能做。这是很多国内的公司还缺乏的一种文化：就是工程师来能够对产品说 NO。因为不能说 NO，所以 996甚至 007 也要把它弄完。这其实是一个是一个很折磨人的过程，这对我们工程师来讲，成长是不利的；长远来讲，短期公司得到的一些利益，长远可能也不见得那么有利。

Q18：如何处理有限的资源和产品质量之间的冲突？

A：这种矛盾我是经常会遇到的，这是不可避免的。大部分的决策我们要去去讨论的，是 why，为什么我们要做这件事情，这件事情做出来之后对我们的好处是什么，很多时候公司的 CEO 也会拍脑门做一些决定，不见得 CEO 做的决定都是对的，有可能其中 40% 能被我们挡掉，但剩下的60%，无论如何是不得不做的，并且它是有一些截止日期的压力，比如说你要为了某个事件，在这个事件之前，我必须要做出来某个产品的 feature，甚至某个产品来应对这个事件，因为我知道这样的时机一旦错过，可能下一个几年才能遇到的东西。这个时候我们如果说商业决策想清楚了，ROI 都算好了，那就是一个调动资源的问题，这个东西我们要评估它的 scope 有多大，有多少资源可以去使用，我们愿意为它付出多少代价，这个代价不光是内部的，还有外部的。如果自己做受限于资源无法做到更加稳定，那么可不可以找付费的供应商去做？

就拿 clubhouse 来讲，这款产品是一个爆款的产品，但是如果你去看 clubhouse 的实现，他的团队主要做的是一个产品如何去增长，这个产品的界面是什么样子，这个产品如何去打造这样一种交互的感觉。它的底层的稍微复杂一点的技术，都托管给了第三方，比如说它的音频是声网的，这是众所周知的，刚才我们也讨论过它的 pubsub 这块用的是 pubnub 这样一个第三方的服务。

所以我觉得是当我们有一些截止日期不得不去满足的时候，我们从工程师从 CTO 或者技术骨干的角度，我们需要去考虑：有些东西我们是不是这个时刻必须要自研？就像clubhouse这样，我的核心的功能是什么，我怎么样去调配我的核心资源去做我的核心功能，把不那么核心的功能，我如果能多花一些钱就能解决的，是不是可以先把它在这个时刻用第三方服务解决？因为所有技术我一起上的话，以我现在的资源就是满足不了这个日程。所以这是一个博弈的过程，你需要跟做商业决策的那些stakeholder，比如说CEO要去博弈这些东西，你可以提出一些技术的解决方案，你说 ok 为了做这么一个东西，我需要用这些第三方服务，这些服务如果用户量级在这个程度下一个月的cost是多少。我把这个东西列出来，如果 CEO 不同意，那么我们需要这么多资源，并且我没办法保证能在日程截止之前我能完成这样的东西。这就是一个博弈的过程，需要讨价还价。不是说什么东西，别人说 ok 我就要做，我就让我手下的这兄弟们拼命地加班，没日没夜的去做这个东西。这样子长久不了，可能还会带来很多的技术债。

Q19：团队做大，人才密度是肯定下降的，不能要求人人都有主人翁的心，能不能用精细的流程来避免搬砖？

A：我觉得是很好的想法，我觉得讨论就是大家和而不同，我赞同你里面的很多观点，也不赞同里面的一些观点，比如说我赞同人才密度降低这件事情，就是当你公司做大人才密度肯定，是以指数级下降，很难去避免。怎么样去尽量让下降的速度慢一些呢？我觉得一个很好的方式是通过文化来保证，你怎么样通过同一种文化的感召力去召唤那些认同你的文化的人进入到你的公司。这里相关的东西我就不展开来谈了。我稍微不太认同的是过于严谨的规则。每个公司都有一堆的规章制度，有一堆的流程，这无可厚非。

我个人觉得流程流程应该是能被自动化的东西，它不需要你去学习和遵循，工具本身就帮助你准守流程了。比如说当你的代码提交之后，有一堆的 pre commit check，要去check你的代码风格对不对，你是不是过了静态检查，是不是过了单元测试，所有这些都通过后才会允许你提交代码。你 push 上去的时候会有一堆的 github action 去执行，去从各个维度去看你这个代码，是不是符合足够质量的，是不是破坏了现有的 code coverage 等等。这些东西不应该是写成文字去，让每个工程师去遵守的，而是就在你的工具链里，在你的公司的日常运作的过程中，自然而然地去使用规则和流程约束每个工程师的行为。而且越好的团队你会发现自动化的流程越多，就像我们写代码一样，框架是干什么的，框架就是一堆东西来限制开发者的行为，让我们有所为有所不为。为什么我们要做信息隐藏，为什么我们要去做各种各样的解耦，为什么我们要去使用各种各样的设计模式，这些其实都是流程，这些流程都是刻在我们平时开发者骨子里的流程。我觉得这些自然而然发生的流程，是最好的流程。

从另外一个角度来讲，我觉得真正的人才，如果真的把程序员看做艺术家的话，我们很难用规则去来框定它，就像截止日期件事情，如果说你毕加索在 10 天之内画出来某幅指定要求的画，那么毕加索可能画出来的，就跟我们普通的一个画师画出来的是一样的东西。梭罗在瓦尔登湖里面，讲过一句话，我特别喜欢，他说不：能维持一只兔子生活的田野一定是贫瘠无比的，我觉得好的公司它就是好的公司，不好的公司它就是不好的公司，很多公司大了之后，它可能只是比小的时候没有那么，好而已，但它依旧是好的公司，好的公司很多公司它很小的时候，就跟上可能不是一个好的公司，它大了之后也一定不会是一个好的公司。

在搬砖的问题上扯远一些。对于个人来讲，我们工作生活中肯定会遇到各种各样的困难，遇到各种各样的沟沟坎坎，日子就是问题解决问题来过的。但是我自己的一个亲身体验是，当你真心想要去做成一件事情的时候，真的是整个宇宙都会联合起来帮你。我在我之前的公众号文章里面一个叫《缘分天注定？》的文章里面也，提到了我我为了申请 O1 签证的时候，就是得到了各种各样的帮助，以及我过去的种种经历为我当时提供的助力，就说很多事情是当你真正想去做，如果说你想打破现在老鼠赛跑的这种生活，你想打破天天搬砖的生活，如果说你尝试了，你没办法影响到你周围的人，你没办法让周围的文化变得更好，你自己又是一个不甘寂寞想做出点什么事业的人，你不想只是解决你自己的衣食住行，你还有更高层次的需求，那么这个时候你有很多的解决方案。你会发现你在去执行这些方案的时候，你突然之间会有很多的助力，比如说你可以换一家公司，比如说你可以想清楚之后你可以，自己创业，比如说你可以去有一个间隔年，你可以去尝试不同的东西，你可以去读个书，你去见识一些不同的人等等。

Q20：feed parser 那样的改动就不能做自动化吧？如何更好地做流程自动化？

A：这个是代码重构，确实不能自动化，也很难用流程来约束它，只能期待 code review 来抓到它。而很多流程是可以自动化的。我觉得好的自动化的流程，它还能像 Rust 编译器一样，很多编译器告诉你代码错了，错在哪，但 Rust 编译器还会告诉你，你可能需要做哪些事情，能让代码通过编译，我觉得这就是一个非常理想的场景，如果我们的流程都是这样子，就很完美。

当然我们现在的工具没有达到这样一个理想的场景，但是我们可以从这样的产品上面，来学到怎么样让流程对大家平日工作的侵害最小。我不需要去读一个100多页的新员工入门手册，就可以写下我的第一行代码，提交我的第一个 pull request，让他部署到生产环境。这个过程对于一个新员工来讲越顺畅，对于任何一个员工来讲越顺畅，那就说明你的流程自动化的越好，如果说在这个过程中我需要停下来，等着做什么工作，效率一定会下降。

我再讲一个我们团队刚刚做的一个自动化的东西：我们 web 团队有自己的一些流程，比如说一个pull request，你通过了 review，通过了 CI 之后，你还需要必须跟 master 要保持同步，才能合并。当我们定义了这样一个规则之后，执行起来的代价是挺高的，因为一个 repo 可能有十几，甚至几十个工程师在上面上面工作，一天有无数的 PR 被不断的合并，当我自己有一个通过了 CI 和 reivew 的 PR，我还得去和 master 同步一下，一旦同步意味着又继续运行一遍 CI，可能在这个过程中别人又合并了，回头我还得再继续同步，这个流程拖累了所有人的效率，因为大家工作之余还需要盯着 CI的状态。于是我们就写了一个 github action，把这个东西变成一个自动执行的流程。工程师提完一个 PR 之后，只要过了 review，我就可以不用管它了，可能在未来的一个小时它被自动合并，可能在未来的三个小时它被自动合并，而我不需要不断的去检查 CI 的状态，看是否可以合并了。这在工程师身上省下来的停等的时间就节省的资源，是花额外的钱我们可以接受的。

我真的没有想到我自己能说这么多话，因为我自己个人来讲不是一个很 social 的人，我宁可趴在电脑旁边去去写很多的代码，或者去看 YouTube 的视频，也很少愿意在这么样去聊天。最后如果大家没有什么其他问题，我稍微总结两句，我对我的文字的一个期许。

我希望未来大家看到程序人生的文章的时候，能够有两两个收获：第一个就是能够体会到写代码和思考问题的这样一种快乐，我希望我把我的这种快乐也带给我的读者们；第二个是我希望通过我的文字可以激发大家的一个进一步的思考，就像罗翔老师 —— 我特别粉罗翔老师，如果大家在座的也不知道罗老师的，我非常建议你去b站关注一下 —— 他在b站 11 周年演讲的时候，说了一句话对我的感触特别的深。他说 真正的知识要影响每一个爱思考的心灵。我希望我的程序人生能够带来这样的影响，这也是我自己践行 pay it forward的一个东西。谢谢大家，有机会我们下次再聊。