Yao Dong's view

Learning ability, especially self-learning ability, when have you ever seen those famous programming experts ask on forums, "What book should I read to learn XX,how to learn XXX quickly,what code do you recommend for learning XXX"? Whatever they want to learn, they can quickly find relevant materials on their own. This industry develops too fast, and technology becomes obsolete very quickly. If you don't learn new things for 3 years, you may fall behind.

Hands-on ability, everyone reads books and materials, but while others are still agonizing over what book to read and what the words in the book mean, some people have already gotten hundreds or thousands of lines of code running.

Patience and perseverance, interest is certainly important for a programmer—writing code you like is a very enjoyable thing—but in software development there will always be a large amount of boring and uninteresting work, and you need to persist and grit your teeth to finish it.

Expression ability, being able to present your ideas logically, fluently, and clearly in public so that people understand.

What about technical skills? Technical skills aren't important. With the abilities above, whatever technology the market needs, you can master it quickly.

Finally, let's talk about salary. Remember two sentences:

• Salary is not the boss's reward for your past contributions, but his expectation of your future contributions.
• Your current boss will never give you a satisfactory salary; only your next boss will.

Cao Zheng's view

Yao Dong answered very well. Let me add a few words by way of continuation.

We all know learning ability is very important, but where does learning ability come from? Apart from reading books and taking classes, how do you learn and grow in practical work?

I said a general concept on Weibo before: what is ability? Your attitude toward problems, and your approach and methods for handling them.

First, attitude

Your server occasionally returns 501 errors, maybe not at a high rate (Zhihu has had this happen many times too). Many programmers—yes, many—pretend not to see it, don't care, or blame it on bad luck. This is an attitude problem.

Later, when the load gets high or for some other reason, 501 errors suddenly occur frequently. Instead of investigating the root cause, they look for all kinds of excuses: the IDC provider is bad, the server brand is bad, the operating system is bad, the database is bad, the CDN is bad, the network conditions are bad, the web server is bad, or even directly tell the Boss, "We're being DDoSed!" (I've encountered this—I helped his boss find multiple security experts for a joint consultation, and in the end we found it wasn't DDoS at all; the programmer was just too lousy.)

This is attitude, and it is shocking. If you can be sensitive to problems and have enough keenness toward any small, minor issue, you have a foundation for rapid growth. Keenness toward problems is very important. Many non-fatal bugs in performance or program logic cannot be detected when you're not keen enough, but once a special scenario occurs, they suddenly erupt. A little more keenness on your part reduces the risk of such crises.

The second attitude is the attitude toward solving problems. Some people are full of confidence in their solutions and believe they are foolproof, while others leave themselves an extra way out. For example, when you say, should I harden my server's security? You definitely should, right? You should be as rigorous and thorough as possible. But should you still encrypt passwords when saving them in the database? And use a random salt? Isn't that precisely to prevent the worst case where there's still a vulnerability and someone takes the database? The same goes for programs. Some server-side daemon processes I wrote in the past had bugs and would terminate inexplicably. Of course, this bug has to be located and fixed, but at the same time, write a cron to check the daemon's status and automatically restore it once it terminates. This is a backup plan. Even if you really don't want it to execute, you still need to make this preparation. Having two or even three plans for a problem is also a key quality of excellent programmers and architects.

The third attitude is based on communication and understanding. When the product or operations team raises an unreasonable requirement, rejecting it in one sentence is certainly satisfying and impressive. But have you carefully communicated and analyzed what actual need this requirement is based on, and whether this actual need has a more reasonable way to be implemented? A flat "this can't be done, the implementation cost is too high" is not the right communication attitude. Moreover, the best products are often those that realized the needs people originally thought couldn't be realized.

With such an attitude, you have a foundation for continuous progress. Now let's talk about approaches and methods.

If you only look at the speed of typing code, I think you can't distinguish an excellent programmer from a mediocre one. Perhaps everyone can write many lines of code in a day, but when a problem arises, the difference in problem-solving efficiency between a mediocre programmer and an excellent programmer is like heaven and earth. So-called solving efficiency is nothing more than the analysis, location, and thinking about bugs.

The most basic point: check execution logs, check all kinds of logs—web server logs, database logs, slow query logs, binlog logs, PHP error logs, and so on. When problems occur in production, there are plenty of people who guess wildly without even looking at logs. There are also plenty who don't read logs carefully or completely. If you can seriously study logs, you've already surpassed many people.

Second: module testing and breakpoint analysis. A bad habit of programmers is to start by writing a huge chunk of code and then execute it, not knowing to write and test module by module, and not knowing to set breakpoints, narrow down the scope, and analyze step by step when something goes wrong after execution. Breakpoint analysis is very simple: insert several intermediate outputs into the code to observe which link has the problem, or observe the system overhead of each link. This is very important for both debugging and performance optimization. Experts probably think this is ABC-level stuff, but as for this thing, most programmers I've seen don't have this habit.

Third: understanding and searching error messages. Search engines have all kinds of rich technical materials and technical Q&A. The error messages and prompts you encounter can usually be found online. Of course, after finding them, you need to think carefully in the context of your scenario and understand them thoroughly, rather than handling them by rote copying. Otherwise, you might get lucky this time and guess right, but next time when luck isn't with you, you won't know what's going on.

Fourth: constantly summarize and generalize. For one problem, a class of problems, and different types of problems, be good at organizing and summarizing, and constantly reflect on your own problems. Even for code that doesn't produce bugs, when you look back after some time, there are many places where your thinking was incorrect or unreasonable, and many optimization points. If you think your code has always been awesome and flawless, then you're definitely marking time and making no progress.

Regarding summarizing, let me share a case.

Previously we had a system with a very large request volume and very high load. A fairly good technical manager came to handle it. He listed several upgrade plans, all reliable, executed them, and the results were very good. Then when we followed up on the report, he talked about the upgrades he had made and the overall results. Then I criticized him.

What did I criticize? He did the upgrades together, then observed the effects together. So among those plans, he had no data on the actual effect of each specific plan or how much it helped the improvement. So he had no concept of the value and importance of each specific upgrade plan. You solved the problem correctly, but if you didn't carefully summarize and organize, your gains are limited. Doing upgrades together can't be said to be wrong, but effect evaluation needs to be done separately, and this data is very valuable. Knowledge accumulation isn't necessarily gained from what you've handled; it's gained from what you've organized.

That's about it.

Finally, let me restate it once more.

What is ability?

• Your attitude when encountering problems
• Your approach and methods for handling problems

That is ability

Original source:Zhihu