2 年加薪 4 次！这位软件工程师告诉你“秘诀”

译者 | 弯月

出品 | CSDN（ID：CSDNnews）

免责声明：

1、本文的观点来自一名普通的软件工程师。

2、我的意图不是炫耀，而是分享个人经验，希望对大家能有所启发。

3、虽然涨工资是每一位打工人的梦想，但在这篇文章中，我将重点介绍如何提高自己的技术力。

前言

本文将重点讨论技术、经验、机遇和心态，以及如何提高自己的技术力。

我认为成长的过程更重要，而且我并没有奢望不断升职加薪。我的目标不是往上爬。其实，我并没有一个真正的目标，我只是想开开心心地工作，同时还能拥有一些自主权和控制权，拥有一个可以学习很多知识的空间。

鉴于此，可能我的个人经历无法帮助你攀登职业阶梯。但我希望能对你有所启发，能够更好地生活和工作。

此外，如果你的目标是在公司内升职加薪，在这里我有两个肤浅的建议：

• 了解公司的职业阶梯：为了能够获得晋升，你需要了解自己所处的位置，以及下一个级别的职责要求。

• 与经理搞好关系：通过一对一的面谈了解职业阶梯、获取反馈，并咨询你可以参与的项目。

获得加薪的途径有很多种，但对我来说，以上建议是帮助你迈出第一步的基础。

个人经验

外部因素

首先，我不得不说外部因素很重要。我所在的公司是巴西发展最快的初创公司之一。公司的市值已达 51 亿美元。目前公司收到了大量投资，在不断发展，因此对于渴望升职加薪的员工来说，无疑是一个大好消息。

除此之外，我们公司能够吸引到人才，不仅是工程方面，而且在产品和其他组织方面也是如此。

就我个人而言，公司的文化对我们工程师非常友好，因为我感觉在公司工作很安全，可以展示和讨论我的想法，诚实地分享我的个人观点，而且公司还鼓励我们勇于挑战现状。

如下是关系到个人发展的重要外部因素，与技术力和工作无关：

• 我们是一家发展速度非常快的公司；

• 公司运营良好，而且在持续增长；

• 公司有很多有才华的人；

• 公司的文化对工程师非常友好（但不仅限于工程师）；

实现团队的目标

有一点很重要，我的工作重点主要放在了我们团队和每个季度的目标上。了解团队的目标、业务指标以及有待实现的功能列表背后的原因，对我来说非常重要。

为了让每个人都明白团队的目标，我们建立了一个页面，其中记载了与我们团队相关的所有业务和产品。我还创建了一个仪表板，方便我们查看关键指标。

了解背后的动机只是第一步。作为工程师，我们的职责之一是提供帮助，并提出解决方案。

与产品经理、设计师和其他工程师合作是团队取得成功的关键。然而，相关内容的讨论却很罕见，在刚开始从事软件工程时，我总是不太理解这一点。这里协作的意思很广，下面我会列出以前曾尝试过的一些想法：

• 来自各种渠道的想法：工程经理、项目经理、设计师或团队以外的其他人。在理解了他们的想法之后，你可以利用自己的工程背景与当前系统的知识，帮忙塑造和完善解决方案。

• 了解系统的痛点。

• 每个人的背景不同，提出的解决方案也不同：每个解决方案都需要付出时间和努力，而你们团队就是需要负责实现这些方案。

• 如果解决方案需要尽快部署到用户，但缺乏工程最佳实践，则可以协商是否可以在实现解决方案后，花些时间改进方案。

• 或者，协商是否可以延长一些时间，确保交付拥有最佳实践的功能或产品。

• 来自你个人的想法：你看到的可以改善用户体验和业务指标的功能或产品。稍后，我会介绍我的一段个人经历：在领导一个 Web 优化项目的过程中，我成为了具有产品意识的软件工程师。

• 建立促进协作的空间：如果公司的文化已经创造了这样的空间，你就可以安心地讨论各种想法，并提出自己的不同意见。拥有一个越来越多样化的团队对于丰富团队的讨论很重要，拥有一个安全的空间是让员工心无所忌地展开讨论的基础。

• 为了创造这样的空间，应该让团队中的每个人都提出问题，并讨论和分享他们的意见。

• 积极倾听，关心他们提出的问题，并记录他们提出的意见。

• 优化产品开发流程：讨论战略的空间、讨论季度目标和指标的空间、讨论工程挑战和架构/解决方案的空间。

重点在于，当你成为一名成熟的工程师时，不仅需要编写代码交付产品，还要在软件工程的各个方面开展协作。你必须明白，不断改善团队、流程、交付和开发体验也是自己的责任。

挑战现状：一切皆可改进

我需要强调的是，我们公司的文化不仅鼓励我们挑战现状，而且还希望我们积极地改善一切不合理的地方。因此，在这种环境中，我可以质疑一切，尝试各种想法并改进。

公司改进的目标是使组织变得更好，我可以想到的包括流程、技术、团队文化、开发人员体验等等。

我的想法是首先从小范围入手，专注于我们团队，尝试实验，在这个过程中学习，然后再改进。如此循环，直到想法成熟。然后再扩展到更广泛的范围，比如一个小队/团队或整个组织。

一个好的解决方案首先会提出一个明确定义的问题。这就是为什么理解问题和上下文如此重要的原因。每天都与工程问题打交道，因此我对事物的运作方式有了很多了解，并且能够让我联想到更好的解决方案。

在一家大型科技公司工作时，技术、模式和惯例可以加快我们工作的速度，但我们始终需要牢记质量至关重要。

我提出的第一个方案是，就如何在 JavaScript 和 React 项目中使用 React、优化、不变性和测试，编写一本指南。编写指南是一个很好的提议，因为首先我们可以规范整个公司的约定和模式；其次，可以让我们更加重视这些主题，作为工程师，我们可以讨论我们希望采用和形式化的约定。我喜欢整个过程，主要是因为我收到了其他工程师的反馈、不同的观点和见解，我们可以针对每天面临的常见问题提出很好的解决方案。

通过这个提议，我更加有信心，相信我们可以改进工程领域内的很多工作。因此，每次遇到问题，我都会整理出自己的解决方案和模式，并与其他工程师分享。

有一次，我发现我们没有机会在 PWA 中使用 Hooks，因此我做了一些实验（https://www.iamtk.co/react-hooks-context-api-and-pokemons），然后与同事们分享。

此外，对于 JavaScript 模式，我还尝试了一些关于闭包和递归、React 的国际化抽象和函数式编程等想法。

随着我们的代码库变得越来越复杂，理解的难度也越来越高，主要是状态管理部分，我们使用了大量的 Redux。

给状态管理添加类型可以让我们更有信心，并让应用程序中的数据结构更加清晰。

最后，我们选择了 TypeScript 来处理这个问题，而我也学习到了很多新知识，也尝试用新的思维模式去思考 TypeScript。由于我们所有的代码库几乎都使用了 React，因此提供有关 React 和 TypeScript 如何协同工作的示例非常重要。

应用程序的测试一直是同事们感兴趣的话题。我们建立了一个小组，专门讨论测试，并创建了自己的模式和约定。以下是我的两个实验： 

• TDD、JavaScript和 React（https://www.iamtk.co/tdd-functions-and-react-components）

• React 测试库的基本选择（https://www.iamtk.co/basic-recipes-for-react-testing-library）

我认为 TDD 是一个更加个性化的过程，但使用测试库是我们测试应用程序的默认方式。

技术在不断变化和进步。我们看到了许多库的出现，其中有两个引起了我们的注意：react-query 和 swr。于是，我和同事一起进行了实验，并针对应用 react-query 建立了一个架构决策记录。我们看到了使用这种模式并取代redux-pack 和 redux-saga 的潜力，因为二者是我们的性能瓶颈。此外，react-query 带来了更直观的方法，可以解决服务器缓存的问题。

除了技术，我们还可以考虑开发者体验。工程师的工作时间也越来越重要。

但在我看来，工程师的时间不仅非常重要，而且关系到许多公司的业务扩展。提高工程师的生产力不需要单独的团队或平台小组，工程师自己就可以设计更好的流程，并解决生产力的瓶颈。只不过，我们需要与经理交谈，为此类工作争取更多时间，必要时甚至可以创建一个新团队。 

我接触过开发者体验的工作，而且我特别喜欢。我认为工程师的主要痛点如下：

• 监控：检测新系统，创建仪表板链接，记录每天使用监控系统的情况。

• 测试：试验新的测试工具，分享这些经验，编写相关的使用指南和示例，展示不同的模式。

• CI/CD：不仅可以优化 CI构建，提高开发人员的生产力，而且还可以自动化发布的过程。以前需要使用 GitHub 标签，现在只需要合并 PR，就会自动部署。

• 代码格式：现在使用prettier 和 ESLint 规则。我能够在一周内将整个代码库变成更漂亮的格式。因为我们有高质量的自动化测试和监控系统。此外，还能实现预提交钩子，每次提交代码自动运行 prettier 和 ESLint。

• Web 性能：我曾有机会参加一个 Web 性能改善项目，当时我主要负责使用性能工具来收集真实的用户指标。

监控和测试是我们尝试更多实验、重构和修改代码的基石。自动格式化代码可以为工程师节省出大量时间，用于讨论业务规则和架构，而不是争论是否需要添加分号。Web 性能工具是衡量与提高软件性能的基础。CI 可以提升每位工程师的体验。而持续交付还能让开发者体验更加流畅。

挑战现状的最后一点是分享知识。

我个人比较喜欢将学习、研究或实验的一切都记录下来，然后与同事分享。具体的格式没有限制，文章、指南、幻灯片或者是简单笔记等等都可以。 

我已经坚持了 8 年，所有的记录都在这里：https://www.iamtk.co/writings。

这是我与同事分享学习成果的一种方式，也是与技术社区分享想法的方式。我可以在这个过程中，建立自己的想法，然后加深对每个主题的理解。

先撰写文章，然后再分享。记录和组织自己的想法与实验是创作的基础。我通过撰写文章详细说明了我想分享的所有内容，而这些文章可以逐步演变成指南、技术评论或幻灯片等。

但我最喜欢把我的作品变成话题，与团队展开讨论。我们经常召开小组学习会议，每个工程师都可以根据一个主题来计划会议。这是一种非正式的会议，目的是方便我们互相聊天、讨论和学习。

有了更多的知识和经验，我还可以非正式或正式地指导我的同事。与他们交谈，帮助他们成长，并以某种方式影响他们的工作。

提升自己的技术力

在本文涵盖的所有主题中，我认为最有趣的是提升自己的技术力。

我喜欢不断寻找各种途径来学习新知识。空闲时间，我会一直思考自己的学习方式。我的学习方式主要有以下三种：

• 基础知识

• 工作中需要的知识

• 极大值与最大值

在考虑基础知识时，我会想到第一原则。软件工程的基础是什么？哪些是我们百分百确定的？从这个原理出发，我们就能够理解和解决更困难、更复杂的问题。

在软件工程中，我们可以学习的知识没有尽头。当我还是一名后端工程师时，我需要重点掌握的技术包括理解 API、系统架构、自动化测试和数据库。这里的每个主题都可以进行进一步的挖掘。熟练掌握这些技术，就可以更好地解决后端工程中更困难的问题。

前端工程也同样。我从学习  HTML 和 CSS 开始，后来又学习了 JavaScript 的知识。如今，我们还需要理解其他技术来完成更复杂的工作，例如构建系统（编译器和捆绑器）、自动化测试（用于组件和集成）、浏览器引擎等等。

学海无涯，我也无法掌握所有的技术，但从上述第一原则出发，不仅可以帮助我解决复杂的问题，还可以帮助我了解自己还需要学习哪些技术。

工作中需要的知识指的是，日常工作或业余项目中遇到的新挑战，并且我需要某种特定的知识来解决问题。例如，在工作中，我需要了解监控、测试和 Web 性能；以及在业余项目中，我需要更好地了解 CMS 和文本编辑器。

极大值与最大值我我最近学习到的一个概念。在我看来这个概念违反直觉，但随着我的了解加深，我越来越清楚知识组合多样化的重要性。

如果你是一名 JavaScript 工程师，那么学习 JavaScript 是显而易见的事，但很快你就会陷入局部极大值。我的做法是走出自己的舒适圈，学习 TypeScript 以及如何充分利用类型系统。接着，我还学习了关于浏览器、算法和数据结构的知识。如今，我将时间和精力全部投入到编译器、打包器的工作原理和 Rust 的学习上。我一直在努力学习可能会对我的工作以及我对工程的看法产生直接或间接影响的知识。

在工作中，我会积极寻求经理和同事的反馈，并思考如何成为一名更好的软件/产品工程师。

积极地寻求反馈是我职业生涯早期开始的一种习惯。最初我认为，反馈对我很有帮助，我应该积极地接受反馈。但这还不够。在之前的一份工作中，每周我都会与经理开会，并询问她对我一周工作的看法：

• 哪些方面表现良好，应该继续保持；

• 哪些方便表现还不错，但也有可以改进的地方；

• 哪些方面表现不佳，应该改进。 

我认为，上述各项可以帮助我学习、工作和养成良好的习惯。

此外，我们还会讨论有助于项目发展的反馈和想法。每周我都会整理一份改进事项，并与经理分享，以便在流程和项目的代码库中得以实施。

还有一种接收反馈的有效方法是制定个人发展计划。我将这份计划分享给了经理，并一起讨论我的职业发展、学习内容和我感兴趣的事情，并获得了有关如何改进我的行为和习惯的反馈和建议。这也是一种提高自我意识，并与经理讨论如何在项目中发挥自己的技术力优势的好方法。我非常喜欢制定个人发展计划，并与同事们分享。每个人都知道我在学习什么，这是在团队内讨论和分享更多知识的起点。

但是，如果你不想制定职业发展计划，那也没关系。你可以通过其他途径鼓励团队成员接受和提供反馈。为了收到同事的反馈，我会首先向他们提供反馈（非正式和正式），并告诉他们，我也非常期待收到他们的反馈。

关于如何成为一名更好的产品/软件工程师，网上有大量有趣的文章，下面我来分享一下自己的看法和经验。

对我来说，第一步是了解自己正在开发的产品。

这是一款面向最终用户的产品吗？

• 客户是谁？

• 我可以通过数据了解他们的行为吗？

• 与设计师交谈，并记录他们的看法。

• 业务的运作模式是什么？

这是一款面向内部利益相关者的产品吗？

• 这些利益相关者使用该产品的目标是什么？

• 缺少哪些功能？

• 常见的问题是什么？

这是一款面向工程师的产品吗？

• 他们目前的工作流程是什么？

• 哪些是他们满意的方面？

• 哪些是他们不满意的方面？

对于以上三个群体（以及任何其他群体），我们都需要考虑 UX，并找到帮助他们实现目标的方法。

了解自己正在开发的产品是一个很好的起点。理解有关业务、用户及其使用方式也是获取更多产品相关知识的重要渠道。

第二步，了解 OKR 与产品的目标。了解我们为什么要创建功能 X、我们想要实现什么目标，并积极参与讨论做什么以及如何做。

这些会议向工程师敞开大门是一项明智的决定，因为我们不仅可以帮忙思考产品创意，还可以深入了解软件本身。由于我们拥有工程和软件背景，因此在创建策略和讨论有关产品的实现时有非常大的优势。

如果可能，不要错过了解产品信息的机会，并积极参与战略与计划会议。

通过有趣的项目挑战自己

有趣的项目可以帮助你在工作中积累更多经验。参与具有挑战性的项目，可以让你学习到更多技术，也就是你不知道且需要搜索和学习的技术。完成这样的项目后，应该做一个回顾，总结表现良好和差强人意的方面。这也是一种学习经历。

我喜欢具有挑战性的项目。首先，我喜欢挑战；其次，如果能在工作中学习新事物，我就能找到更多乐趣；最后，我喜欢回顾过去，并为自己所做的工作感到自豪。

我参与过的项目包括：

• 从头开始构建产品和业务：

• 为摄影师构建了一款全新的应用；

• 在子项目中构建了销售业务。

• 优化一款面向房地产业主的 Web 应用的性能

• 前端开发

• CI/CD 优化、监控系统和自动化测试

我通过这些项目，学到了很多知识。在构建摄影师的应用中，我第一次使用无服务器函数和 React。在构建销售业务时，我第一次使用 Clojure 和支付系统。在 Web 性能提升项目中，我第一次深入研究 Web 性能以及构建工具（主要是 Webpack）。开发者体验让我对工程师的工作流程有了宏观的认识，我也可以将这些知识应用到其他地方。

参与具有挑战性的项目是自我提升的好办法，因为我们可以借此不断学习和提高技术力。寻找有趣的项目并不断学习。回顾过去，我为自己的决定和发展感到自豪。

写日记

我有记录一切的习惯。从我学习的知识到读书笔记，从文章创意到日记。写日记已成为我每日的习惯，它可以帮助我思考，并让我反思自己过去做的事情。

以下是我的一系列做法，仅供你参考：

记录完成的每一件事情

• What：目前正在从事的项目，正在解决的问题，或者实现的功能。

• How：如何决定解决方案和架构，我处理了哪些 PR，做了哪些权衡，团队如何合作，以及我在整个项目中的角色。

• 学习：我学到了哪些知识，包括架构、解决方案、流程、委派、沟通、优先级等所有可以提升并用于下一个项目的知识。

了解工作的影响力

• 我们应该弄清楚的第一件事是：我们正在解决什么问题，为什么（这通常来自 PM、设计师或业务人员），以及我们应该如何解决这个问题。

• 密切关注重要指标：

• 业务/用户体验：通过项目经理和设计师，了解我们需要关注的业务指标和 OKR。

• 工程：性能、构建时、错误日志、监控系统。

• 开发者体验：同事反馈的痛点是什么，并提出解决这些问题的方法。

周报

• 在一周结束时，我还会将所有的日常文档编纂成周报。

• 回顾过去一周的工作，我学习到的知识，以及必须克服的挑战。

季报

• 这种记录方式也很棒，因为我可以在每个季度末将所有笔记都整理成一份报告，让公司里的每个人都知道我在做什么。

• 经理可以通过这份报告了解我的工作情况。

• 经理可以通过这份报告了解我的成就。

• 经理可以将这份报告作为我的晋升材料。

这就是为什么我认为文档和报告非常强大的原因。作为工程师，我们倾向于关注日常生活中的小事，但对自己的工作有宏观认识也非常重要。这不仅会让我感到自豪，还能感受到自己的成长。

结束语

正如本文开头所述，尽管本文的标题是一个真实的故事，而且金钱是生活中宝贵的资本，但我更重视个人的技术力、经验、机遇和心态。我希望本文能对你的职业发展有所启发。

参考链接：

https://www.iamtk.co/how-i-received-4-salary-raises-in-2-years-of-quintoandar-as-a-software-engineer