一个闷热的中午，照常与几位同事在连廊吃午饭。跟我当初一起入职的同事提起说，已经两年了。他的感受一如他往常的云淡风轻：生了个娃，家庭上忙了很多，工作上留下的印象不多。而我告诉他，我觉得这两年挺漫长，当前的状态也是“很忙”的状态。这种长和忙其实也代表了过去两年的表象，而背后的一些事情值得细细思考和沉淀。

这个两年离技术更远了一些。很多技术出身的人是抵制甚至是有些许恐惧这种距离的。我也一样。技术同学的成长路径大概分两种：按照底层核心/中间件/业务系统由下至上或者自顶而下发展。每个环节根据个体差异，平均停留3~5年，而最后一个层级可能会停留多年。我属于前者。过程曲折，但是也没有什么可纠结的。而这种离技术的远不是完全放弃技术的积累，而是技术不再是唯一的首要位置。另一方面，在技术成长上需要更加体系的方式构建自己的技术框架。

比如，这两年追过Flutter, 了解了它在哪些场景下适合解决什么样的问题，以及解决效果及局限性是怎样。在很多前端同学还在犹豫是否要学习的时候，我已经基于Flutter上线了一个Demo. 但是继续深入的事情那就需要等待合适的土壤了。

这两年离业务近了很多。做业务的技术同学有个普遍的困惑：业务结果是前提，并且以业务结果评估技术结果，在不公平，但是也没办法。因此很容易掉入业务说啥就做啥的陷阱，最后长出来的系统千疮百孔，岌岌可危。这里有一个明显的误区，业务！=业务owner. 很多时候，技术同学只是解决了业务owner的问题，并没有从更高的层次不断抽象，去发现和解决真正的业务问题。

如何避免成为 CRUD boy？ 这其实是个伪命题。正确的提问姿势是：如何避免成为只是个 CRUD boy? 两个做法可参考，一是使用已有的轮子或者自己造轮子让这种层次的开发大部分自动化，二是把剩下没法自动化的部分交给团队的人员梯队去消化。

业务系统没有技术含量？这个应该是很多职场初期同学都会问的问题。本着先问是不是，再说为什么的原则：业务系统并不是没有技术含量，而是技术价值输出的对象以及兑现的方式发生了变化。底层核心/中间件层面的轮子很容易在输出给上层系统使用的时候体现其价值。这也是很多技术同学非常熟悉和认可的技术产品生产方式. Talk is cheap, show me the code可以认为也是这种价值转换的诠释。这种价值转换最大的参考案例就是github。然而，对于业务系统而言，Talk is valuable, write the code: 理解和抽象业务非常重要，直接决定了代码的价值。更大层面上，你要理解其背后的用户模型和商业模型。

业务系统技术同学的价值体现在：1. 业务域80%通用问题的技术抽象识别；2. 根据抽象识别选择合适的底座或必要时候能打造适合业务状态的轮子；3. 支撑业务是基线，加速业务达成，扩大业务基本面价值是生命线。对于技术同学来说，要时刻思考：抽离掉技术底座和业务后，你的价值是否归零。

但是，并不是所有的业务都能持续下去。小到一个按钮功能，大到整个公司战略。签字画押前，多跟业务同学沟通，以及业务的历史合作方了解。下定决定了，那就接受那些无法改变的事情。但是，有一点很重要，靠谱的同学无论做什么业务会抢手受欢迎。

一直愉快的合作是非常罕见的。大部分合作都是信用积累和消耗的往复过程。对于个人品牌亦如此。所以，我鼓励大家对人对事上都较真一点，该点出的问题就说出来，不想接的招直接打回去。如果你连内心真实的不认可都无法输出，那么你的赞许也毫无意义。

坦率讲，过去两年虽然发生了很多事情，但是还是觉得自己挺幸运的。遗憾留给过去，平和的心态走向未来。