读程序员的README笔记18_职业生涯规划

1. 行为准则

2. 管理者是做什么的

2.1. 与你的管理者构建工作关系将有助于你发展你的职业生涯、减少压力，甚至交付可靠的软件

2.1.1. 必须了解你的管理者需要什么，这样你才能帮助他们

2.2. 管理者们似乎总是在开会，但他们实际上在做什么并不明显

2.3. 工程经理的工作是关于人、产品和流程的

2.4. 管理者们构建团队、指导和培养工程师，并进行人际关系的动态管理，工程经理还计划和协调产品的开发

2.5. 管理者通过与高管的关系和沟通进行向上管理

2.6. 管理者是普通工程师和负责商业决策的高管之间的沟通渠道，向上管理对于获得资源（资金和工程师）以及确保你的团队可以得到认可、赞赏和倾听至关重要

2.7. 管理者通过与其他管理者合作来进行横向管理

2.8. 管理者通过跟踪正在进行的项目的进展来进行管理，设定期望值并给予反馈，明确提出相对优先的事项，雇用员工并在必要时解雇，以及保持团队的士气

3. 沟通、目标与成长

3.1. 一对一面谈

3.1.1. 你的管理者应该每周或每两周与你安排一次一对一面谈

3.1.2. 一对一面谈是你和你的管理者专属的时间，可以用来讨论关键问题、解决大局观上的偏差，并建立富有成效的长期关系

3.1.3. 一对一面谈是一种众所周知的做法，但它们往往被用作工作状态检查或故障排除会议而没有发挥很大作用

3.1.4. 一对一面谈是一种众所周知的做法，但它们往往被用作工作状态检查或故障排除会议而没有发挥很大作用

3.1.5. 如果你的管理者一再取消与你的一对一面谈，你需要和他们谈谈这个问题

3.1.5.1. 他们的工作职责之一是管理他们的团队，而管理的一部分就是对你投入时间

3.1.5.2. 对管理者而言，反复取消一对一面谈可以是一个有价值的信号

3.2. PPP

3.2.1. PPP是一种常用的更新工作状态的格式

3.2.2. 它是为了帮助你的管理者发现问题，找到你需要背景信息的领域，以及提供将你与正确的人联系起来的机会

3.3. OKR

3.3.1. OKR框架是公司定义目标和衡量其是否成功的一种方式

3.3.2. 在OKR框架中，公司、团队和个人都定义了目标（目的），并为每个目标附上衡量标准（关键结果）

3.3.2.1. 每个目标都附有3到5个关键结果，它们是标志着目标达成的具体指标

3.3.2.2. 不要把关键结果变成待办事项清单

3.3.3. OKR通常是按季度设定和评估的

3.3.3.1. 尽量减少OKR的数量，这将使你保持专注

3.3.3.2. 每个季度有1到3个OKR是一个合理的数值

3.3.3.3. 如果超过5个，你就会把自己搞得过于疲惫

3.3.4. 无论采用哪种框架，个人和团队都需要一种方法来设定目标和评估进展

3.3.5. 并非所有的公司都会设定个人目标，有些公司只设定团队、部门或公司层面的OKR

3.4. 绩效考核

3.4.1. 管理者会定期进行正式的绩效考核，通常是每年或每半年一次

3.4.2. 在写自我评价时，不要凭记忆行事

3.4.2.1. 记忆是不稳定的，你可能只关注某些难忘的项目

3.4.3. 绩效考核可能会有压力

3.4.4. 360度考评鼓励诚实的反馈，给员工一个机会告诉管理者他们做得如何

3.4.4.1. 请认真对待360度考评，并给出深思熟虑的说明

3.4.4.2. 向上（管理者）、向下（下属）和横向（同行）

4. 向上管理

4.1. 你需要通过帮助你的管理者并确保他们会帮助你来进行“向上管理”

4.2. 接收反馈

4.2.1. 绩效考核和360度考评提供了全面的反馈，但它们的频率太低，不能完全依赖

4.2.2. 你需要定期的反馈，这样你才能迅速调整

4.2.3. 管理者们并不总是主动提供反馈，所以你可能需要主动询问

4.2.4. 可以使用一对一面谈的方式来获得反馈

4.2.5. 不要听信表面上的反馈

4.2.5.1. 你的管理者仅仅是视角之一（尽管是一个重要的视角），试着把管理者的反馈纳入你的观点，而不是直接采用管理者的反馈

4.2.6. 对别人的反馈意见也要给予反馈

4.2.6.1. 如果不这么做，可能会让别人觉得自己的反馈掉入了黑洞

4.2.6.2. 积极的结果会鼓励他们给予更多的反馈

4.2.6.3. 如果反馈没有效果，也请让你的管理者知情，他们可能有其他的主意

4.2.7. 你也可以通过要求反馈来提供反馈

4.3. 给予反馈

4.3.1. 好的管理者希望从他们的团队中获得反馈

4.3.2. 提出问题，但不要只关注问题

4.3.3. 积极的反馈同样有价值：管理者们可能很难知道哪些改变有积极的作用，他们的工作没有单元测试

4.3.4. 反馈可能会引发强烈的情绪，但要尽量保持清醒的头脑，保持谈话的建设性

4.3.4.1. 私下提供反馈，允许你的管理者与你进行诚实的对话，可以使双方都不感到被攻击

4.3.4.2. 经常地反馈可以消除意外状况，不要等到问题恶化，直到为时已晚

4.3.5. 不一定所有的反馈都是悲观、失望的场景，SBI框架也适用于积极的反馈

5. 职业生涯建议

5.1. 软件工程师是一个伟大的职业，充满了迷人的挑战

5.1.1. 成为资深工程师或主任工程师需要时间和毅力，但你可以通过对自己的职业发展负起责任来帮助自己

5.1.2. 资深工程师的工作范围和重点也会发生变化

5.2. T型人才

5.2.1. 软件工程有许多专业领域：前端、后端、运维、数据仓库和机器学习等

5.2.2. “T型”工程师在大多数领域内都能有效地工作，并且至少是某一个领域的专家

5.2.3. 对你的团队来说，也要牢记广度/深度范式

5.2.4. 每个人都有自己的专长和短板

5.2.5. 一个好的团队会有一个坚实的T型人才的组合

5.2.5.1. 产品开发团队的成员有可能拥有不同的深度领域

5.2.5.2. 础设施团队的成员则更有可能拥有共同的专长

5.2.6. 随着公司的发展，他们越来越多地为每个领域雇用专家，这将推动已经在公司工作的每个人也走向专业化

5.2.6.1. 通才会发现自己可操作的领域越来越小

5.3. 参加工程师训练营

5.3.1. 许多公司都设有工程师训练营以鼓励学习、开发和共享的企业文化

5.3.2. 招聘、面试、午餐会、研讨会、聚会、阅读小组、开源项目、学徒和导师计划都是可以参与的机会

5.3.3. 寻找并加入你最感兴趣的项目，你可以通过参加项目或领导项目来参与训练营

5.4. 主导你自己的晋升

5.4.1. 一旦你了解了评估标准和晋升流程，就进行自我评估，并获得他人的反馈

5.4.2. 如果你已经拖到了你认为你应该得到晋升，但你的管理者并不同意的时候，晋升谈话就会变成如何解决冲突，而不是提出一个计划

5.5. 换工作需谨慎

5.5.1. 工作可以拓展你的技能和人脉，但频繁地换工作会阻碍你的成长，在招聘经理的眼里也很难看

5.5.2. 资深工程师需要利用过去的经验来指导决策

5.5.2.1. 如果你不断地更换工作，你永远不会看到你的决定是如何长期发挥作用的，这将阻碍你发展作为高级工程师所需的直觉

5.5.3. 如果你的日程安排允许，开源项目和副业项目也是保持新鲜感的好方法

5.5.4. 你也可以考虑留在同一家公司，但更换团队

5.5.5. 特殊的机会不会在方便的时间内出现，但当它出现时，你应该对它们持开放的态度

5.5.5.1. 让自己接触不同的技术栈、同事和工程师团体也有价值

5.5.5.2. 工程师的工资一直在快速增长，你的公司可能不会像市场那样快速地加薪

5.5.5.2.1. 换工作往往更容易赶上市场的步伐

5.5.5.3. 如果你仍然有适当的薪酬、成长和学习，就请坚持你现在的工作

5.5.5.4. 看到团队、公司和软件随着时间的推移而不断发展是非常有价值的

5.5.6. 没有充分的理由就不要换工作

5.5.6.1. 害怕错过(fear of missing out，FOMO)并不是一个换工作的好理由

5.5.7. 事情不顺时要采取行动

5.5.7.1. 人力资源部门的作用是保持稳定，使公司不受法律和合规性问题的影响，这与使事情正确或公平并不完全相同

5.5.7.2. 如果你被告知事情会发生变化，给你的管理者3到6个月的时间是合理的

5.5.7.3. 糟糕的业务、匮乏的领导力、有害的企业文化，换一家新公司会是更好的选择

5.5.8. 不要待得太久

5.5.8.1. 工作僵化、停滞不前是改变现状的正当理由

5.5.8.2. 在一家公司工作时间长的工程师自然会成为“历史学家”

5.5.8.3. 如果你的价值更多来自过去的工作而不是现在的贡献，那么它就会阻碍你的成长

5.5.8.4. 更换公司并在一个新的环境中找到自己，可以重启你的成长

5.6. 自我调节

5.6.1. 软件领域的工作并不是没有压力的

5.6.1.1. 马拉松式的编程和缺乏睡眠会损害你的代码、身体健康和个人社交

5.6.1.2. 工作可能很忙碌，竞争很激烈，技术发展又很快，而且总是有更多的东西需要学习

5.6.2. 即便你有一张健康的工作时间表，每月工作的劳累也会让你疲惫不堪

5.6.2.1. 利用年假和学术休假来短暂脱离