今日推荐英文原文：《Why you should have the discussions even if you’re right》
推荐理由：这个项目是用于一个看似很小的需求——对字符串中的链接进行修改使其变为一个 HTML 的链接标签。要想自己实现的话并非那么简单，所以作者单独把这个功能写成一个库，并为其加上了一些附加要素，诸如为标签提供不同的属性，或是允许开发者自己传入回调函数实现自定义转换功能等等。
今日推荐英文原文：《Why you should have the discussions even if you’re right》作者：Ken De La Guera
Why you should have the discussions even if you’re rightWe engineers can be an interesting lot. Due to the nature of our jobs, we are wired to think a certain way. Engineers are essentially told “I want you to get from point A to point B”. No roads, rivers, or anything exists between the two points. Maybe you’ll build a road, maybe you’ll build a rocket, or maybe trebuchets are back in style. It is up to the engineer to decide how to get there.
This type of ask is typical and results in very analytical minds. This same mentality can also make it difficult to work with other engineers. Everyone has an idea of how to best do things, and it isn’t always easy to come to an agreement.
If you have never read “Programming Sucks”, I highly recommend you read it. The article illustrates the dichotomy I am talking about in a comical way. Here is an excerpt:
- Tom and Harry have been working together for years, but have an ongoing feud over whether to use metric or imperial measurements, and it’s become a case of “whoever got to that part of the design first.”
Engineers are by necessity very opinionated and generally know how they want to tackle a problem before they even start writing code. Collaboration by extension then becomes very difficult.
I think learning how to collaborate is one of the hardest things to learn to do well, especially in the tech field. If you learn how to do this, you will be wildly successful, and here is why.
Collaboration allows you to make sure that your plan is bullet proof and accounts for everything needed. Even if it turns out the original plan was solid, it still provides the confirmation, disseminates the information, and also provides a potential learning opportunity for collaborators.
If I could, I would copy and paste those last two sentences 10 times, and call the article done. This is because there is a lot in those sentences that I think we should always keep in mind. Collaborating:
- Ensures the solution provided adequately meets all requirements/hurdles.
- Disseminates the information to the team.
- As team members ask questions and you are able to answer them, it helps them understand and grow.
- Improves your communication skills since you are having to pitch this idea to the team and then intelligently address any concerns that are brought up.
- By extension from the previous point, collaborating also makes you more knowledgeable. There is a knowledge gap between knowing enough to do something, and knowing enough to speak about it.
- Helps to increase the adoption of patterns. Check out the linked article for a more in-depth explanation. Establishing problems means you are not only fixing today’s issue, but tomorrow’s as well.
ConclusionI wanted to expand on some of the points above. Among other things, talk about peer reviews and how it leads to less bugs and more maintainable code. I am intentionally cutting this article short so that hopefully the message above is not watered down or lost in the process of a long read.
Collaboration allows you to make sure that your plan is bullet proof and accounts for everything needed (no one is perfect). Even if it turns out the original plan was solid, it still provides the confirmation, disseminates the information, and also provides a potential learning opportunity for collaborators. All of the above makes you a better engineer, makes for a more efficient team, and makes work more enjoyable.