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.PPP3.2.1.PPP是一种常用的更新工作状态的格式3.2.2.它是为了帮助你的管理者发现问题，找到你需要背景信息的领域，以及提供将你与正确的人联系起来的机会3.3.OKR3.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.并非所有的公司都会设定个人目标，有些公司只设定团队、部门或公司层面的OKR3.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.利用年假和学术休假来短暂脱离