Hello, and welcome! 你好,欢迎!
My name is Benoit. I have been a software engineer for the past eight and a half years. I stayed at my previous (and first) company for seven and a half years, then I joined a new one in early 2022.
我的名字是Benoit。我已经做软件工程师八年半了。我在之前的公司待了七年半,然后在2022年初加入了一家新公司。
This article comes from a recent self-reflection on the things I wish I had started doing earlier in my career and the things I wish I had done differently.
这篇文章源自我最近对我希望在职业生涯中早点开始做的事情以及我希望能够以不同方式去做的事情的自我反思。
What I am sharing here may be useful to any junior to mid-level developer who wishes to improve and progress toward the title of senior and beyond.
我在这里分享的内容可能对任何希望提高并向高级及更高级别发展的初级到中级开发人员有所帮助。
Table of Contents· My Career Evolution· Things I Wish I Had Started Doing Earlier: ∘ Write a Work Log ∘ Leave the Comfort Zone ∘ Be Curious About Other Teams and Projects ∘ Join the On-call Team ∘ Change Teams ∘ Write Blog Posts· Things I Wish I Had Done Differently: ∘ Be Careful When Introducing New Things to the Team ∘ Do Not Let Your Emotions Take Over in Front of the Team ∘ Dip a Foot Into the Hiring Market· End Thoughts
My Career Evolution 我的职业发展
Before diving into the main subject, here is my career evolution:
在深入讨论主题之前,先来看一下我的职业发展历程:
- I interned for three months at a startup (which quickly became a scale-up) company. 我在一家初创公司实习了三个月(很快就发展成了规模较大的公司)。
- After that, I did a full year of work-study, spending three months at school and nine months at work. 之后,我进行了一整年的工学结合,其中三个月在学校,九个月在工作。
- Then, I got hired as a full-time software engineer and kept this title for three and a half years. 然后,我被聘为全职软件工程师,并保持这个职位三年半。
- Quickly after the introduction of the tech career ladder, I got promoted to senior software engineer. I kept this title for three years until I left the company, at which point the tech teams accounted for approximately 200 people. 在技术职业阶梯推出后不久,我迅速晋升为高级软件工程师。在离开公司之前,我一直保持这个职称,那时技术团队大约有200人。
- I joined as a software engineer 2 at a company with thousands of tech employees. Despite the title downgrade at the second company (see Big Tech Hiring is Conservative — But Why?), I have been trying to keep the same responsibilities (and more) as before. 我以二级软件工程师的身份加入了一家拥有数千名技术员工的公司。尽管在第二家公司中职位有所降级(参见《大型科技公司的招聘保守性——但为什么?》),但我一直努力保持与之前相同的责任(甚至更多)。
Illustration of my career evolution over the past 8.5 years.
我职业发展的插图,涵盖了过去8.5年的时间。
In the beginning, I was part of the frontend team. The tech organisation was split between backend and frontend developers. At that time, we were no more than 30 engineers. When our new CTO arrived a year later, he introduced an organisation based on feature teams: the Spotify Model. Although there was some friction at the start (people don’t like change), this reorganisation definitely turned out to be for the better.
一开始,我是前端团队的一员。技术组织分为后端和前端开发人员。当时,我们只有不到30名工程师。一年后,新的首席技术官到任后,他引入了一个基于特性团队的组织模式:Spotify模型。虽然一开始有些摩擦(人们不喜欢变革),但这次重新组织明显是为了更好地发展。
I stayed for more than five years in the same feature team. I was there at its inception, so throughout the years, I became the tech referent of the project. Eventually, I joined another team, where I worked until I left for a whole new adventure a year later.
我在同一个特性团队待了五年多。我在团队成立时就在那里,所以在这些年里,我成为了项目的技术参考人。最后,我加入了另一个团队,在那里工作了一年后,我离开了,开始了全新的冒险。
All right, enough with the context. I hope you’ll enjoy reading the rest, and that the following advice will be actionable for your career progression!
好了,不再多说废话。希望你能享受接下来的阅读,并且以下的建议对你的职业发展有所帮助!
Things I Wish I Had Started Doing Earlier
我希望我早点开始做的事情
Write a work log 写一份工作日志
A work log is a document that contains the list of tasks you accomplished. The granularity and the type of tasks don’t matter, as long as you keep track of what you did.
You can fill in this document at the frequency you want. I would advise doing that on a weekly basis. Tasks done during the week are still fresh on Friday, so you won’t struggle writing them down.
您可以根据自己的需求填写此文件。我建议您每周填写一次。在周五填写时,您对本周完成的任务还记忆犹新,这样您就不会遇到困难。
Why is this work log important? For the following two reasons:
为什么这份工作日志很重要?有以下两个原因:
- To remind yourself of all the things you have done over the past 6 to 12 months. This is very valuable during performance reviews, so you can show your manager what you have accomplished and why you deserve that raise or promotion. 回顾过去6到12个月你所做的所有事情,这对于绩效评估非常有价值,这样你就可以向经理展示你取得的成就以及为什么你应该得到加薪或晋升。
- To keep track of projects, notable responsibilities, and critical numbers (e.g., decreased latency by X% for a critical service) that you had over your career. This is great for completing your resume, whenever you want to venture into the waters of the hiring market. 为了跟踪你在职业生涯中承担的项目、重要职责和关键数字(例如,为关键服务减少了X%的延迟),这对于完善你的简历非常有帮助,无论何时你想要进入招聘市场。
I started writing a work log roughly two years before leaving my first company. So, over the past eight and a half years, my work log contains only three years of data (with some gaps here and there). When I had to write my resume in late 2021, I had to rely on my memory to remember what I did during the first five years of my career. To say the least, it took me some time to remember everything valuable, and I’m sure I forgot some of them.
我在离开第一家公司前大约两年开始写工作日志。所以,在过去的八年半里,我的工作日志只包含了三年的数据(偶尔有些间断)。当我在2021年底写简历时,我不得不依靠记忆来回忆我在职业生涯的前五年里做了什么。可以说,我花了一些时间来回忆所有有价值的事情,但我肯定有些遗忘了。
You can use a work log template if you want to (here is an example). Personally, I have been using Microsoft Notes for the first two years, then I switched to a Google Doc with bullet points (one list for each month of the year).
如果你想的话,可以使用工作日志模板(这是一个例子)。就我个人而言,前两年我一直使用微软笔记,然后我转而使用谷歌文档,并使用项目符号(每个月份一个列表)。
Leave the comfort zone 离开舒适区
This is the best way to learn and become a better developer. The comfort zone is the scope, environment in which you feel comfortable doing your job. It is the teammates you already know and work with daily, the projects you have been working on for years, the responsibilities you have been carrying, and so on.
这是学习和成为更好的开发者的最佳方式。舒适区是你感到在工作中感到舒适的范围和环境。这是你已经认识并与之合作的团队成员,多年来一直在进行的项目,你一直承担的责任等等。
But why would someone advise you to leave this wonderful situation? Because this environment is not suitable for evolution.
但是为什么有人会建议你离开这个美好的境地呢?因为这个环境不适合进化。
Sure, if you stay in this bubble, you are an efficient person. You already know who to talk to about a specific subject, and what file in the codebase has to be changed. But what is better than one efficient person? Several efficient people!
当然,如果你待在这个小圈子里,你就是一个高效的人。你已经知道该找谁谈论特定的话题,以及在代码库中哪个文件需要改变。但是有什么比一个高效的人更好呢?多个高效的人!
Once you have reached the comfort zone on a particular topic, you should look for:
一旦你在某个特定的话题上达到了舒适区,你应该寻找:
- Mentoring people, so they become comfortable with this topic. 指导人们,使他们对这个话题感到舒适。
- Look for something new to do outside of your comfort zone. 寻找一些超出你舒适区的新事物去做。
Mentoring is one of the responsibilities that is expected from a senior position. It is a great way of helping our coworkers to be more efficient quickly. You become a force multiplier.
指导是高级职位所期望的责任之一。这是帮助我们的同事们迅速提高效率的绝佳方式。你成为了一个力量的倍增器。
As for the new things to do, it could be anything. Here is a non-exhaustive list for inspiration:
至于新的事情要做,可以是任何事情。以下是一份非详尽无遗的灵感清单:
- Contribute to a team/organisation project you never had the chance to touch before, e.g., because it was always assigned to the same person (who was in their comfort zone). 为一个你以前从未有机会接触过的团队/组织项目做出贡献,例如,因为它总是被分配给同一个人(他们在自己的舒适区)。
- Write documentation about a topic you are comfortable with. The objective is to share your knowledge and indirectly mentor people so they can get this knowledge faster than you did. Also, writing is a great skill to learn and improve, be it for documentation, emails, instant messages, RFCs (Requests For Comments), blog posts, etc. 写一份关于你熟悉的主题的文档。目标是分享你的知识,间接地指导他人,使他们能够比你更快地获得这些知识。此外,写作是一项很好的技能,无论是用于文档、电子邮件、即时消息、RFC(评论请求)、博客文章等,都能学习和提高。
- Volunteer to participate in cross-team projects. You can even take a leadership position during these projects to feed two birds with one hand. 自愿参与跨团队项目。你甚至可以在这些项目中担任领导职位,一举两得。
- Take care of improving tooling, monitoring, or team/organisation processes. 注意改进工具、监控或团队/组织流程。
- Participate in meetups organised by the company. 参加公司组织的聚会。
- Join a community/guild at the company to work on org-level, cross-teams projects. 加入公司的一个社区/公会,参与组织层面的跨团队项目。
- Help the hiring team by conducting technical interviews, and/or checking take-home exercises from candidates. 通过进行技术面试,或者检查候选人的作业,来帮助招聘团队。
The goal is to learn something new. Performance reviews can help you define what to do, and how to do it when stepping outside your comfort zone. But you don’t have to wait for this moment to make the move. You can do that at any time, as long as your manager is aware of it. For instance, you can talk about it during a 1–1 meeting. One of the core objectives of your manager is to help you progress in your career, so I highly recommend talking with them before leaving your comfort zone.
目标是学到新东西。绩效评估可以帮助你确定在走出舒适区时该做什么以及如何做。但你不必等待这个时刻才采取行动。只要你的经理知道,你可以随时这样做。例如,在一对一会议中可以谈论这个问题。你的经理之一的核心目标是帮助你在职业生涯中取得进步,所以我强烈建议在离开舒适区之前与他们交谈。
There may be some subjects you don’t really care about. In my case, for a long time, I didn’t want to learn anything related to machine learning and data analytics. But, my curiosity and thirst for knowledge eventually led me on the path of these topics. Even though I didn’t get the chance to work on company projects based on these fields, I am glad I learned about them. It is great to have meaningful conversations with my peers, and it can even help me find ideas I couldn’t get without this knowledge.
可能有一些你并不太关心的学科。在我的情况下,很长一段时间里,我不想学习任何与机器学习和数据分析相关的东西。但是,我的好奇心和对知识的渴望最终让我走上了这些话题的道路。尽管我没有机会在公司项目中应用这些领域的知识,但我很高兴我了解了它们。能够与同行进行有意义的对话是很棒的,甚至可以帮助我找到我在没有这些知识的情况下无法得到的想法。
If you want to progress in your career, I strongly encourage you to leave your comfort zone and learn new things every time you get the chance. And I’m pretty sure this advice also applies to one’s personal life too!
如果你想在职业生涯中取得进步,我强烈鼓励你走出舒适区,每次有机会都学习新的东西。而且我相信这个建议同样适用于个人生活!
Be curious about other teams and projects
对其他团队和项目保持好奇心
This one is close to the previous one, though you don’t have to endorse additional responsibility.
这个与之前的那个相似,尽管你不必承担额外的责任。
For a long time, I did not care about teams and projects outside my team’s scope. Our product had some dependencies with services owned by other teams, but as long as the API between them and us was clearly defined, we didn’t have to know anything about their services.
很长一段时间以来,我对我们团队范围之外的团队和项目都不太关心。我们的产品与其他团队拥有的服务存在一些依赖关系,但只要我们之间的API定义清晰,我们就不需要了解他们的服务。
The only time we had to open the box and see how things worked was when we had to contribute to these projects. As we were organised in feature teams, if we needed some changes in one of the other projects of the company, we had to make these changes ourselves. Each feature team had its own roadmap, so we couldn’t ask another team to do the work for us. Although we were slow at first, with the help of the other team, we progressively became more efficient when contributing to their projects.
唯一一次我们不得不打开盒子并看看事物是如何运作的是当我们需要为这些项目做出贡献时。由于我们是按特性团队组织的,如果我们需要对公司的其他项目进行一些更改,我们必须自己进行这些更改。每个特性团队都有自己的路线图,所以我们不能要求另一个团队为我们完成工作。虽然一开始我们进展缓慢,但在其他团队的帮助下,我们逐渐在为他们的项目做出贡献时变得更加高效。
But, for the other services that we didn’t directly interact with, I had no idea how they worked, and what was their precise role in the system. It was when I joined the on-call team, years later, that I really started having a look at all the services of the company. When I finally got the full picture, it felt great.
但是,对于我们没有直接互动的其他服务,我不知道它们是如何工作的,以及它们在系统中的确切角色是什么。几年后,当我加入了值班团队时,我真正开始了解公司的所有服务。当我最终获得了全面的了解时,感觉非常棒。
- I had a better understanding of what the culprit could be when things went wrong. 当事情出错时,我对可能的罪魁祸首有了更清楚的了解。
- I knew why we needed that particular service or why we made that data store choice. 我知道我们为什么需要那个特定的服务,或者为什么我们选择了那个数据存储方式。
- Finally, piecing everything together, after years of bringing value to the company, provided an awesome feeling of “Ohhh, now I get it.” 最后,把一切都拼凑在一起,经过多年为公司创造价值,给人一种令人惊叹的感觉,就像是“哦,现在我明白了”。
If you can, take a look at the other projects and teams at your company. Read their internal wiki pages, attend their demos, and read their public documentation. This is something you can do from time to time; it doesn’t have to be a sustained effort. Bonus: if you can draw a diagram and write some documentation about the “full picture,” do it. Chances are a lot of people in the organisation will thank you for that!
如果可以的话,看看你公司的其他项目和团队。阅读他们的内部维基页面,参加他们的演示,并阅读他们的公共文档。这是你可以随时做的事情;不需要持续不断地进行。额外加分:如果你能画一张图并写一些关于“整体情况”的文档,那就去做吧。很可能组织中的很多人会感谢你!
Notice that you do not have to produce anything here, compared to the previous advice regarding the comfort zone. All you need is to be curious, read documentation from the other teams, and ask questions. You might meet people from other teams along the way, and you may discover projects that you really want to work on.
请注意,与之前关于舒适区的建议相比,你在这里不需要产出任何东西。你只需要保持好奇心,阅读其他团队的文档,并提出问题。你可能会在路上遇到其他团队的人,你可能会发现一些你真正想参与的项目。
Join the on-call team 加入值班团队
This one may feel controversial, and it may not even be possible at your company. Of course, you should consider this advice only if your company has a healthy on-call environment (see On-call Compensation for Software Engineers).
这个可能会引起争议,甚至在你的公司可能不可行。当然,只有在你的公司有健康的值班环境时,你才应该考虑这个建议(参见《软件工程师的值班补偿》)。
The on-call team is composed of people who are willing to intervene if something goes wrong during and outside business hours, i.e., at night, during weekends, and on bank holidays. Your company may have a dedicated team of SREs (Site Reliability Engineers) for it, and/or your team may not be responsible for DevOps work.
值班团队由愿意在工作时间以及非工作时间(即晚上、周末和节假日)出现问题时进行干预的人组成。您的公司可能有专门的SRE团队(网站可靠性工程师),或者您的团队可能不负责DevOps工作。
But, if you have the possibility to join the on-call team, whether it’s for the product you work on, or for the whole company (depending on its size), I would suggest doing it.
但是,如果你有可能加入值班团队,无论是为了你所工作的产品,还是为了整个公司(取决于公司的规模),我建议你这样做。
Here’s some advantages of joining this team:
加入这个团队有以下几个优势:
- You learn a lot about the “behind the scenes” of the products and services that make the company thrive. 你会对使公司蓬勃发展的产品和服务的“幕后工作”有很多了解。
- You feel more empathetic to your coworkers, as you experience the weight of responsibility whenever something bad occurs, especially at night. 当你经历到责任的重担,尤其是在夜晚发生不好的事情时,你会对同事们更加有同理心。
- You feel more engaged with the company, as you invest more of your time into making sure the products and services work as expected for the customers. 随着你投入更多时间确保产品和服务能够如预期般运作,你会感到更加投入于公司。
Again, a healthy on-call environment is required before embracing these responsibilities.
再次,在承担这些责任之前,需要一个健康的值班环境。
At my first company, I joined the on-call team (who was responsible for all the services) approximately two months before leaving. I wish I had joined earlier, as I learned a lot during these few months, and this additional responsibility was well compensated.
在我第一家公司,我在离职前大约两个月加入了值班团队(负责所有服务)。我希望我能早点加入,因为在这几个月里我学到了很多东西,而且这份额外的责任也得到了很好的补偿。
At my second and current company, I joined the on-call team (who is responsible for the services of a single product) two to three months after my first day. For now, I am only intervening during business hours, but eventually, I will be able to respond to pages during the night and on the weekends.
在我目前的第二家公司,我在入职后的两三个月加入了值班团队(负责一个产品的服务)。目前,我只在工作时间内进行干预,但最终,我将能够在夜间和周末响应页面。
Change teams 换团队
I can see three reasons why you would move to another team:
我可以看出你转到另一个团队的三个原因:
- You are too comfortable in your current position, and you would like to go out of your comfort zone. 你在现在的职位上太过舒适,而且你想走出你的舒适区。
- You don’t really like the projects/scope of the team, and you wish to work on projects that you enjoy more. 你并不真的喜欢团队的项目/范围,你希望能够参与更加喜欢的项目。
- The relations with your coworkers and/or manager have deteriorated, and you want some fresh air while still being part of the company. 与同事和/或经理的关系恶化了,你希望在公司中仍然能够呼吸到新鲜空气。
If you see yourself in one of these situations, then I encourage you to consider a new team instead of resigning and looking for a new company.
如果你发现自己处于以下情况之一,我鼓励你考虑加入一个新团队,而不是辞职并寻找新的公司。
Changing to a new company is exhausting, and you may lose things that you really appreciated, such as coworkers, the engineering culture, or employee benefits.
换到一家新公司是很累人的,而且你可能会失去一些你真正珍惜的东西,比如同事、工程文化或员工福利。
I think team hopping is great for the following reasons:
我认为团队跳槽有以下几个好处:
- The organisation of the new team may be different (rituals, ways of working together), so you get more experience in this field. 新团队的组织可能会有所不同(仪式、合作方式),这样你就能在这个领域获得更多经验。
- You can bring positive changes that you learned from the previous team (improve the code review process, tools, libraries, and rituals), thus becoming a good practices advocate at your company. 你可以将之前团队学到的积极变化带入公司,改进代码审查流程、工具、库和仪式,从而成为公司中的良好实践倡导者。
- You can help your new teammates when they have to work on the projects owned by your previous team (i.e., knowledge spreading efficiently from one team to the other). 当你的新队友需要在你之前的团队拥有的项目上工作时,你可以帮助他们(即,知识从一个团队高效传播到另一个团队)。
- You can learn new tools, languages, libraries, architectures, and ways of solving problems. In other words, become a better developer. 你可以学习新的工具、语言、库、架构和解决问题的方法。换句话说,成为一个更好的开发者。
- Possibly, you get to work in better conditions if your change is due to reasons 2 or 3 mentioned earlier. 如果你的变动是由前面提到的第二或第三个原因引起的,可能你会在更好的条件下工作。
One year before leaving my first company, I decided to move to another team. Several teams asked me to join them, and if I could have split myself into multiple parts, I would have gladly joined them all.
在离开我第一家公司的前一年,我决定转到另一个团队。有几个团队邀请我加入,如果我能把自己分成多个部分,我会很愿意加入所有的团队。
When I joined the new team, I felt like my senior title was not legitimate anymore. I had to learn new codebases, tools, and practices. Sure, I kept my soft skills and my knowledge about the business/products, but my technical skills took a hit. Learning something new was great, of course, but I wasn’t the technical referent of the team anymore. Though, whenever the team had to contribute to the projects of my previous team, I could help them in a more efficient way. Through time, the feeling of “not deserving my title” faded away, and I became even better as I gathered more skills.
当我加入新团队时,我觉得我的高级职位不再合法。我不得不学习新的代码库、工具和实践。当然,我保持了我的软技能和对业务/产品的知识,但我的技术能力受到了打击。学习新东西当然很好,但我不再是团队的技术参考了。然而,每当团队需要为我之前的团队的项目做出贡献时,我可以以更高效的方式帮助他们。随着时间的推移,“不配拥有我的职位”这种感觉逐渐消失,我变得更加优秀,积累了更多的技能。
That being said, I think changing teams should not happen too frequently. I stayed at my first team for more than five years, then switched to the new one for one year, and eventually left the company for reasons unrelated to this new team.
话虽如此,我认为频繁换团队是不应该发生的。我在第一个团队待了五年多,然后转到新团队待了一年,最终离开公司是因为与这个新团队无关的原因。
If you feel like your situation fits in one of these three reasons, I would advise you to consider changing, but only if you stayed at least one full year with your current team. I think one year is a reasonable amount of time to feel if you belong with your current team or not. If you cannot wait for a whole year, then it means the situation is quite critical, and I would suggest involving your manager, and/or their manager to address the urgency.
如果你觉得你的情况符合以下三个原因之一,我建议你考虑转换,但前提是你至少与现在的团队待了一整年。我认为一年的时间足够让你感受到自己是否适合当前的团队。如果你无法等待一整年,那意味着情况相当紧急,我建议你与你的经理和/或他们的经理商讨解决办法。
Write blog posts 写博客文章
This one should just be “Write,” but it felt too short. Writing is one of the most important skills a developer should have. A lot of our daily work involves writing: code, messages, emails, documentation, RFCs, meeting notes, incident post-mortems, etc.
这个应该只是“写”,但感觉太简短了。写作是开发者应该具备的最重要的技能之一。我们日常工作中涉及大量的写作:代码、消息、电子邮件、文档、RFC、会议记录、事故事后总结等等。
Writing is one of the best asynchronous ways of communicating with people. They can read your messages whenever it suits them, and they are not interrupted in the middle of their task and can focus on it. Of course, in some situations, synchronous communication is a better way of communicating, i.e., video calls, in-person meetings, etc., to address some urgency or remove ambiguity and misinterpretations. But in my experience, developers are more exposed to writing than talking on a daily basis.
写作是与人沟通的最佳异步方式之一。他们可以在适合自己的时间阅读你的信息,而且不会在工作中间被打断,可以专注于工作。当然,在某些情况下,同步沟通是更好的沟通方式,比如视频通话、面对面会议等,以解决紧急情况或消除歧义和误解。但根据我的经验,开发人员更多地接触写作而不是口头交流。
Writing blog posts is interesting for the following reasons:
写博客文章有以下几个有趣之处:
- Practice makes perfect. The only way to improve a skill is by practising it. If you are not sure you are doing it right, you may ask for help from someone who does it well in your opinion, so they can mentor you on this topic. You can also read documentation and blog posts about it. That being said, the most important thing is to start practicing, even if your first articles have some flaws. 熟能生巧。提升技能的唯一途径就是不断练习。如果你不确定自己是否做对了,可以向那些在你看来做得很好的人寻求帮助,让他们在这个领域给你指导。你也可以阅读相关文档和博客文章。话虽如此,最重要的是开始实践,即使你的第一篇文章可能有些缺陷。
- It forces you to know the subject you are talking about. This is a great way of actually learning things — by diving deeper than usual into a specific subject. 它迫使你了解你所谈论的主题。这是一种真正学习事物的好方法——通过比平常更深入地研究特定的主题。
- It develops your personal brand. The more people are interested in your blog posts, the more followers you get and the more influential you become. 它能够发展你的个人品牌。越多人对你的博客文章感兴趣,你就能获得越多的关注者,变得越有影响力。
You can write articles on your personal blog, and/or on your company’s blog. Writing for your company is great at the beginning because it already has a base of readers and followers. However, you have less freedom on the subject you want to talk about, as it’s the company’s choice.
你可以在个人博客上写文章,也可以在公司的博客上写。在公司写作在开始阶段是很好的选择,因为它已经有一批读者和追随者。然而,你在想要谈论的主题上有较少的自由,因为这是公司的选择。
Do not expect to become popular after the first blog post. It takes a long time to become influential. You might even never reach that moment, and that’s fine. You should write for YOU, to improve your writing skills, and share your discoveries with the community. You should not care about how many likes or followers you get. Yes, it is a great moral boost to get that type of recognition, but your goal should not be to increase these numbers. Your goal should always be to improve your writing and share knowledge.
不要期望在第一篇博客发布后就变得受欢迎。要成为有影响力需要很长时间。甚至可能永远都无法达到那个时刻,但这没关系。你应该为自己写作,提升写作技巧,并与社区分享你的发现。不要在意获得多少点赞或关注者。是的,获得这种认可会给予你很大的鼓舞,但你的目标不应该是增加这些数字。你的目标始终应该是提升写作水平并分享知识。
I started this journey by publishing on my first company’s engineering blog: The most accurate way to schedule a function in a web browser. It even got a mention in the JavaScript Weekly newsletter, which felt awesome.
我通过在我第一家公司的工程博客上发布文章开始了这段旅程:在Web浏览器中安排函数的最准确的方法。它甚至在JavaScript Weekly的通讯中被提及,感觉很棒。
Then, in March 2021, I started writing blog posts on Dev.to, and I continue doing so occasionally. I also posted an article on HackerNoon, but I didn’t really like their editing on the title, and I felt like Dev.to would be my main blog medium, at least for now.
然后,在2021年3月,我开始在Dev.to上写博客文章,偶尔还会继续写。我也在HackerNoon上发布了一篇文章,但我并不是很喜欢他们对标题的编辑,而且我觉得Dev.to可能会成为我主要的博客平台,至少目前是这样。
Things I Wish I Had Done Differently
我希望我能够以不同的方式去做的事情
Be careful when introducing new things to the team
在向团队介绍新事物时要小心
This is especially true the more senior you become, though even juniors should feel capable of introducing new things to the team, be it libraries, languages, paradigms, ways of working together, and so on. As a junior, you will be more easily challenged by the senior folks on your team. However, the more senior you become, the easier it gets to convince people, especially juniors, to be onboard.
这一点尤其适用于你的职位越高,尽管即使是初级员工也应该有能力向团队引入新事物,无论是库、语言、范式、合作方式等等。作为初级员工,你会更容易受到团队中资深人士的挑战。然而,随着你的职位晋升,说服人们,尤其是初级员工,加入你的想法会变得更容易。
Back at my first company, a few months before moving to another team, I was in a position where I could propose… ambitious changes to the codebase. At that point, I had been learning about the Functional Programming paradigm for a couple of years, and I was convinced of its advantages.
回到我在第一家公司的时候,在转到另一个团队之前的几个月,我处于一个可以提出对代码库进行雄心勃勃改变的位置。那时,我已经学习了几年关于函数式编程范式的知识,并且我对其优势深信不疑。
Over a few months, I introduced functional concepts to two teams, including mine. For the record, these presentations occurred before I introduced the heavy changes to the codebase.
在几个月的时间里,我向两个团队介绍了一些功能概念,包括我的团队。值得一提的是,在我对代码库进行重大更改之前,这些演示已经进行了。
I thought these training sessions sufficiently convinced people to adopt this new paradigm. And at that moment, it was true: people were nodding their heads. They understood the new concepts, the pros and cons, and what we could use to improve our projects.
我认为这些培训课程已经足够让人们接受这种新的范式。而在那一刻,这是真实的:人们点头表示理解了新的概念,利弊以及我们可以用来改进项目的方法。
At one point, after these presentations, we saw an opportunity:
在这些演示之后的某个时候,我们看到了一个机会:
- It was at the beginning of the summer, so business activity would be quite slow for a couple of months. 这是夏季的开始,所以接下来的几个月里,商业活动会相当缓慢。
- Over the first half of the year, we encountered a few bugs and had to use dirty workarounds in one of our oldest systems. 在上半年,我们遇到了一些问题,并不得不在我们最古老的系统中使用一些不太正规的解决方法。
- We could drastically improve the testability and developer experience of that system, using functional concepts and the types of TypeScript (aka, TS). That old system was initially developed as an early version of TS that did not provide great type features. 我们可以通过使用函数式概念和TypeScript(简称TS)的类型,大幅提高该系统的可测试性和开发者体验。那个旧系统最初是作为一个不提供出色类型特性的早期TS版本开发的。
In other words, it was the perfect time to do some refactoring! I showed a proof of concept to the team, using functional and type-level programming with TS, to greatly improve that system. We were all convinced of its benefits and decided to go further with a production-ready implementation. I was responsible for creating the tasks, planning what could be done in parallel, etc. I posted regular updates to a Slack channel where stakeholders could follow the progress.
换句话说,现在是进行一些重构的绝佳时机!我向团队展示了一个概念验证,使用了TS的函数式和类型级编程,以极大地改进该系统。我们都被其好处所说服,并决定进一步进行一个适合生产环境的实现。我负责创建任务,计划可以并行完成的工作等等。我定期在一个Slack频道上发布更新,利益相关者可以跟踪进展情况。
I developed the v2 of the system as a library within our own codebase, making it an independent module where it was possible to test every possible edge case we could think of, with unit tests since side effects were finally under control. Despite introducing a lot of new concepts, functions, and code changes, everyone was fine with it. I got approvals during code reviews.
我在我们自己的代码库中开发了系统的v2版本,将其作为一个独立的模块,可以测试我们能想到的每一个可能的边缘情况,因为副作用终于得到了控制,所以可以进行单元测试。尽管引入了许多新的概念、函数和代码更改,但大家都对此表示满意。在代码审查中,我得到了批准。
I was heavily inspired by the fp-ts library, which has a way of coding that differs from “regular JavaScript,” some could say. We couldn’t simply import the library in our codebase due to constraints I will not mention here, so I had to reintroduce some of its functions and data types myself, with minor adaptations. I shared more presentations about these changes and got positive feedback.
我受到了fp-ts库的极大启发,它的编码方式与“常规JavaScript”有所不同,有人可能会这样说。由于某些限制,我们无法直接在我们的代码库中导入该库,因此我不得不重新引入其中的一些函数和数据类型,并进行了一些微小的调整。我分享了更多关于这些改变的演示,并得到了积极的反馈。
The lack of opposition led me to continue deeper into the rabbit hole.
缺乏反对意见促使我继续深入兔子洞。
Once the new system was finished and tested, we had to replace the old system that was scattered everywhere in the codebase. It was used in a lot of places, so making the migration from the old system to the new proved to be very tedious.
一旦新系统完成并经过测试,我们就必须替换散布在代码库中的旧系统。它被广泛应用于许多地方,因此从旧系统迁移到新系统被证明是非常繁琐的。
I had never overworked so much in my life. I loved refactoring the old code to what I thought was a better version, so I didn’t count the hours. Over two months, I must have spent around ten hours a day working on it, including weekends.
我这辈子从未如此过劳。我喜欢重构旧代码,将其改进为我认为更好的版本,所以我没有计算过工作时间。在两个月的时间里,我一天可能工作了大约十个小时,包括周末。
Once the work was done, I took two weeks off (they were already planned for a long time). While I was gone, the team was unfortunate to get a quite important incident. They struggled to identify the root cause and to find a fix for it. The issue was located inside the new system, which didn’t look like the rest of the codebase. The team wasn’t familiar with it, as I was pretty much the only one who developed it.
工作完成后,我休了两周假(这段时间早就计划好了)。在我离开期间,团队不幸遇到了一个相当重要的事故。他们努力寻找根本原因并解决问题。问题出现在新系统内部,与其他代码库不太相似。团队对此并不熟悉,因为几乎只有我一个人开发过它。
During my presentations, people understood these new tools and practices and agreed with the changes. But, once they were alone in the middle of all this novelty, they rightfully felt lost.
在我的演示中,人们理解了这些新工具和实践,并同意进行改变。但是,一旦他们独自面对这一切的新奇,他们理所当然地感到迷失。
Presentations are a thing, but if you don’t practice what you just learned, you will eventually forget it. Plus, presenting each concept separately is not the same as using them altogether. It adds complexity to an already-difficult subject to learn.
演示是一回事,但如果你不实践刚学到的知识,最终会忘记它。此外,将每个概念单独呈现并不等同于将它们整体运用。这会给本来就难以学习的主题增加复杂性。
Long story short, I introduced a lot of new concepts to my team, and while they were on board during my presentations, the changes I brought to the project greatly damaged their ability to fix a critical issue while I was gone.
长话短说,我向团队介绍了许多新概念,在我的演示中他们都表示支持,但是在我离开期间,我所带来的变化严重影响了他们解决一个关键问题的能力。
When I got back and learned about this incident, I offered to share more presentations with them so that they could get more familiar with the new code.
当我回来并了解到这件事后,我主动提出与他们分享更多的演示文稿,以便他们能更加熟悉这个新代码。
In reality, I should have never gone down the rabbit hole in the first place. It was not a pragmatic solution. The type improvements were great, but the whole new functional system was a mistake.
事实上,我本不应该一开始就走进兔子洞。这不是一个务实的解决方案。类型的改进很好,但整个新的功能系统是一个错误。
You should not bring important changes to the team just because you are comfortable with these changes. You have to keep the bus factor in mind. I thought I would stay in that team for long enough that everyone would eventually be familiar with the new code, and that I could teach them little by little.
你不应该因为你对这些变化感到舒适而给团队带来重大的变动。你必须牢记公交因素。我原以为我会在这个团队待足够长的时间,以至于每个人最终都会熟悉新的代码,我可以逐渐教给他们。
But, a few months after these events, I joined another team. Looking back, I feel bad for dropping this hard-to-maintain module a few months before leaving them and almost burning myself out because of it.
但是,在这些事件发生几个月后,我加入了另一个团队。回想起来,我为在离开他们前几个月放弃这个难以维护的模块感到内疚,几乎因此而筋疲力尽。
Whether you are an individual contributor (aka IC) or a manager, if a senior teammate introduces important changes like these ones, I strongly advise you to really challenge their proposition. I am sure a better tradeoff could have been found in my case.
无论你是一个个体贡献者(也称为IC)还是一个经理,如果一位资深的团队成员引入了像这样重要的变化,我强烈建议你真正质疑他们的提议。我相信在我的情况下可以找到更好的权衡。
If you are in the same position as I was, I encourage you to think twice before committing. Is this really a pragmatic solution? Are you sure the scope is well defined and rabbit holes well identified? Are you doing this for the good of the team or because you like it? Will the team be comfortable with it when you aren’t around to help them?
如果你处于和我当时一样的位置,我鼓励你三思而后行。这真的是一个务实的解决方案吗?你确定范围已经明确定义,兔子洞已经被识别出来了吗?你是为了团队的利益还是因为你喜欢这样做?当你不在场时,团队会对此感到舒适吗?
Do not let your emotions take over in front of the team
不要在团队面前让情绪控制你
I’ve had moments where I strongly disagreed with whatever a manager or coworker was sharing with the team during a meeting. I let everyone in the room know it bothered me, thus starting a “conflict” publicly.
在开会期间,我曾经有过一些时刻,对于经理或同事在团队中分享的内容强烈持不同意见。我让在场的每个人都知道这让我感到不悦,从而公开引发了一场“冲突”。
I wanted to show my peers it was fine to disagree with someone else’s decision. However, this type of behaviour is not healthy:
我想向同行们展示,与他人的决定意见不同是可以的。然而,这种行为并不健康:
- People may feel uncomfortable when a conflict becomes visible/obvious, like in these situations. It’s not fair to put them into these situations. 当冲突变得明显可见时,人们可能会感到不舒服,就像在这些情况下一样。把他们置于这些情况中是不公平的。
- This may create division within the team, where some agree with person A, and others agree with person B. A team must remain united to be efficient. 这可能会在团队内部造成分裂,一些人支持A,而另一些人支持B。一个团队必须保持团结才能高效运作。
- Generally speaking, it shows some lack of self-control and discipline, and some inability to take a step back and think about the situation. 一般来说,这显示出一些缺乏自控和纪律的问题,以及一些无法退后一步思考情况的能力。
I am not saying that it’s easy to contain our emotions. After all, we are human beings, not machines. But, it is also important to show respect to our peers and avoid disturbing the course of the meeting.
我并不是说控制情绪很容易。毕竟,我们是人类,不是机器。但是,向同事们表达尊重,避免干扰会议的进行也是很重要的。
In my opinion, the right thing to do is to wait for the end of the meeting, then immediately:
在我看来,正确的做法是等待会议结束,然后立即:
- Go talk to the other person in a 1–1 meeting. 去和另一个人进行一对一的会议交谈。
- Talk to your manager about the situation, and find a way to fix it. 与您的经理谈谈这个情况,并找到解决办法。
It is important to trigger this 1–1 immediately after the meeting that made you feel this rush of emotions. The more time passes, the worse the situation gets.
在让你产生强烈情绪的会议结束后立即引发这种一对一的对话非常重要。时间越过,情况就会变得越糟。
In my experience, talking with the other person always helped in improving the situation. Communication is the key here. Without social interactions, we cannot go far in a company (or our personal lives).
根据我的经验,与他人交谈总是有助于改善情况。沟通在这里是关键。没有社交互动,我们在公司(或个人生活)中无法走得太远。
Dip a foot into the hiring market
踏入招聘市场
When I joined the first company as an intern, I had a 30-minute interview with my future manager. And that’s it. I did a quick “culture-fit” interview, and I was accepted.
当我作为实习生加入第一家公司时,我与未来的经理进行了30分钟的面试。就这样。我进行了一次快速的“文化适应性”面试,然后被录用了。
After that, I didn’t set foot on the hiring market for seven and a half years. Once I decided to leave, my single and brief hiring market experience was clearly not representative of what I was about to deal with. The hiring process when you apply for senior positions with approximately eight years of experience is definitely not composed of just a “30-minute behavioural interview.”
之后,我七年半都没有踏足招聘市场。当我决定离开时,我短暂的一次招聘市场经历显然不能代表我即将面对的情况。当你申请具有大约八年经验的高级职位时,招聘过程绝对不仅仅是一个“30分钟的行为面试”。
After reading The Most Heated Tech Job Market in History, I felt I was ready to try it. I updated my LinkedIn profile, then set myself as “open to work.”
阅读完《历史上最热门的科技就业市场》后,我觉得我已经准备好尝试一下了。我更新了我的领英个人资料,然后将自己设为“求职中”。
I felt overwhelmed. Dealing with all the job propositions that rained down on me was exhausting. From September 2021 to the end of October 2021, I must have received 5 to 10 propositions per business day. I had to take PTOs (Personal Time Off) to address the situation, and I spent a significant amount of my weekends dealing with it.
我感到不知所措。应对那些接踵而至的工作提议让我筋疲力尽。从2021年9月到10月底,我每个工作日可能收到5到10个提议。我不得不请假来处理这种情况,而且我在周末花了大量时间来处理。
Initially, I was able to answer every recruiter's message. But, when I was in a situation where:
起初,我能够回复每一位招聘人员的信息。但是,当我处于以下情况时:
- I had to work all day, as I was still employed at my current company at that time. 那时候我还在现在的公司工作,所以整天都得工作。
- I was in the middle of moving to another city, which was quite stressful for me. 我正在搬家去另一个城市,这对我来说相当有压力。
- I was engaged in the hiring process of several companies. 我参与了几家公司的招聘过程。
- I kept receiving new job propositions. 我不断收到新的工作提议。
It became increasingly hard to answer all of the new messages from recruiters.
回复所有来自招聘人员的新消息变得越来越困难。
I ended up writing my own message template containing my wishes for the next job. I shared as many details as I could: size of the company, engineering culture, remote work, compensation, technical challenges, and so on. But despite this, I couldn’t keep up with all the messages.
我最后写了一份自己的信息模板,包含了我对下一份工作的期望。我尽可能地分享了许多细节:公司规模、工程文化、远程工作、薪酬、技术挑战等等。但尽管如此,我还是无法跟上所有的信息。
To all the recruiters that contacted me at that time, and to whom I never got the chance to answer, I am sorry. I was overwhelmed by the situation.
对那时联系过我的所有招聘人员,以及我从未有机会回复的人,我很抱歉。当时的情况让我感到不知所措。
But dealing with LinkedIn messages was not the most difficult part of it. The most exhausting part was actually doing the interviews. I never got the chance to train DSA (Data Structures and Algorithms) before, as I never felt the need to change companies.
但是处理LinkedIn的消息并不是最困难的部分。最令人疲惫的部分实际上是进行面试。我以前从未有机会培训DSA(数据结构和算法),因为我从未觉得有必要换公司。
I trained mainly on leetcode, and I also bought a few books to help me:
我主要在LeetCode上进行训练,还买了几本书来帮助我:
- Cracking the Coding Interview by Gayle Laakmann McDowell. 《破解程序员面试》(作者:Gayle Laakmann McDowell)
- System Design Interview Volume 1 by Alex Xu. 《系统设计面试指南 第一卷》作者:Alex Xu.
In addition, I had to remember and present some of the most impactful projects I worked on in detail. This is where the work log we mentioned previously could be a very interesting asset.
此外,我还需要详细回忆和展示我参与的一些最具影响力的项目。这就是我们之前提到的工作日志可能成为一个非常有趣的资产的地方。
Once I finally accepted an offer, I handed the resignation to my manager. If I remember correctly, I got a +25% base salary increase with this new offer. There was some additional compensation included and overall better employee benefits for my situation (working remotely).
当我最终接受了一个工作机会后,我递交了辞职信给我的经理。如果我没记错的话,这个新的工作机会给了我一个基本工资增加了25%。除此之外,还有一些额外的补偿和更好的员工福利,适合我目前的情况(远程工作)。
The reason why I encourage you to try interviewing from time to time is for this:
我鼓励你不时尝试面试的原因是这样的:
- You will get some experience along the way, so when you finally join a new company, you will feel less overwhelmed. 在这个过程中,你会获得一些经验,所以当你最终加入一家新公司时,你会感到不那么压力山大。
- You can check your worth on the market and potentially ask for some compensation adjustments at your current company. If you can get a job offer, chances are it will help you get what you think you deserve at your current position. 你可以在市场上评估自己的价值,并有可能要求当前公司进行一些薪酬调整。如果你能获得一份工作机会,很有可能能帮助你在当前职位上得到你认为应得的待遇。
At my first company, I got good salary raises (between 7% and 10% year-on-year), except for the last year. Despite not being satisfied with the one I got in the last year, I thought I would have gotten an even better raise the next year anyway. That moment never came as I quit before it happened.
在我第一家公司,我得到了不错的薪资涨幅(年均在7%至10%之间),除了最后一年。尽管对最后一年的涨幅不满意,但我还是认为下一年会得到更好的涨幅。然而,在那一刻之前,我已经辞职了,所以这个机会从未到来。
Since I got good raises for most of my career at that company, I never felt like checking what I was worth in the hiring market. I wish I had done that earlier. That doesn’t necessarily mean I would have left the company earlier, but at least I would have gotten some experience, and I could have possibly asked for a salary adjustment instead of a raise.
由于我在那家公司的大部分职业生涯中都得到了不错的加薪,我从未觉得有必要去了解自己在招聘市场上的价值。我希望我早点这样做。这并不一定意味着我会早些离开公司,但至少我会获得一些经验,可能还可以要求薪资调整而不是加薪。
Don’t get me wrong: getting a 10% raise is great. But if your salary is 15% to 20% below what the market tells you you are worth, in the end, that 10% raise isn’t good enough. And how can you know if you have the compensation you deserve? By experiencing that market yourself. Also, by staying in touch with former coworkers that experienced the market themselves.
别误会我的意思:获得10%的加薪是很不错的。但是如果你的薪水比市场价值低15%到20%,那么最终,这10%的加薪就不够好了。你如何知道自己是否得到了应有的补偿?通过亲身体验市场。此外,与曾经亲身体验市场的前同事保持联系也是一种方法。
Doing interviews doesn’t force you to leave the company. You can do tens of interviews while staying at your current company, as long as you don’t sacrifice your work for doing interviews. This is why I had to take PTOs, and I had to do interviews early in the morning and during lunch breaks.
参加面试并不意味着你必须离开公司。只要你不为了面试而牺牲工作,你可以在现任公司的同时进行数十次面试。这就是为什么我不得不请假,并且不得不在早晨和午餐时间进行面试。
End Thoughts 结束思考
First of all, thank you for reading so far! I hope this article was useful to you. I think you noticed all this advice is not really technical. Most of them are about soft skills. Maybe I’ll write another article with advice that is more about technical skills or hard skills. Let me know if you would be interested in such content.
首先,非常感谢您一直阅读到这里!希望这篇文章对您有所帮助。我想您已经注意到,这些建议并不是非常技术性的。其中大部分都是关于软技能的。也许我会写另一篇更多关于技术技能或硬技能的建议的文章。如果您对这样的内容感兴趣,请告诉我。
One last thing I wanted to share with you: stay in touch with some of your former coworkers, especially those who inspired you. They are people you admired because they did a great job according to your standards. They may have been excellent managers or influential technical leaders that you really appreciated. This is important because they will help you improve and become a better developer. They may even convince you to join their company/team, which is healthy as long as the frequency is reasonable. Everyone should build a network that helps them become better people.
还有一件事我想和你分享:与一些以前的同事保持联系,尤其是那些给你带来灵感的人。他们是你钦佩的人,因为他们按照你的标准做得很出色。他们可能是优秀的经理或有影响力的技术领导者,你非常欣赏他们。这很重要,因为他们会帮助你进步,成为一个更好的开发者。他们甚至可能说服你加入他们的公司/团队,只要频率合理,这是有益的。每个人都应该建立一个能帮助他们成为更好的人的人际网络。