diff --git a/sources/talk/20230227.1 ⭐️⭐️ Essential tips and tricks for your first tech job.md b/sources/talk/20230227.1 ⭐️⭐️ Essential tips and tricks for your first tech job.md
deleted file mode 100644
index a7a9f31537..0000000000
--- a/sources/talk/20230227.1 ⭐️⭐️ Essential tips and tricks for your first tech job.md	
+++ /dev/null
@@ -1,146 +0,0 @@
-[#]: subject: "Essential tips and tricks for your first tech job"
-[#]: via: "https://opensource.com/article/23/2/your-first-tech-job"
-[#]: author: "Fatima https://opensource.com/users/ftaj"
-[#]: collector: "lkxed"
-[#]: translator: "XiaotingHuang22"
-[#]: reviewer: " "
-[#]: publisher: " "
-[#]: url: " "
-
-Essential tips and tricks for your first tech job
-======
-
-First days at work are scary. I still recall many instances where I lay awake at night before my first day at work, having an internal meltdown over what would happen the next day. Starting a new job is uncharted territory for most people. Even if you're a veteran in the industry, there's no denying that there can be a part of you that's a bit terrified of what is to come.
-
-Understandably, a lot is happening. There are new people to meet, new projects and technologies to understand, documentation to read, tutorials to sit through, and endless HR presentations and paperwork to fill out. This can be overwhelming and, coupled with the considerable degree of uncertainty and unknowns you're dealing with, can be quite anxiety-inducing.
-
-Two reasons motivated me to write about this subject. The first one being that back when I was a student, most of the discussion revolved around getting a job in tech, and no one talked about what happened next. How do you excel in your new role? Now that I look back, I think I assumed that the hard part is getting the job, and whatever comes after, I could probably figure out myself.
-
-Similarly, once I started working in the industry, most of the career-related content I came across was about how to go from one senior level to another. No one really talked about what to do in the middle. What about the interns and the junior engineers? How do they navigate their early careers?
-
-After completing three years of full-time professional experience as a software engineer (and a couple of internships before), I reflected on my time. I put together a list of tips and tricks I've employed while settling into a new tech role. I wanted to look beyond just the first couple of months and prioritize helping achieve long-term success.
-
-### Reflect on existing processes and documentation
-
-Most new employees start by either having a ton of documentation thrown their way or none at all. Instead of being overwhelmed by either of these possibilities, you could view this as an opportunity.
-
-Identify gaps in existing documentation and think about how you could improve it for the next engineer that gets onboarded. This not only shows initiative on your part but also demonstrates that you're committed to improving existing processes within your team.
-
-I've seen both ends of the spectrum. I've been on teams with no documentation whatsoever. I've also been on teams that were very diligent with keeping their documentation up to date. Your path is pretty straightforward with the former, and you can work on creating that missing documentation. With the latter, you can always think of ways to improve what already exists. Sometimes, too much documentation in written form can also feel intimidating, especially for new employees. Some things might be better explained through other mediums, like video tutorials or screencasts.
-
-### Ask questions
-
-I encourage you to look into whether a buddy will be assigned to you when you're starting. This is a fairly common practice at companies. The purpose of a buddy is to help you as you are onboarded. I've found this incredibly helpful because it gives you someone to direct all your questions, and you don't have to run around trying to find the right person/team.
-
-While asking questions should always be encouraged, it is also necessary to do your homework before you ask those questions, including:
-
-- Do your research. This encompasses doing a web search, checking forums, and reading existing documentation. Use all the available tools at your disposal. However, it is essential to timebox yourself. You must balance doing your due diligence and keeping project deadlines and deliverables in mind.
-- Talk it out. As someone whose first language isn't English, I recommend talking things out loud before asking questions. In my experience, I've often found that, especially when I'm struggling with something difficult, I think in one language (probably my native language) and must explain it in another. This can be a bit challenging sometimes because doing that translation might not be straightforward.
-- Organize your thoughts. When struggling with something, it's very common to have many scrambled ideas that make sense to us but might not necessarily make sense to another person. I suggest sitting down, gathering your thoughts, writing them down, and talking through them out loud. This practice ensures that when you're explaining your thought process, it flows as intended, and the listener can follow your train of thought.
-
-This approach is called the rubber duck technique, a common practice developers use while debugging. The concept is that sometimes explaining your problem to a third person can be very helpful in getting to the solution. This is also a testament to your excellent communication skills.
-
-Respect people's time. Even if you're reaching out to someone like your buddy, be cognizant of the fact that they also have their day-to-day tasks to complete. Some things that I've tried out include the following:
-
-- Write down my questions and then set aside some time with my mentor so I could talk to them.
-- Compile questions instead of repeatedly asking for help so your mentor can get to them when they have time.
-- Schedule a quick 15-20 min video chat, especially if you want to share your screen, which is a great way to showcase your findings.
-
-I think these approaches are better because you get someone's undivided attention instead of bothering them every couple of minutes when their attention might be elsewhere.
-
-### Deep dive into your projects
-
-Even on teams with excellent documentation, starting your technical projects can be very daunting since multiple components are involved. Over time though, you will understand how your team does things. However, it can save you time and potential headaches to figure this out early on by keeping a handy list to refer to, including basic project setup, testing requirements, review and deployment processes, task tracking, and documentation.
-
-If there's no documentation for the project you're starting on (a situation I have been in), see if you can identify the current or previous project owner and understand the basic project structure. This includes setting it up, deploying it, etc.
-
-- Identify your team's preference in the IDE (integrated development environment). You're free to use the IDE of your choice, but using the same one as your team can help, especially when debugging, since the choice of IDE impacts debugging. Different IDEs offer varying degrees of debugging support.
-- Understand how to do debugging, and I don't just mean using print statements (not that there's anything wrong with that approach). Leverage your team's experience here!
-- Understand testing requirements. This might depend on the scope of your project and general team practices, but the earlier you figure this out, the more confident you'll be in the changes you push to production.
-- Visualize the deployment process. This process can vary by team, company, etc. Regardless of how informal or formal it may be, make sure you understand how your changes get deployed to production, what the deployment pipeline looks like, how to deploy changes safely, what to do in case of failed builds, how to rollback faulty changes, and how to test your changes in production.
-- Understand the ticketing process. Understand how to document tickets and the level of detail expected. You will see a lot of variation here. Some companies expected us to submit our tickets daily, showing our progress. Other companies might not require that level of documentation.
-
-Given everything I just mentioned, a beneficial, all-in-one exercise you can do in the first couple of weeks is to shadow another engineer and do peer coding sessions. This allows you to observe the entire process, end to end, from the moment a ticket is assigned to an engineer to when it gets deployed to production.
-
-The first couple weeks can also feel frustrating if you're not yet given an opportunity to get your hands dirty. To counter this, ask your manager to assign some starter tickets to you. These are usually minor tasks like code cleanup or adding unit tests. Still, they allow you to tinker with the codebase, which helps improve your understanding and gives you a sense of accomplishment, which is a very encouraging feeling in the early days of a new job.
-
-### Speak up, especially when you're stuck
-
-I want to stress the importance of communication when you're stuck. This happens, especially in the early months of a new job, and as frustrating as it can be, this is where your communication skills will shine.
-
-- Be transparent about blockers and your progress. Even if it's something as trivial as permission issues (a fairly common blocker for new employees), ensure that your manager is aware.
-- Don't wait until the last day to report if something will be delayed. Delays in your project push many other things forward. Share necessary project delays well in advance, so your manager can share this with stakeholders.
-- Don't forget things like thoroughly testing your changes or documenting your code just because you're in a rush.
-
-### Gain technical context
-
-Gaining technical context is something I've personally struggled with, and I've actively worked on changing my approach in this area.
-
-When I started as an intern, I would go in with a very focused mindset regarding what I wanted to learn. I'd have a laser-sharp focus on my project, but I'd completely turn a blind eye to everything else. Over the years, I realized that turning a blind eye to other or adjacent projects might not be the wisest decision.
-
-First and foremost, it impacts your understanding of your work. I was naive to think I could be a good engineer if I focused exclusively on my project. That's just not true. You should take the time to understand other services with which your project might interact. You don't need to get into the nitty gritty, but developing a basic understanding goes a long way.
-
-A common experience that new employees undergo is disconnecting from the rest of the company, which is a very natural feeling, especially at larger companies. I'm someone who develops a sense of exclusion very quickly, so when I moved to Yelp, a significantly larger company than my previous one, with projects of a much larger scale, I prioritized understanding the big picture. Not only did I work on developing an understanding of my project but also of other adjacent projects.
-
-In my first few weeks at Yelp, I sat down with various engineers on my team and asked them to give me a bird's eye view of what I would be doing and the project's overarching goal. This approach was incredibly helpful because not only did I get varying degrees of explanations based on how senior the engineer was and how long they had been working on the project, but it also deepened my understanding of what I would be working on. I went into these meetings with the goal that my knowledge of the project should allow me to explain what I do to a stranger on the street. To this end, I asked my tech lead to clarify at what point my work came into the picture when a user opened the Yelp app and searched for something.
-
-Architecture diagrams can also help in this scenario, especially when understanding how different services interact.
-
-### Establish expectations
-
-For the longest time, I thought that all I needed to do was my best and be a good employee. If I was doing work, meeting goals, and no one complained, that should be good enough, right? Wrong.
-
-You must be strategic with your career. You can't just outsource it to people's goodwill and hope you'll get the desired results just because you're meeting expectations.
-
-- Establish clear criteria the moment you start your new job. This varies by company, as some organizations have very well-defined measures while others might barely have any. If it's the latter, I suggest you sit down with your manager within the first couple of weeks and establish and unanimously agree on a criterion.
-- Make sure you thoroughly understand how you will be evaluated and what measures are used.
-
-I remember walking out of my first evaluation very confused in my first full-time role. The whole conversation had been very vague and hand-wavy, and I had no clarity about my strengths, weaknesses, or even steps to improve.
-
-At first, it was easy to attribute everything to my manager because the new employee in me thought this was their job, not mine. But over time, I realized that I couldn't just take a backseat as far as my performance evaluations were concerned. You can't just do good work and expect it to be enough. You have to actively take part in these conversations. You have to make sure that your effort and contributions are being noticed. From regularly contributing to technical design conversations to setting up socials for your team, ensure that your work is acknowledged.
-
-Tying into establishing expectations is also the importance of actively seeking feedback. Don't wait until your formal performance evaluations every three or four months to find out how you're doing. Actively set up a feedback loop with your manager. Try to have regular conversations where you're seeking feedback, as scary as that may be.
-
-### Navigate working in distributed teams
-
-The workplace has evolved over the past two years, and working in remote and distributed teams is now the norm instead of a rarity. I've listed some tips to help you navigate working in distributed teams:
-
-- When starting meetings, exchange pleasantries and ask people how their weekend/day has been. This helps break the ice and enables you to build a more personal connection with your team members, which goes beyond work.
-- Suggest an informal virtual gathering periodically for some casual chit-chat with the team.
-
-- Establish core hours and set these on your calendar. These are a set of hours that your team will unanimously agree upon, and the understanding is that everyone should be online and responsive during these hours. This is also convenient because meetings only get scheduled within these hours, making it much easier to plan your day.
-- Be mindful of people's time zones and lunch hours.
-- In the virtual world, you need to make a greater effort to maintain social interactions, and little gestures can go a long way in helping make the work environment much friendlier. These include the following:
-
-### Maintain a work-life balance
-
-At the beginning of your career, it's easy to think that it's all about putting in those hours, especially given the 'hustle culture' narrative that we're fed 24/7 and the idea that a work-life balance is established in the later stages of our careers. This idea couldn't be further from the truth because a work-life balance isn't just magically going to occur for you. You need to actively and very diligently work on it.
-
-The scary thing about not having a work-life balance is that it slowly creeps up on you. It starts with you checking emails after hours and then slowly makes its way to you, working over weekends and feeling perpetually exhausted.
-
-**[ Related read [How I recognize and prevent burnout in open source][1] ]**
-
-I've listed some tips to help you avoid this situation:
-
-- Turn off/pause notifications and emails and set yourself to offline.
-- Do not work weekends. It starts with you working one weekend, and the next thing you know, you're working most weekends. Whatever it is, it can wait until Monday.
-- If you're an on-call engineer, understand your company's policies surrounding that. Some companies offer monetary compensation, while others may give time off in lieu. Use this time. Not using your benefits like PTO (paid time off) and wellness days really shortens your longevity at work.
-
-### Wrap up
-
-There's no doubt that starting a new job is stressful and difficult. I hope that these tips and tricks will make your first few months easier and set you up for great success with your new position. Remember to communicate, establish your career goals, take initiative, and use the company's tools effectively. I know you'll do great!
-
---------------------------------------------------------------------------------
-
-via: https://opensource.com/article/23/2/your-first-tech-job
-
-作者：[Fatima][a]
-选题：[lkxed][b]
-译者：[XiaotingHuang22](https://github.com/XiaotingHuang22)
-校对：[校对者ID](https://github.com/校对者ID)
-
-本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
-
-[a]: https://opensource.com/users/ftaj
-[b]: https://github.com/lkxed/
-[1]: https://opensource.com/article/21/5/open-source-burnout
diff --git a/translated/talk/20230227.1 ⭐️⭐️ Essential tips and tricks for your first tech job.md b/translated/talk/20230227.1 ⭐️⭐️ Essential tips and tricks for your first tech job.md
new file mode 100644
index 0000000000..558384ded5
--- /dev/null
+++ b/translated/talk/20230227.1 ⭐️⭐️ Essential tips and tricks for your first tech job.md	
@@ -0,0 +1,151 @@
+[#]: subject: "Essential tips and tricks for your first tech job"
+[#]: via: "https://opensource.com/article/23/2/your-first-tech-job"
+[#]: author: "Fatima https://opensource.com/users/ftaj"
+[#]: collector: "lkxed"
+[#]: translator: "XiaotingHuang22"
+[#]: reviewer: " "
+[#]: publisher: " "
+[#]: url: " "
+
+Essential tips and tricks for your first tech job 技术领域小白必不可少的工作技巧和诀窍
+======
+
+刚刚入职那几天确实令人害怕。 我现在依然可以清晰举出很多例子，例如在第一天上班前的晚上无法入睡，因为不知道第二天将要发生什么而内心崩溃。 对于大多数人来说，开始一份新工作就像踏入未知领域。 即使你已是行业的资深人士，不可否认的是，你内心可能还是会对即将发生的事情感到有点害怕。
+
+可以理解的是，刚入职的时候你的事情很多。 你要认识新的人，有新的项目和技术要了解，有文档要阅读，有教程要看完，还有没完没了的人事谈话和文件要填。 这可能让你感觉压力山大，再加上你还面临着相当大程度的不确定性和未知数，以上种种能引起焦虑。
+
+促使我写这篇文章有两个原因， 首先是在我还是学生的时候，大部分讨论都围绕着如何找一份技术工作，却没有人谈论接下来发生的事情。 如何在新角色中脱颖而出？ 现在回过头来看，我想我当时认为最困难的事情是得到一份工作，之后发生什么的一切我都可以自己弄清楚。
+
+同样的，在我开始在这个行业工作之后，我发现大部分我看到的与职业相关的内容都是讨论如何从一个高级别升到另一个高级级别职称。 没有人真正谈论在此中间我们要做什么。 实习生和初级工程师呢？ 他们在早期职业生涯中如何找到方向？
+
+在拥有了三年全职软件工程师的经验（以及之前的几次实习）之后，我将这段时间的经历进行了复盘并整理出一份我自己在适应新技术职位时使用过的技巧和诀窍表格。我想不只局限于前面的几个月，而是优先考虑如何让这段经历帮助你实现长期的成功。
+
+
+### 从现有的流程和文档着手学习
+
+大多数新员工一开始要么拥有一大堆文档，要么根本没有。 你可以将这视为一个机会，而不是被这两种可能性中的任何一种所淹没。
+
+从现有文档中找到缺口，并想想你可以怎样为下一位入职的工程师做出这方面的改进。 这不仅能显示你工作的主动性，还表明你致力于改进团队中的现有流程。
+
+上述两种极端情况我都遇到过。我在没有任何文件的团队中工作过，也在一些更新文档方面很勤快的团队中工作过。 对于前者，你的路径非常简单直接，你可以致力于创建那些缺失的文档。 对于后者，您总是可以想办法改进已经存在的东西。 有时，过多的书面文件也会让人感到害怕，尤其是对新员工而言。 有些事情可能通过其他媒介进行更好地解释，比如视频教程或截屏视频。
+
+### 勤问问题
+
+我会建议你在开始一份新工作时研究一下公司是否会为你分配搭档。 这在公司中是相当普遍的做法。 工作搭档的主要作用是在你入职时为你提供帮助。 我发现这非常有用，因为这个人能够针对你所有的问题给出指导，你就不必为了寻找合适的人或部门而四处奔波。
+
+虽然我鼓励提问，但在提问之前也有必要做功课，包括：
+
+- 做好调查。 这包括进行网络搜索、查看论坛和阅读现有文档。 使用所有可用的工具。 然而，给自己设定时间规划是很重要的。 你必须平衡好尽职调查与牢记手头项目截止日期和可交付成果。
+- 说出来。 作为母语不是英语的人，我建议你在提问之前大声把想法说出来。 根据我的经验，我经常发现自己会用一种语言（通常是我的母语）思考但不得不用另一种语言来解释，而当我在一些困难的问题中挣扎时这一现象尤为突出。有时这颇有挑战性，因为经过翻译后的想法可能没那么容易理解。
+- 组织思绪。 当你在为某件事而苦苦挣扎时，可能同时有很多不同的想法在你的脑海中翻来覆去。这些想法可能对你来说都挺有道理的，但对于别人来说却不一定说得通。对此，我建议你坐下来，收集你的想法，写下来，然后大声说出来。 这一做法可确保当你在解释自己的思维过程时，你能按照预期进行流畅地表达出来，听众也可以紧跟你的思路。
+
+
+这种方法称为橡皮鸭调试法，是开发人员在调试时的常见做法。 背后的概念是，有时向第三方解释你的问题非常有助于你找到解决方案，同时也证明了你出色的沟通技巧。
+
+尊重别人的时间。 即使你在向你的搭档求助时，也要意识到他们也有自己的日常任务要完成。 我尝试过的一些事情包括：
+
+
+- 写下我的问题，然后留出一些时间与我的导师交流，以便与他们交谈。
+- 整理问题而不是反复寻求帮助，这样导师可以在他们有空的时候着手解决。
+- 安排 15-20 分钟的快速视频聊天，特别是如果你想共享屏幕，这一方法可以很好地展示你的发现。
+
+我认为这些方法是更好的选择，因为这么做你能得到对方全部的关注，而不是在他们忙着其他事情的时候每隔几分钟打扰他们一下。
+
+### 深入研究你的项目
+
+即使在拥有出色文档的团队中，开始你的技术项目也可能非常艰巨，因为一个项目涉及多个部分。 不过，随着时间的推移，你将了解团队是如何做事的。 但是，通过记下一张包括基本项目设置、测试要求、审查和部署流程、任务跟踪和文档的实用清单，你将迅速搞清楚一切，节省了你的时间和潜在的麻烦。
+
+如果你开始的项目没有文档（我就遇到过这种情况），请看看你能不能找到当前或以前的项目所有者并了解基本的项目结构，这包括设置、部署等。
+
+- 确定你的团队在 IDE（集成开发环境）中的偏好。 你可以自由使用你喜欢的 IDE，但使用和团队相同的 IDE 会比较好，尤其是在调试的时候，因为 IDE 的选择会影响调试。 不同的 IDE 提供不同程度的调试支持。
+- 了解如何进行调试，我的意思不仅仅是使用打印语句（不是说这种方法有什么问题）。 充分利用团队的经验！
+- 了解测试要求。 这可能取决于项目的范围和团队的一般惯例，越早弄清楚要求，你在后期推送自己的修改请求时就会越有信心。
+- 可视化部署过程。 这个过程可能因团队、公司等而异。无论这个过程是非正式或正式，请确保你了解自己提交的新代码是如何被部署至新环境中、部署流水线是什么样的、如何安全地部署代码更改、在构建失败后可以怎么做，如何回滚错误的更改，以及如何在生产环境中测试你的更改。
+- 了解报修流程。 了解如何记录报修以及要求的详细程度。 你会由此发现每个公司各不相同。 有的公司希望我们每天提交报修单以显示我们的进度。 有的公司可能不需要如此详细的文档。
+
+基于我刚才提到的所有内容，我建议你可以在入职头几周内做一个有益的、一体化的练习——跟随模仿另一位工程师并进行同行编码。 这么做让你可以端到端地观察整个流程，从派单给工程师到部署到生产中都清清楚楚。
+
+如果刚入职几周时你还没有机会亲身实践，可能你会感到沮丧。 为了解决这个问题，你可以让你的经理也给你派一些单子。 这些通常是一些小任务，例如代码清理或添加单元测试。 不过，它们允许你修补代码库，这有助于提高你的理解并给你带来成就感，这在新工作的初期是非常鼓舞人心的。
+
+### 当你遇到困难时尤其要大声说出来
+
+我想强调一下当你碰到困难时沟通的重要性。 遇到困难总是难免的，尤其是在一份新工作的最初几个月，尽管这可能会令人沮丧，但这正是你的沟通技巧大放异彩的地方。
+
+- 让工作中的阻碍和进步透明化。 即使是像权限问题一样微不足道（新员工常常遇到的障碍之一），也要确保你的经理知道。
+- 如果有些工作耽搁了，不要等到最后一天才向团队报告。 你的项目延迟会推动许多其他事情的发展。 对于一些必要的项目延迟请提前告知，以便你的经理可以与相关人员分享这一信息。
+- 不要因为匆忙而忘记全面测试代码的更改或记录你的代码等事情。
+
+### 获得技术大局观
+
+获得技术大局观是我个人一直在努力改进的地方，并且我一直在积极改变自己对此的看法。
+
+当年我开始实习时，我会非常专注于自己想学的东西。 我会非常专注于我的项目，但对其他一切完全视而不见。 多年后，我意识到对其他或相邻的项目视而不见可能不是最明智的。
+
+首先，技术大局观会影响你对自身工作的理解。 我曾经天真地以为，只要我专注于自己的项目就可以成为一名优秀的工程师。但事情并非如此。你应该花时间了解其他可能与你的项目有所交互的服务。 你无需深入了解细节，但建立基本的理解也会大有帮助。
+
+新员工的一个普遍经历是与公司其他人脱节，会有这种感觉很正常，尤其是在大公司。 我是一个很快就会产生排斥感的人，所以当我刚到 Yelp 时 —— 这是一家比我以前的公司大得多的公司，项目规模也大得多，我优先考虑了解大局。 我不仅努力建立对我的项目的理解，还认真了解了其他相邻项目。
+
+在 Yelp 的头几周，我与团队中的不同工程师坐下来，请他们给我一个关于我将要做什么和项目的总体目标的概况。 这种方法非常有用，因为我不仅根据工程师的资历和他们在项目上的工作时间得到了不同程度的解释，而且还加深了我对我将要从事的工作的理解。 我参加这些会议的目的，是希望我对项目掌握的认识让我能够向街上的陌生人解释我所做的事。为此，我还请我的技术主管向我解释，当用户打开 Yelp 应用程序并搜索内容时，我的工作成果会在什么时候出现。
+
+在这种情况下架构图也很有用，尤其是它能帮助你了解不同服务是如何交互的。
+
+### 建立期望
+
+在过去很长一段时间里，我以为自己只需要尽力而为，成为一名优秀的员工。 只要我有在工作，达成目标，而且没有人投诉，那就足够好了，对吧？ 错！
+
+你必须对你的职业有战略眼光。 你不能只是将它外包给人们的一片好心，并希望自己只要达成了目标就能得到想要的结果。
+
+- 在你开始新工作的那一刻就建立明确的标准。 这因公司而异，因为有些组织有非常明确的措施，而其他组织可能几乎没有。 如果是后者，我建议你在头几周内找你的经理坐下来谈谈，制定并统一一个标准。
+- 确保你彻底了解公司将如何评估你以及采用什么方法进行评估。
+
+我记得在我的第一份全职工作中，我对自己的第一次评估会议一头雾水。 整个谈话非常含糊不清，而且我对自己的长处、短处甚至可以如何改进都一无所知。
+
+起初，我很容易地将一切都归咎于我的经理，因为作为新员工的我认为这是他们的工作，而不是我的职责。 但随着时间的推移，我意识到，就我的绩效评估而言，我不能只是退居二线。 你不能只做好工作并期望它就足够了。 你必须积极参与到这些对话中。 你必须确保你的努力和贡献被注意到。 为了确保你的工作得到认可，你可以做很多事情，从定期参与技术设计对话到设置团建活动。
+
+建立期望也是积极寻求反馈，这一点也十分重要。不要等到每三四个月进行一次正式的绩效评估时才知道自己的表现如何。 积极与你的经理建立反馈循环。 虽然这听起来很可怕，但尝试定期进行寻求反馈的谈话。
+
+### 在分布式团队中找到方向
+
+在过去两年中我们的工作场所在不断变化，如今在远程和分布式团队中工作已成为常态，不再罕见。 我列出了一些技巧，帮助你在分布式团队中快速找到工作方向：
+
+- 开始会议时，互相寒暄并询问人们周末/一天过得如何。 这有助于打破僵局，让你能够与团队成员建立更私人的、超越工作的联系。
+- 建议定期举行非正式的虚拟聚会，与团队进行一些随意的闲聊。
+
+
+- 建立核心时间并将其设置在你的日历上。 核心时间是你的团队一致同意的几个小时，在这段时间里，大家都明白自己应该在线并能随时响应。 这样做很方便，因为会议只会安排在这个时间段，让你在计划自己一天的工作时更轻松。
+- 注意人们的时区和午餐时间。
+- 在虚拟世界中，您需要付出更大的努力来维持社交互动，而小小的心意却可以大大有助于让工作环境更加友好。 其中包括：
+
+### 维持工作生活间的平衡
+
+在你职业生涯刚开始的时候，你很容易认为只要投入很多时间就能成功，特别是考虑到我们全天候待命的“忙碌文化”以及认为建立生活工作的平衡是在职业生涯下阶段才需要考虑的想法。但这些想法与事实相去甚远，因为工作与生活的平衡不会神奇地发生在你身上。 你需要积极和非常勤奋地去找到个人的平衡点。
+
+没有工作与生活平衡的可怕之处在于它是慢慢蔓延到你身上的。 刚开始是你下班后还在查看电子邮件，然后慢慢地，你开始周末也在工作，一直感到疲惫不堪。
+
+**[ 相关阅读 [我是如何识别并防止自己在开源项目中感到倦怠的][1] ]**
+
+
+我列出了一些提示，可以帮助你避免这种情况：
+
+- 关闭/暂停通知和电子邮件并将自己设置为离线。
+- 不要在周末工作。 刚开始是你需要在这一个周末工作，但不知不觉间，你会发现自己大部分周末都在工作。 不管是什么工作，它可以等到星期一。
+- 如果你是随叫随到的工程师，请了解公司的相关政策。 一些公司提供金钱补偿，而另一些公司可能会以休假代替。 利用这个时间。 不使用 PTO（带薪休假）和健康日等福利确实会缩短你的工作寿命。
+
+### 总结
+
+毫无疑问，开始一份新工作压力很大而且很困难。 我希望这些方法和技巧会让你的头几个月变得更轻松，并为你在新职位上取得巨大成功做好准备。 记住，勤沟通，确立职业目标，积极主动，有效地使用公司的工具。 做到这些，我相信你会做得很好！
+
+--------------------------------------------------------------------------------
+
+via: https://opensource.com/article/23/2/your-first-tech-job
+
+作者：[Fatima][a]
+选题：[lkxed][b]
+译者：[XiaotingHuang22](https://github.com/XiaotingHuang22)
+校对：[校对者ID](https://github.com/校对者ID)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
+
+[a]: https://opensource.com/users/ftaj
+[b]: https://github.com/lkxed/
+[1]: https://opensource.com/article/21/5/open-source-burnout