开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
今日推荐开源项目:《接受挑战 JavaScript30》
今日推荐英文原文:《Programmers: Make Yourself Replaceable》

今日推荐开源项目:《接受挑战 JavaScript30》传送门:GitHub链接
推荐理由:国庆要结束啦,准备好接着回到爆肝的日子中了吗?如果不知道回到日常的工作学习中要干点啥来填充自由活动时间的话,这个项目就是个好主意。这个项目是用纯粹的 JS 来实现一些玩意儿的挑战,借助这些挑战来达到学习框架背后知识的目的。有工具用自然不是坏事,但是这样一些知识就被工具所掩盖了起来,将这些被掩盖的知识重新发掘出来,就是这个项目希望倡导的。
今日推荐英文原文:《Programmers: Make Yourself Replaceable》作者:Malcolm Laing
原文链接:https://medium.com/better-programming/programmers-make-yourself-replaceable-1b08a94bf5
推荐理由:让你的技能等级在世界上所有人中难以替代——而不是只在公司里

Programmers: Make Yourself Replaceable

Why making yourself replaceable will lead to a better career

My first internship after studying computer science at college was a disaster. They didn’t use any form of version control. We had no local development environments — we all ran our code on the same staging server. If one person crashed the app, it would crash it for everyone. The application was an undocumented spaghetti code disaster.

There was only one person able to work with this application. They were irreplaceable — without them, nothing would get done. Tasks that would take the rest of us days took them hours.

Here are some of the factors that made them irreplaceable:
  • The undocumented framework made it difficult to onboard new team members.
  • Having no local development environment made people work less effectively.
  • Not using version control made it easier to introduce bugs and made code reviews impossible.
  • Information hoarding led to large knowledge silos.
But why is this a bad thing? Shouldn’t we strive to be indispensable? Seth Godin wrote the bestselling book “Linchpin: Are You Indispensable?” In it, he argues that Linchpins, or indispensable people, are the backbone of the workforce. He compels you to hoard knowledge and relationships to make yourself irreplaceable.

This is something that we have heard our entire lives. People joke about how we should make code so obscure that only we can understand it, to ensure job stability. Why would you want to be replaced?

Why You Don’t Want to Be Irreplaceable

1. Your skills become less marketable

If you spend years working with an obscure codebase, your skills become less relevant. You aren’t working with popular open-source frameworks. You might even work with a programming language that’s becoming less and less popular.

Companies want to hire people who have relevant experience. Experience developing features in a homemade framework isn’t relevant. Why hire someone who has only worked with jQuery, when I can hire someone who has two years of React experience?

Working with the same tools as potential employers increases your marketability.

2. Your work relationships will sour

Maintaining good relationships with your colleagues is hard when you hoard information. An irreplaceable programmer will often bend or break the rules that others follow. They often see themselves as above their colleagues. They are often difficult to work with and only want to do things their way. They won’t listen to feedback.

To go back to the example from my former internship, the programmer in question saw himself as above the rest of us. He would show up late and leave early. When you asked him for help, he would prefer to code for you instead of explaining his solution. He was terrible at onboarding new teammates.

Management noticed but chose to look the other way because of how vital he was to the organization. The rest of us felt like second-class employees, and morale suffered.

Instead of hoarding information, share it. Instead of coding for your teammates, pair-program. Instead of making up your own rules, follow them. This will make you more liked. It will allow you to not only teach your coworkers but learn from them.

3. It makes it harder to step away

If you have made yourself irreplaceable, then it’s hard to take sick days and vacations. If you don’t share knowledge about your part of the application, then nobody can help you. If there’s a problem, then you will be stuck fixing it. And if you aren’t available when disaster strikes, then the blame will fall on your shoulders.

4. It stops your career growth

If you are irreplaceable in your current position, why would your boss ever give you a promotion?

Let’s go for a more concrete example. John has worked for ten years at the same company as a PHP engineer. When John started at the company, they had one product. It was a poorly documented monolith that was very difficult to work with. John worked hard and made himself an expert in working with the monolith.

Over the past ten years, the company evolved and created new and exciting products. They started using more modern technologies and frameworks.

John’s coworkers got the opportunity to work with those more modern products, but not John. John’s supervisor knew he would be difficult to replace if they moved him off his project.

Some of John’s coworkers got promoted, others left the company for new jobs at higher pay. But John stayed behind. When he finally starting looking for a new job, he found it hard. In the last ten years, the industry had evolved. It had left him behind.

5. Believing you are irreplaceable gives you a false sense of security

We work hardest when we are working for something. If we know we are irreplaceable, we tend to become complacent. We start taking longer lunches. Arriving later, and leaving earlier.

Even if you are irreplaceable, there are many ways you can still lose your job. What if the company goes bankrupt? Or the product you are working on loses market share? Or if your company decides to outsource its development to a low-cost area?

Face it, there’s no such thing as true job security. Instead of investing in your job, you should invest in yourself. Develop your interpersonal skills by working together with your colleagues. Learn new skills and work with market-leading technology.

Prepare yourself, and when you do lose your job, you will have no trouble finding a new one.

How To Make Yourself Replaceable

1. Practice inner source

Use best practices from open source in your closed-source software. Try the following:
  • Write a README file with examples and explanations.
  • Add a CONTRIBUTING file with information about conventions and a code style guide.
  • Create a pull request template to make it easier for teammates to contribute.
  • Set up a strong CI pipeline. Make sure your tests and linters run on every pull request.
  • Use a code formatter like prettier to stop nitpicking about formatting.

2. Share your knowledge and learn together

When you finish working on a feature, share what you learned. Set up lunch-and-learns and outline the problems you faced coming to your solution. Encourage your teammates to do the same. Create a Slack channel where people can post and discuss blog posts. When starting new projects, push to use new and different technologies.

Leave comments throughout your pull requests explaining why you made these changes. This makes it a lot easier for your reviewers to understand where you are coming from and why you made these changes. If you are having lots of back and forth over a pull request, call them up. Go through your changes together

3. Share the keys to the castle

Don’t let only one or two team members have access to the production environment. Encourage everyone to take responsibility. Rotate developer on-call responsibilities. Teach new team members how to use application-monitoring and error-tracking tools. Make everyone on the team a stakeholder.

It’s demoralizing when only one or two people are trusted with access to production. It also leads to people thinking why should they care about production issues if they aren’t trusted to fix them? Empowering your team to make fixes on production will lead them to feel more responsible.

4. Never stop learning

Introduce new tools and new practices to your workflow. Learn new technologies and frameworks. Identify pain points, and come up with solutions.

At my current position, I noticed that we would often introduce visual regressions. When making pull requests, it was difficult to check every component to see if they had changed. Testing manually took time and was prone to errors. Designers would get upset when these visual regressions made it to production.

So I did some research on different types of visual testing. I introduced visual regression testing. Now this testing setup makes it harder to break our component library.

It also makes me more replaceable — these tests make it easier for other developers to work with my code.

Making yourself replaceable makes it easier to take time off. It can help you develop better relationships with your colleagues. It makes you more attractive on the job market and even opens you up to promotions.
下载开源日报APP:https://openingsource.org/2579/
加入我们:https://openingsource.org/about/join/
关注我们:https://openingsource.org/about/love/