開源日報 每天推薦一個 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/