你打算如何渡过自己的职业生涯？毕竟工作是公司给的，但职业生涯是你自己。
1. 前言
22年的年中，因为多年来在传统软件行业里的职业生涯经历，有感而发我开篇了名为走出软件作坊这个专栏（这个名字源于对我影响颇深的同名书名）。
在这个专栏的开篇三文中，我分别介绍了我所见证和理解的传统软件公司的发展现状，其对于技术人员的要求，以及身处其中的技术人员的破局之路。
过去的一年多里，也是继续见证了不少职场操作，有了不少琐碎的念头。有感于相较于这些念头，过往在走出软件作坊中所列出的对于高级人员的标准要求过于"宽泛"。
本文尝试给出一些稍微具体的标准和要求。这些标准和要求彼此独立，没有明显的先后顺序，感兴趣的读者可以自行选摘。
2. 叠甲
碎碎念了这么多年，我也清醒地认知到这篇文章的结局肯定也是石沉大海，但为了避免不慎被身边熟悉的人所看到，所以这里有必要做一些前置性的免责声明。
- 以下这些标准和要求中对于人的要求都是相当高的了，而且这些技能和思维都是需要后天进行有意识地刻意练习才能入门并且在之后的职业生涯中持续磨练才能熟悉掌握的，这需要当事人有清晰的认知以及极强的自律才能做到精进。如果发现自己做不到，这很正常；毕竟"just a job"，正如上面引言部分所言，只要你想清楚了这就是你想要渡过职业生涯的方式，那就没有任何问题，无需产生任何不良情绪。
- “你自己做到了吗”。可能有些朋友第一反应会是这个，毕竟"凭什么你在这居高临下巴巴这么些高大上的玩意，你自己又做到了吗？就搁这一副教育人的样子"。关于这一点，首先这些只是我对自己职业生涯的反思，并且与其他朋友的交流发现也都存在类似的感受；其次写下这些也不为什么凸显自己优秀，其实记录这些的最主要原因是从小脑子不好，容量不够大，但又特别小气——觉得自己思考了这么久的东西，不能保存下来实在可惜了。
- “我都没做到，但我在公司就是被认定为高级甚至资深了”。这个其实也没毛病，就像我在《走出软件作坊》三部曲中所说的 —— 对于传统软件公司而言，它对技术要求不高，一年经验当十年也绝对没问题；加上"水多了加面，面多了加水"形成的管理流程，在这类公司里你只要呆得时间足够长，你就是满足它的要求的。这类公司只要商务不出现大问题，一直待下去是一个比较好的选择。
- 为了保命，最后我再强调一遍：对于在职场游历多年的人，他的硬实力一定是满足要求的 —— 首先工作内容是分层次的，做不到大厂的P7，最基础的CRUD总是会的吧；其次最近不是流行一句话"世界就是个草台班子"，本身大部分事情的技术含量也就是半个月上手操作的水平。这里摘抄一段最近从知乎上看到的评论：
公司并不需要编程水平太高的程序员。因为干的活就是个毛坯房，垒的就是鸡窝。除非大公司里搞底层技术的需要高手之外。某市技术职业学院的计算机系大专生都能胜任现在大部分程序员岗位。
3. 基本素养
3.1 快速适应环境
"唯一不变的就是变化本身"。 这句被奉为圭旨的名言相信大部分人都或多或少听说过。
这句话适用于人类社会的方方面面，咱们每个人的职业生涯也自然身处其中。不论你是运气爆棚陪着公司从初创一路走向辉煌，还是为了追求个人发展在不同的公司之间来回跳槽，你都需要面对时刻发生的变化 —— "在不同的公司之间来回跳槽"自不必说，即使是在同一家公司，随着公司的发展，领导势必会不断将其推到更高的位置直到你无法胜任，这首先是物尽其用的基本诉求，同时也是对于你这个日益增长的成本的对等要求，而这些也势必会要求你不断面对新出现的状态。
当变化发生时，能够快速认清现实，梳理总结事物运行的客观规律，适应新角色，满足岗位要求就成为区分职业素养高低的重要标准：
- "快速适应变化"要求你能够"杜绝砸锅思维"，先理解环境，再改造环境。新环境下各种让你觉得不科学，非常业余的解决方案一定是有其产生的原因，这些原因可能听起来觉得匪夷所思，很幼稚；但是如果想要以更为高效的方式改造这个现状，你要做的第一件事就是去全面了解这种现状产生的原因，理解当初为什么这么做；而不是一上来就"这系统就是垃圾，老子要全部推了重来才行"，要求现状按照你的意愿去变化，让环境适应你。"动了两下发现环境无动于衷，于是开始摆烂"这种虽然也是属于适应环境，但很明显并不能算积极状态。
- "快速适应变化"要求你能够理解“现实的复杂性”，很少有人是憋着坏去做的。软件开发是合作性的工作，不是对抗性的。
- "快速适应变化"要求你先改变自己适应环境，然后改造环境适应自己。
3.2 排查问题的能力
在 传统软件行业中技术团队的发展(个人破局篇) - 简书 (jianshu.com)中，我就谈到了"技术能力"是我们这类以技术作为安身立命之本的职场人士的基石，之后的进一步发展都是以此为基础的。
而所谓"技术能力"的体现，很大一部分就是在解决问题过程中体现的。这里我们仅以技术问题为例，简要介绍下对于相关要求的个人理解。
- 快速排查问题需要你得有一个庞杂的知识基础。如此才能在面对问题时候快速排除掉大部分可能性，将范围缩小到有限的几个可能点上。
- 快速排查问题需要的其实是一个综合性的能力，比如与他人沟通以了解问题更多的上下文；在专业经验和通识经验的支撑下设计递进式地问题验证方案等等。
- 快速排查已发生问题的能力依然也只能算是基础，主动发现问题，察觉问题，提出问题，以及持续追踪问题并且落地解决的能力比前者更重要得多。后者才是将中级和高级区分开的关键。
3.3 文档能力（包括编写和阅读的能力）
据我观察，很多技术人员别说写文档，阅读文档的能力都有些岌岌可危了。
- 文档的作用之一是记录过程，避免过程黑盒。你最大的价值不在于你知道什么，而在于你知道这些的过程。尤其对于这个注定要长期维护的软件产品，不写文档的成员应该第一时间干掉。
- 文档保证了问题的持续跟踪，持续优化。相较于把某个问题的解决优化寄托在某一个人身上所带来的不稳定性，文档让相关的知识公开化，共享化，以及由此带来的持续性。一个人可能走得快，但对于一个需要长期维护的软件产品，我们更需要走得远。
- 这个文档已经有其他人写了，为什么我还需要写？ 关于这个问题，文档分内部文档和外部文档，公司文档和团队文档，不同的视角下，文档所表述的重点不一样，只要还存在问题，就说文档还有优化的空间。
3.4 明白系统监控的重要性
这里我刻意使用了"明白"，而不是"理解"来强调对于系统监控的重视，以表达现实中很多所谓的高级甚至资深人员对于监控一无所知的状况的无奈。
"没有监控的系统运行，犹如闭眼开车上高速"。在传统软件公司里很多软件项目都是三个月甚至一个月出一个，客户要求也是能够跑起来就行，业务中断也是可以接受的，在这种氛围下，相关的研发人员完全没有动力，自然没有意识去进行相关的系统稳定性研究。
但是对于从事软件产品的高级研发，你却不能按照这样的项目软件进行自我要求，你可以限于实际不去做，但不应该没有相应的思考，沉淀和推进。（这里举个笔者自身的例子，我们的团队至今没有将监控常态化，但过去几年里我已经先后尝试了多种本地化方案，包括但不限于基于大众点评CAT的CAT-LOCAL项目，基于Skywalking的本地化方案，Plumelog-一个简单易用的java日志系统，Loki等等应对不同场景的多种方案。实现了部分产品的监控常态化，以及在需要时提供多种快速接入或者事后补充的监控接入方案）
- 首先你要熟练掌握系统现有监控能力。解决问题的第一步是理解问题，而监控正是你理解问题的关键手段；相较于额外引入监控手段，熟练掌握系统中已存在的监控手段能够有效缩短问题定位的前置时间。
- 圈内主流监控技术栈的熟练掌握。典型如Java领域的arthas等。
- 博览群书，丰富相关理论知识。 这是实现持续推进优化的基础。
3.5 渐进式升级， 随时可验证
这一小节的标题要求我们在进行软件产品优化维护或业务功能需求实现过程中，能够将实现的过程进度以上层无感知，可视化地方式呈现给领导和团队其他成员，让升级或实现过程中系统的稳定性不出现明显的波动。
这个素养其实就是要求相关人员对于所从事的任务能够进行刻意地任务分解，确保分解出来的子项之间彼此独立，能够分别进行验证，并且通过逐步验证完成的子项来保证本次完成的优化和业务功能能够实现尽快的验收。—— 而不是研发宣称已经完成了，然后测试接入之后每走一步都是一道坎；研发一周，之后测试阶段得花一个月才能将功能磨合稳定来实现发布。
- 这项能力依然是需要后天刻意练习才能熟练运用的，而对于很多人来说这个过程太辛苦了，它们更倾向于一股脑扎进问题里，以最终的交付为要求，期间的检查点是什么东西？你总盯着我干什么，最后阶段我能够交差不就完了吗？
- 对于那种比较耗时的功能（比如一个月，这对于现在两周甚至一周一个迭代周期的敏捷流程可说是相当长了），如果你在一周的时间之后无法给出外部可直观感受到的相应测试（避免有人抬杠，这里我解释下测试不仅仅是有用户的验收测试，对已经实现的功能点的单元测试也算是测试的一种），那么只能说明两种可能性：这项优化不合适现在开始；或者直白地说：你这任务拆解是怎么做的，表现得跟个初级研发似乎的？
- 其实关于这一条，其实前辈们已经在各自的著作里强调了无数次了 —— 小步快跑，每日提交代码，频繁测试，让系统演进过程尽量平缓，不要出现剧烈波动等等。可惜不说能够有意识地去了解这些的有多少，了解之后的自律练习更是劝退了本以所剩不多的大部分人。
- 关于"随时可验证"，这里有一条前辈们的经验总结：精力中始终得有十分之一是花费在效果展示上的，这笔投入会持续让你收获丰厚的回报，将是你最明智的投资之一。
3.6 解决问题优先
关于这一条，与上面的"排查问题的能力"存在着非常高的重合度，这里单独列出来主要是为了强调这个"优先"，技术人员常见的一个毛病是不分场合地刨根问底 —— 这边业务急迫得都火烧眉毛了，他还就在纠结系统按理来说不应该出现这种现象？
记住，第一时间修复问题！技术上的疑问让我们在修复问题之后再进行复盘。如果担心现场丢失，那你应该锻炼的是快速保存现场的能力，而不是要求客户按照你的进度来。（注：这里的客户不仅仅是最终为产品付钱的甲方，软件产品的用户都是这里客户概念的范围，比如测试就是软件产品的第一波客户）
要实现"第一时间修复问题"，这要求我们在日常的系统开发和维护过程中，要时刻绷住一根弦：
- 根据历史经验，持续提供一些让系统快速恢复正常状态的内部使用接口。这里最典型的就是系统同步状态不一致，通过提供内部强制同步手段，让系统快速恢复正常，
- 根据历史经验，持续给系统增加一些快速检测和验证接口，确保发生过的问题能够快速得到验证，然后在此基础上持续优化相应的解决方案。
3.7 对结果负责的能力
高级研发最基本的素养之一就是对于所安排的任务自己进行计划，自己细排日期表，自己推进落地。
对于整个需求的结果负责。编码完成甚至都不是"结束的开始"，而只是"开始的结束"；测试认可，最终用户认可，这才能算是拿到了结果。 宣称已经完成，客户始终无法顺畅使用整个功能，等着别人一步步推进落地，这是初级研发的表现。
- 像其他的子项要求一样，这一条其实也是主动性的表现。
- 好的样例见过少数几个，但常规表现通常是拿测试人员当小工用 —— 只负责敲代码提交，测试工作让测试人员来，表现上就是测试通过率个位数，阻塞率惨不忍睹。另外一个常见的就是最终逼着负责人亲自下场，两个人做一件事情 —— 负责人在后面亦步亦趋地告诉他下一步应该怎么做，搞得不亦乐乎。
3.8 研发效能的意识
这依然是一个认知上的要求。
关于这一点我在过往专门写过一篇
传统软件行业技术团队现状之研发效能误区 - 简书 (jianshu.com)来进行分析。正如这篇文章里强调的：
很多人，包括领导认为”问题太多，解决太慢“是人手不足导致的，但我的观点是：不应该是效率太低了吗?
一个问题解决三天和一个问题半小时甚至几分钟内解决，这能一样？甚至这其中还参杂有不少人的“解决那么快干什么？"，真是人都给气笑了。
软件研发的整个流程环节里，有一个慢，那整个环节都会跟着慢下来；而对于研发来说最显著的打包(CI)，部署(CD)，问题排错(监控)，这三个里有一个有问题，那就别说什么效能了。（这里的有问题不仅仅是单次耗时长，还包括发生频率低，尤其是对于前两者的CI/CD，大厂一天几万次打底，反而小厂一天一次都费劲，见了鬼了）。
但往往有意思的，如果一个团队要么这三都没问题，要么就是这三都有问题，很少会出现什么中间态。这也契合上面所说的"这是一个意识问题"，因为只要意识到位了，这种业内研究了几十年，方案一大堆的事情，没道理会因为技术问题而造成困境。
注：如上面所说的"好的例子见得不多"，常见例子往往是各种堪称奇葩的论调："一天就打包一次，打包那么快干什么"，"一天就部署一次，今天完成的功能得到明天才能得到验证"等等。
3.9 数据驱动意识 / 量化思维
这个也属于是被前辈或者领导所反复要求的技能。
这种意识或思维要求客观数据说话，杜绝定性描述。典型如评估人员效能时，应该以诸如禅道这样的客观数据来进行指标判定评估。
但可惜在实际的工作过程中，常见表现是跟着感觉走 —— 我感觉应该没有问题了，感觉应该是改完了等等。 最近发生的一个典型例子是在面试一个资深技术管理时，我问他是如何考核下面这帮研发人员，确保他们的工作进度和质量的，对方给出的回答是根据他们过往的表现进行针对性的抽查，主打一个信任。
3.10 工具思维
这一基本素养要求我们在遇到问题时，给出的解决方案以提供工具为主。
如我在关于”问题解决方案的递进"基本共识 - 简书 (jianshu.com)中所表达的，针对问题的四类解决方案 ——面对面沟通，文档化，工具化，界面化；作为拥有先天优势的程序员来说，我们应该在审时度势的基础上，优先选择工具的方式来进行解决：
- 解决方案做成工具有助于沉淀，有助于持续迭代，有助实现知识的团队共享。
- 解决方案做成工具有助于降低与外界的沟通成本，提升效能，进而提升软件产品的用户体验。
3.11 对"完成"的定义
"编码工作量只占整个研发流程工作量的1/6"，这是源自《人月神话》里的白纸黑字。
关于这一点，其实也是我一直在吐槽的 —— 不少研发或者是认知不足，或者根本就是惰性使然，每次汇报进度时刻意将编码完成当作一个重要的节点进行汇报，往往是编码用去两天，之后的功能测试来回磨两周才堪堪稳定。
之所谓如此强调对于"完成"的定义，是因为如果你认为编码完成就是工作的结束，那么势必造成对功能最终上线的不重视，进而导致整个功能交付的拖延，而这对于软件产品研发的根本目标 —— 满足客户的期望是背道而驰的。
3.12 持续优化思维
持续优化思维要求我们对于所从事的工作始终绷着一根弦 —— 通过实际工作过程中遇到的问题，以及不断地系统全局审视，来持续性地发现系统中的待优化点，然后通过全局分析，对这些待优化点进行排期落地。
如前面地很多素养要求一样，这个思维也是一项反人性地要求，需要相关人员进行长期地自我训练才能形成习惯。而且这一特性和其他素养之间关系紧密：
- 持续优化思维要求我们保持对于问题的长期跟踪，这基本就要求有文档意识，能够持续性地记录问题进展。
- 持续优化思维基本也就意味着工作没有"完成"地概念，优化无上限。
- 正是持续优化思维，才能让我们更倾向于选择使用工具来沉淀解决方案，而不是偷懒的文档化，甚至口述方式。
- 持续优化思维应用于个人开发过程的方方面面，例如功能实现完毕并非终结，相应的测试用例编写，代码重构等等"吃完饭洗碗"的操作都是持续优化思维的具体体现。这一点尤其在你做的是长期维护的软件产品时非常重要。
3.13 有意识地训练自己
在日常的工作中，经常能够看到的一个现象就是所谓的六十分万岁，只要表面上过得去，那怎么顺手怎么来，怎么能够尽快交差怎么来。
这种思维其实在做三个月周期时的项目类软件时问题不大，因为繁重的项目deadline压力会推着你持续往前走，而且正如上面所说相关用户要求并不高 —— 业务中断，系统重启这些都不是事；但如果你所参与的是一个产品类软件，或者你对自己的职业生涯还有些许期待，那么你就不应该这么放纵自己：
- 对于传统软件研发公司的开发人员来说，本身起点就存在弱势了，我们更应该在平时每步行动中有意识地进行自我训练，主动带上镣铐跳舞，这样才能最大限度地端来自己的能力。如《游戏改变世界》读后感 - 简书 (jianshu.com)里所说的"限制并不会约束你的发展，反而会激发你的创造力，活跃你的思维能力"，而且只有在充满限制的情况下实现目标，那当条件宽松时，你的表现将更加瞩目。
- 日常工作中，领导不可能事无巨细地要求到每一步操作的标准，而且真做到了这样你又得开始抱怨没有自由；加上任何问题肯定不止一种解决方案，那么如同那句鸡汤一样 ——两条人生道路你不知道选哪个的时候，选择比较难的那一条。你可以在确保按时完成的前提下，选择那条对系统全局更佳，对个人挑战更大的方案去实施。
- 最后，工作要求之外还有自我要求。我们不应该将外部客户标准或者领导标准作为唯一的要求，除此之外还应该有团队内部标准，还有你的个人标准：
3.1 开放标准： 开放给外部使用时的标准
3.2 项目/产品标准： 项目组和产品组内部共识的标准
3.3 小组标准：比如研发小组内部的标准
3.4 个人标准： 个人对此的标准
以上这些标准应该是逐级更加严格的，只有如此你的职业生涯才有希望稳步向前，向上发展。
"求上得中，求中得下，求下无所得"，这句出自《论语》的名言警句绝大部分国人都不陌生，但正如"听了这么多大道理，依然过不好这一生"一样，做到的又有多少？
4. 最后
以上这些所介绍的素养，彼此之间其实有着相当强的关联性，属于是你如果想要修炼好其中一门技艺，其他的自然会跟上，也必须得跟上。
这些素养看着不少，但归根到底，就是"主动性，对结果负责，沉淀思维"这三者的衍生。
如社会上一再渲染的35危机，职业生涯里，我们需要主动体现体现价值，时刻保持有忧患意识：
- 尽量把选择权拿到自己手上（不要把所谓的悲壮跳槽也当作是一种选择的话）；
- 不要让自己在团队里可有可无；
- 不要靠拼苦劳来博取同情来达到目的，这样并不符合将命运攥在自己手上的初心。
当然如果你想明白了自己的职业生涯发展，并且愿意为此承担相应得结果，那么我觉得这也是成功的 —— 毕竟除非迫不得已，谁愿意把自己锤炼得遍体鳞伤。
5. 相关
- 传统软件行业中技术团队的发展(团队破局篇) - 简书 (jianshu.com)
- 传统软件行业中技术团队的发展(个人破局篇) - 简书 (jianshu.com)
- 《人月神话》
- 编程之道：饭后洗碗 --- 虽然道理都懂，但是你可能还是写不好代码。因为要做到这些，除了加强学习（懂git rebase/squash，懂如何封装和抽象，懂如何编写测试），还需要非常强的自律。
- 我的日常工作内容 - 简书 (jianshu.com)
