如何成为软件工程师的团队合作者

In my first software engineering role at an eCommerce brand, I often secretly worked on tasks outside of my core responsibilities. And many times I felt isolated from my teammates.

在电子商务品牌的第一个软件工程职位中，我经常秘密地从事核心职责以外的任务。 很多时候，我感到与队友隔绝。

Therefore, when I was invited to participate in a project-based course to better my communication skills, I jumped at the opportunity.

因此，当我被邀请参加一个基于项目的课程以提高我的沟通技巧时，我抓住了这个机会。

For the program, I was assigned to a team with two other engineers and a team lead to build a full stack application using React, Python, and Flask. Now that the course is over, I thought I'd share the lessons I learned about how to be a better team player.

对于该程序，我被分配了一个由其他两名工程师组成的团队，一个团队负责人使用React，Python和Flask构建了一个完整的堆栈应用程序。 既然课程结束了，我想我应该分享从中学到的如何成为更好的团队合作者的经验教训。

第1课：不要低估项目的潜在难度 (Lesson 1: Do not underestimate a project’s potential difficulty level)

Since the course was meant for entry-level engineers, I figured I would have a leg up as I already had some professional Node.js experience. Granted, our tech stack would be using a Python Flask backend, but I figured Python and Flask would not be too hard to pick up.

由于该课程是为入门级工程师准备的，因此我认为我已经有了一定的经验，因为我已经拥有一些专业的Node.js经验。 当然，我们的技术堆栈将使用Python Flask后端，但我认为Python和Flask不会太难。

On the first day of our project, we were shown what we would be building. Wow, I suddenly felt very unprepared. Our project was significantly more challenging than I had expected.

在项目的第一天，向我们展示了我们将要构建的内容。 哇，我突然感到非常准备不足。 我们的项目比我预期的要困难得多。

My other two teammates seemed to pick up the material easily. At the end of our first week I was our team’s least contributing member.

我的另外两个队友似乎很容易拿起材料。 在第一周结束时，我是我们团队贡献最少的成员。

I knew React quite well, so our front end was not too difficult for me. But our backend was using PostgresSQL and Python, neither of which I knew well. It quickly became clear that the tasks expected of us would be particularly challenging for someone with little Python experience.

我非常了解React，所以我们的前端对我来说并不困难。 但是我们的后端使用的是PostgresSQL和Python，我都不熟悉。 很快就变得很清楚，对于那些没有Python经验的人来说，我们期望的任务将特别具有挑战性。

第2课：请求反馈正在进行的工作 (Lesson 2: Request feedback on work in progress)

Initially, I often found myself wasting time doing unnecessary work. For instance, one time I was creating an editable user profile form, not realizing that my teammate was in the middle of building a reusable Material UI dialog component that I could have used.

最初，我经常发现自己浪费时间做不必要的工作。 例如，有一次我创建了一个可编辑的用户个人资料表单，却没有意识到我的队友正在构建一个本可以使用的可重用的Material UI对话框组件。

Another time I spent time reading a tutorial on how to get the identity of an authenticated user, not realizing that my teammate had already figured it out.

还有一次我花时间阅读有关如何获取经过身份验证的用户身份的教程，但没有意识到我的队友已经知道了这一点。

Realizing how much time I was spending doing unnecessary work, I started posting in our Slack message board what I was working on and requesting feedback. My teammates were quick to respond. By having my colleagues give input on my unfinished designs, I was able to avoid duplicating work.

意识到我花了多少时间做不必要的工作后，我开始在Slack留言板上发布我正在做的事情并要求反馈。 我的队友React很快。 通过让我的同事对未完成的设计提供意见，我避免了重复工作。

第3课：时间紧迫，应优先考虑避免学习的内容 (Lesson 3: When pressed for time, prioritize what to avoid learning)

Given that I struggled to keep up with the workload, I needed to better prioritize my time. Whenever someone created a new feature, they would create a Git Pull Request (PR) to ask for the code to be reviewed. At first, I reviewed every PR and gave each of them my full attention. However, this soon proved impractical.

鉴于我努力跟上工作量，因此我需要更好地安排时间的优先级。 每当有人创建新功能时，他们都会创建一个Git Pull Request(PR)来请求代码进行审查。 首先，我审查了每个PR，并给予了我充分的关注。 但是，这很快被证明是不切实际的。

I remember spending lots of time reviewing the PR to add cookies and tokens for authentication. To do a proper review, I first read lots of background info on security issues such as cookies, local storage, and cross site scripting attacks. When I finished all that reading I read through the PR, only to find all the code made sense and there was nothing for me to comment on.

我记得我花了很多时间来审查PR，以添加cookie和令牌进行身份验证。 为了进行适当的审查，我首先阅读了许多有关安全性问题的背景信息，例如Cookie，本地存储和跨站点脚本攻击。 当我完成所有阅读后，我通读了PR，结果发现所有代码都有意义，没有什么可评论的。

In hindsight, given how far behind I was with my own tasks, I should have ignored much of the cookie documentation and instead done just a rapid PR review to save time.

事后看来，考虑到我的工作远远落后于我，我应该忽略很多cookie文档，而只是进行快速的PR审查以节省时间。

Gaining an in-depth knowledge of the inner workings of our cookie authentication was of little use to my overall productivity. In contrast, other PRs such as the one which set up React Context to pass state through our app directly affected nearly every feature that I worked on.

深入了解我们的cookie身份验证的内部工作原理对我的整体生产力没有多大用处。 相比之下，其他PR(例如将React Context设置为通过我们的应用传递状态的PR)直接影响了我开发的几乎所有功能。

Prioritizing gaining a deep understanding of that PR would have been a far more valuable use of my time.

优先获得对PR的深刻理解将是我宝贵的时间。

第4课：通过逐块构建新功能 (Lesson 4: Build new features by going from chunk to chunk)

To get more organized, I had to learn how to skim through technical documentation. I called a senior engineering friend of mine, Sean Ellison-Chen, and asked his process for tackling a new feature that requires a technology that is brand new to him.

为了使工作更有条理，我必须学习如何浏览技术文档。 我给我的高级工程朋友Sean Ellison-Chen打电话，并询问了他处理新功能的过程，该功能需要对他来说是全新的技术。

He explained that he first tries to understand at most 70% of what is going on, and then immediately starts building the feature in chunks. Each chunk gets committed to git.

他解释说，他首先尝试了解最多70％的情况，然后立即开始按块构建功能。 每个块都提交给git。

For example, let’s say he needs to set up web sockets, he might set up a basic skeleton structure for web sockets, commit it to git, then work on the next chunk of setting up the correct socket events and so on.

例如，假设他需要设置Web套接字，他可能会为Web套接字设置基本的框架结构，将其提交给git，然后进行下一个设置正确的套接字事件的工作，依此类推。

By working in chunks, he ensures a smooth progression from tackling the bare minimums to eventually having a fully functioning feature.

通过分块工作，他确保了从解决最低要求到最终具有功能全面的平稳过渡。

第5课：要求团队负责人提供反馈 (Lesson 5: Request feedback from your team lead)

Midway through the program, I received feedback from our team lead, Shums Kassam. I was told to ask for help more, to skim through documentation, and to leverage my teammates.

在计划进行中，我收到了团队负责人Shums Kassam的反馈。 我被告知要寻求更多帮助，浏览文档并利用我的队友。

I took the advice to heart and upped the amount of times I posted in our message board. I started having video calls with teammates to review features I was building. I skimmed faster through the technical documentation and avoided the less critical areas. By implementing these changes, my rate of contributions sped up.

我深信该建议，并增加了在留言板上发布的次数。 我开始与队友进行视频通话，以查看我正在构建的功能。 我快速浏览了技术文档，并避开了关键区域。 通过实施这些更改，我的捐款速度加快了。

第6课：避免在要求可能会发生变化的任务上做得完美 (Lesson 6: Avoid doing a perfect job on tasks whose requirements might change)

By sheer luck, I learned the importance of procrastinating on tasks whose requirements might change.

靠运气，我了解了拖延要求可能会改变的任务的重要性。

One of my first tasks was building a front-end form that lets users change their profile info. When I submitted my code for review, I was told the form’s appearance needed to be fixed as some of the input lengths did not match.

我的首要任务之一是建立一个前端表单，使用户可以更改其个人资料信息。 当我提交代码进行审查时，由于某些输入长度不匹配，我被告知需要修复表单的外观。

Normally, I would have spent the 45 minutes to fix it right then and there. But I was far behind in my contributions, so instead I just commented a “todo” about matching the input lengths and merged my code.

通常，我会花45分钟的时间在那里修复它。 但是我的贡献远远落在后面，所以我只说了关于匹配输入长度并合并代码的“待办事项”。

A week later, a teammate pointed out it would be a better user experience to combine the separate ‘street’, ‘city’, ‘state’, and ‘country’ inputs into a single ‘address’ input. When he simplified the inputs, my commented out “todo” was no longer applicable.

一周后，一个队友指出，将单独的“街道”，“城市”，“州”和“国家”输入组合为单个“地址”输入将是更好的用户体验。 当他简化输入时，我的注释“待办事项”不再适用。

By procrastinating with working on the form, I had saved myself from doing unnecessary work.

通过拖延处理表格，我避免了自己做不必要的工作。

第7课：轻松提交未重构的代码 (Lesson 7: Be comfortable submitting non-refactored code)

Near the end of our project, our team was rushing to finish all our features prior to a fixed date when we would present our project to an audience. We planned to have all features submitted well in advance to give us enough time to practice and rehearse.

在项目接近尾声时，我们的团队急于在固定日期之前完成所有功能，以便向观众展示项目。 我们计划提前提交所有功能，以便给我们足够的时间进行练习和排练。

But I ended up submitting my final feature with barely an hour to our demo and we had to rush to add it in. Though our presentation went well, I was troubled that I submitted the feature so late as it severely reduced our team’s ability to rehearse our demo in advance.

但是我最终只花了一个小时就向演示文稿提交了我的最终功能，因此我们不得不急于添加它。尽管我们的演示进行得很顺利，但我却感到很晚才提交了功能，因为它严重降低了我们团队的排练能力提前进行演示。

In hindsight I realize that instead of submitting optimized and clean code, I could have saved at least two hours of time by simply adding comments about refactoring later.

事后看来，我意识到不用提交优化和简洁的代码，而是可以通过简单地添加有关稍后重构的注释来节省至少两个小时的时间。

Over the past few months, I learned many lessons about how to be a better team player. Most importantly, I learned that teamwork is a skill that can be improved just like any other.

在过去的几个月中，我学到了很多关于如何成为更好的团队合作者的经验教训。 最重要的是，我了解到团队合作是一项可以像其他任何方式一样得到提高的技能。

The program I participated in was run by Hatchways, a company that helps software engineers get their first jobs. At the time of this writing they service engineers and companies in North America. If you're an employer looking to hire interns or entry-level engineers see Hatchways - Employers.

我参加的程序是由Hatchways运营的，该公司帮助软件工程师获得第一份工作。 在撰写本文时，他们为北美的工程师和公司提供服务。 如果您是想雇用实习生或入门级工程师的雇主，请参阅《 海奇威雇主》 。

I am from New York city and am currently looking for a new software engineering position. Here is my resume. My email is [email protected]

我来自纽约，目前正在寻找新的软件工程职位。 这是我的简历 。 我的电子邮件是[email protected]

翻译自: https://www.freecodecamp.org/news/how-to-be-a-team-player/