Being able to write programs is not enough. Here are 5 skills that all outstanding software engineers in Silicon Valley have.

Edmond Lau, who has worked for companies such as Google and Quora and is currently a software engineer at Quip, interviewed senior software engineers at well-known Internet companies such as Facebook, Instagram and Google in his book "The Effective Engineer", and summarized the five abilities that they believe highly productive and outstanding software engineers possess.

1. Don’t be afraid to explore unfamiliar programming languages

When you are approaching a new project or changing your career path, you may need to learn a completely unfamiliar programming language. Many people are afraid of this and even give up before trying. The fear of stepping out of your comfort zone is often greater than learning the program. They worry about whether they can reproduce the good performance of their past work, and even doubt their own abilities.

No matter how good an engineer is, he or she must have a starting point. For example, Dave Cutler, a senior engineer at Microsoft who built the foundation of Microsoft Windows, was born in the literary group and had no formal computer science education. He spent more time learning from mistakes than his peers. Among them, the two most important keys are to have a "growth mindset" instead of a "fixed mindset" and an "optimize for learning" attitude.

This critical skill of learning an unfamiliar programming language will become more and more accessible with practice, and will make you a better programmer in the process.

2. Master Debug

"Why does the program run differently than I expected?" is a question that many engineers will encounter. Debugging ability is often a key factor that affects whether an engineer can successfully complete a project, but it is underestimated by most people. The systematic thinking of debugging is as follows:

1. Let’s first assume the possible cause of the bug.
2. Define the possible consequences of this assumption if it is true.
3. Try to see if there are any conflicts with these results.
4. If there is a conflict, it means the assumption is wrong and you need to repeat the above thinking process.

From this, we can see that if you want to speed up debugging, you need to improve your ability to "propose hypotheses" and "examine hypotheses." The ability to make hypotheses can be improved as debugging experience accumulates, while the ability to examine requires strengthening the skills of using detection tools. In this process, you must first assume that everything is examineable and find tools or mechanisms that can be used to test or speed up testing. Never use only tools that you are familiar with.

3. Develop time-saving tools

Spend less time doing tasks that computers can already do, such as developing time-saving tools and automating workflows.

Bobby Johnson, a software engineer who was in charge of Facebook's software infrastructure team, led the team from 6 people to more than 100. He observed that most of the people who performed well in the team wrote many tools. The development time of these tools, which seemed to have no direct correlation with performance, might take up one-third of the working time, but greatly improved work efficiency. These tools included tools for deploying programs, monitoring systems, and other time-saving tools.

4. Optimize the speed of repetitive tasks

Software engineers may need to search and browse function definitions many times a day. Making good use of keyboard shortcuts can save considerable time. For example, each search takes 12 seconds, and similar steps are repeated 20 times a day. If shortcuts are used, the search time can be shortened to 2 seconds, which saves 40 hours a year. Other situations include testing on different devices each time you debug. In addition to opening the app separately, you also need to set up test scenarios. At this time, you can think about how to speed up such repetitive tasks.

5. Develop a systematic thinking model

Writing program code and making the program work is just the tip of the iceberg. To produce truly valuable programs, we must think from the program itself to the entire system.

• Is your program compatible with other libraries and functions written by others?
• Is the program tested and are you sure that other members can execute the functions you wrote?
• What production environment changes are required to deploy your application?
• Will the new procedure have a negative impact on other operating systems?
• Are customers and users using the new program as expected?
• Is the new program achieving the results the company expected?

Thinking about problems from a macro perspective can help you better understand how to allocate time and energy to achieve the best results for the program.