戒除工作的急躁
觉察、分析、改进。
觉察
觉察是改进的先导步骤。
当心情急躁时，停下来思考是什么触发了急躁。
有意识地觉察内心的情绪、欲念和活动，是一种心理训练。觉察，本身就是一种治疗。
急躁，一定是遇到了冲突矛盾。要么是时间少与工作量大的冲突，要么是经验能力不足与问题复杂的冲突，要么是沟通意见难以共识的冲突。
冲突根源，通常来自于时间有限、资源有限、缺乏共识、驾驭力不足。
- 时间有限。很多问题都源于时间有限。就万物生长而言，时间是变化的刻尺。而在人类社会里，时间更多是一种约定。期限本质上是人与人之间的约定，是沟通。既然是沟通，则必有沟通的余地（除非是恶意为难）。沟通最重要的是学会换位思考，从对方的角度去思考，通常可以让对方感受到被理解，缓解紧张关系。
- 资源有限。如果一件事情需要涉及较大的范围或资金，或者需要动员很多人参与，或者需要较长时间的投入，则需要请求领导给予支持。如果领导不予支持，那就只能靠个人魅力了。
- 缺乏共识。来自不同背景、有不同经历和经验的人是容易产生观念冲突和分歧的。盲人摸象的寓言最能揭示这个问题。每个盲人都只是接触到了事情的一个侧面。首先要弄清楚彼此的观点分歧，利益立场，是否有不可调和的地方。如果没有不可调和的地方，则可以寻找一个大家都能接受的平衡点，将彼此的想法都融入到这个平衡点；如果有不可调和的地方，则只能通过谈判来解决，靠己方实力来保证利益了。
- 驾驭力不足。驾驭力不足，有技术方面和非技术方面。技术方面，是不了解相关技术原理，不擅长知识技能；非技术方面，是不谙熟人际沟通的法则。
最重要的是培养耐心细致的素养，然后是提升驾驭力。有了耐心和驾驭力，即使不能解决全部问题，也能在大多数时候保持镇定和耐心。
对策
戒除工作中的急躁，首先要分析出有哪些急躁场景，然后各个击破。把每一个场景的解决作为一个挑战。
以下是我会产生急躁心态的几个场景。
前三个偏向技术相关，后两个偏向沟通相关。如果技术能力暂时无法满足，就转向沟通方向解决。
本质上，一切人间事务的问题，都是沟通问题。技术只是快速解决和避免麻烦的支撑手段。
当遇到环境问题无从下手时
缘由
现代软件工程在追求效率和便捷性的同时，也引入了更高的系统复杂度。比如容器化部署，K8S 编排系统，尽管让部署交付变得更加自动化和安全，同时也引入了更多的层。要让这些层正常工作，有很多“隐性”配置在起作用。当一切正常时，你浑然不觉；而当出现错误时，你一筹莫展。
有时，因为环境配置不当问题，导致出现“不知所云”的报错时，往往不知道从何查起。
对策
- 学习基本的原理，掌握必要的知识基础。虽然整体上系统变得复杂了，但是通常不会遇到很深很难的问题。如果遇到了，那也是一种幸运。
- 问询 AI ，了解可能的原因及相关原理。
- 根据实际线索，逐一排除。
- 找同事帮忙看看。
难点
语境广泛，知识经验欠缺，难以找到合理的切入点。
挑战
培养深入原理解决问题的技术素养。
当遇到疑难 Bug 时
程序员的一生中， Bug 可以说是“亲密伙伴”了，或许比初恋还“亲”。疑难 Bug 就是那种绞尽脑汁也很难想到问题所在的 Bug。它通常是小概率事件，难以复现，稍纵即逝，你只能捕捉到它的背影，却看不到它的真身。另一种情况是，日志打得太少，只能靠猜。
对策
- 开启探案的乐趣。
- 查不出原因时，说明已查到的部分，并说明为何无法往下查的原因，说清楚即可，不必焦灼。
- 给一个可以说过去的理由和改进计划。
- 做好抚慰性沟通，没有什么事情是很难沟通的。
难点
没有日志线索；所涉代码比较深层广泛。
挑战
增强推理能力和敏锐发现线索的能力。
当步步受阻时
缘由
有时，由于“运气”不佳，似乎每一步都会受阻。比如，本来精神满满地做计划的事情，结果前几天运行好好的程序突然不能运行了，得找人先排查解决。打开 IDE，之前好好的代码，导入依赖莫名其妙报错了；使用命令试图解决，报错；再用另一个命令解决报错，又报错。这真是考验人的耐心啊！
再比如，迁移 Java 到 Go 之后，走一步来一个 Nil pointer reference，或者直接终止流程什么信息都不输出，都不知道代码运行到哪里去了。
对策
- 耐心。心性的修炼。克制住，不要锤桌子。
- 学习新的经验，增强新技能的驾驭力。Go 与 Java 的设计哲学有所不同，将旧经验和旧习惯搬到新的领域，会有不适应。比如 Go 的报错，如果有错误不捕获，则会继续往下走；而 Java 报错，即使不捕获也会抛出来。
难点
心性的修炼。
挑战
新技能的驾驭和新经验的获取。
当做法比较麻烦时
缘由
有时，会遇到一些看上去有规律但手动工作量很大的事情。比如，将几十个 Java 对象转为 Go 结构体，或者将工程中所有出现 copier.Copy(dst, src) 的地方都改成 bean_utils.copyBean(src, dst) （src,dst 是可变的）。这些手动改起来很麻烦。另一个场景是界面测试。在不同页面点好几处按钮才能完成一个操作，还要验证多个操作是否符合预期。
对策
- 问询 AI，生成自动化工具来解决。
- 改进方法；思考新的方法。
- 耐心。
难点
找出阻碍因素，找到合适方法。
挑战
微创新。
当感觉时间不足时
缘由
应该是常见的情形了。 项目工期紧张。你也不知道为啥项目工期就这么紧张。也许是为了更快抢占市场制定了截止期限，也许是己方缺乏话语权必须听甲方的安排，也许是，很多原因。人们总是非理性地疯狂往前奔，却从不停下来反思一下。结果只能让一场疫情来按下暂停键。
对策
分情况处理。时间不足，有硬性时间不足和软件时间不足。硬性时间不足，是指有明确期限的时间紧张，如果不能达成，将会有不可承受的巨额损失；软件时间不足，是指如果不能达成，无法获得更好的预期。
对于硬性时间不足，可采取的方案：
- 合评估工作量，做好整体设计，制订合理的开发计划。
- 时间实在不足时，拿出合理依据，沟通获取时间宽限和资源支持。
对于软性时间不足，可采取的方案：
- 调整计划，不要过于苛求自己。
- 放松，体验才是真人生。
难点
时间精力和任务管理。
挑战
增强时间和任务管理能力。
和同事有不同意见时
缘由
来自不同背景、有不同经历和经验的人是容易产生观念冲突和分歧的。比如来自两个大厂的资深工程师，各自有一套比较成熟的做法，适用于不同的场景。两种做法都有一定的道理，谁也没有充分的理由说服对方。
对策
- 仔细思考两者的利弊并记录下来，汲取共同的智慧。
- 寻求第三方裁判。
难点
不固执己见，从利益思维中跳脱出来，学习彼此的智慧，达成共识。
挑战
增强集思广益、换位思考和沟通协作能力。
放松
心理心态的调理也是很重要的。
- 听轻音乐
- 欣赏舞蹈
- 欣赏绘画诗词
