Programmers, how to go from mediocrity to ideal?

   
    I think there are only three categories of programmers: genius programmers, ideal programmers, and mediocre programmers. I can only say that I have been in contact with 3 genius programmers. This is destiny. 7 points are determined when you are a sperm, with excellent mathematical talent, calm and dense logic, and technical enthusiasm for solving problems that would rather sleep and enjoy; 3 points come from starting early and wishing for peers When you play mud, you have to start playing with the computer. Before graduating from college, you will break the 10,000-hour rule, and the rest is the game life.

    Genius programmers are hard to come by, let alone long-term, and 90% of the ones I see are still mediocre programmers. The expansion of the IT era has made programmers as ordinary as the printers in the Renaissance. Most of the people who invested in the family of the ancestors were only for a bigger job, higher treatment, and better livelihood. Mediocre programmers write rotten code with no specification and consistency, stick to old world languages, and talk about big architecture and performance better than doing it. Without exception, they believe that there is no way out for technology, and it is more advanced craftsmanship to make products, marketing and management, and 99% of them will naturally reveal that they happen to have talent in that area. As for the process The small question of why it crashes is disdainful to understand. And I like to get along with ideal programmers the most. I can't wait to eat and live with them. If allowed, I hope my team can be filled with their flags. The ideal programmer is not bad at heart (they are never the darlings of office politics, they are a group of simple bright and happy craftsmen), and innocent curiosity (their eyes often flash "Wow, how is this done?" !"), always improving (their mantra is "I'll study it again"), and sharing (they are active on GitHub, Q&A communities, and around you, and are willing to devote their precious time to helping newbies). Yes, they don't need to be managed, they just need to be given a general direction that always pays off with unexpected results. The ideal programmer is separated from the mediocre programmer by a wall. The gap between the two is only a little bit of 6, and the gap between people, it is in this little bit that has been accumulated over time, it has been opened forever. Interestingly, I found that these six points are all related to consciousness, that is, programmers, like all other emerging industries, only need consciousness and time to temper, and everyone can reach the ideal stage. The ideal programmer must also be a good problem-solver.


    The first little bit: Focusing on
    the moment I have seen too many programmers who are arrogant, I have to take "focus on the moment" as the first word of the sky. They often have all kinds of small dreams, such as being a small tea farmer, a goose seller, making products, making sales, and making investments, but they are "delayed" by the programmer's high salary or lack of courage to change careers. Because they are not focused, they don't care about doing their part, honing their skills, or learning emerging technologies. It is undeniable that there are great products (like Mr. Joe), great sales (like Ellison), great investors (like Peter Fei), and they are all programmers without exception. But have you heard what Buffett said about Gates, if Bill Gates switched to selling dogs, he must be the biggest dog dealer in the world. I firmly believe that with the exception of a few geniuses, all beings can succeed in many fields, as long as they maintain enough focus. And even if you want to sell dogs in the next year, the experience of programmers can still train your strong logic, prudence and patience, which is quite competitive in any industry.


    The second point: thinking and driving force
    I think that dealing with emergencies such as bugs, crashes, tuning, and intrusions can better reflect the gap between mediocre programmers and ideal programmers than programming itself. When faced with an unknown problem, how to locate the core problem under complex conditions, how to analyze the potential causes of the problem in a nutshell, how to eliminate interference and restore a minimal verifiable scene, how to seize key data to verify one's own guesses and experiments, It is the best scene that reflects the thinking ability of programmers. Yes, thinking is more important than experience when it comes to measuring the ideal programmer. Sometimes when a friend comes over and asks me, "I submitted a task and got stuck, what should I do?", I always think he can do better. For example, you can check and test other tasks to rule out the cause of the code itself; you can check for exceptions through the Web UI (if you don’t have an account, you can let me provide it); you can check the host log or delete the cache, and if it’s bad, you should always provide the task ID and console log to me. The ideal programmer never waits for things to move forward, they do everything they can to make things move.


    The third little bit: Never Say No
    I remember talking to the boss before I left the factory. He said that my biggest advantage was that I never told him that I couldn’t do it. Later, I found that in many teams, there is a confrontation between technology and products. Programmers often block the needs of products with "technically impossible", and products are often ridiculed with "Why Facebook can't do it" programmer. These two sentences should belong to the forbidden language, which is fundamentally not conducive to the mutual love between programmers and product dogs. It's easy to say "technically impossible", but how many people are 100% sure when they say this? If not sure, why not go back and google it and answer? Originally, I thought that programmers were full of imagination. It is because of imagination that so many software and Internet products that change our lives can be born. With more knowledge, I realize that most programmers have become conservative and unwilling to take risks in the fight against bugs, and at the same time many teams are unwilling to tolerate failure. So "Say No" became a habitual conflict. Remember why Zeng Guofan disbanded the Hunan Army? He said that the army was "fading away" and could no longer fight. To be an ideal programmer, you cannot give yourself the opportunity to breed anger. If you face unreasonable demands, you can put out the time cost and show the curve saving plan. Simple and rude "Say No" is not advisable.


    4th little bit: Investing in the future
    Programmers are a very cruel profession. The languages, frameworks, and patterns you've learned may well be a thing of the past in a few years; the other group of programmers you're laughing at now may be able to turn around and laugh at you in no time. Therefore, in addition to doing their part, the ideal programmer also spends time investing in the future. What is "investment"? An investment is the time you put in now, which will pay you back in the future with more time or money (look at the current pay for programmers who learned iOS a few years ago!). Take my own field - data mining as an example. Hadoop began to rise around 2008. The concept of "big data" was hot, and Hadoop engineers were hard to find. Various Internet companies have switched their data statistics, data analysis and data mining business to on a distributed platform. Seeing that Hadoop is still iterating in recent years, Spark has sprung up again, refreshing the sorting records maintained by Hadoop in one fell swoop. The performance advantages and rich data structures brought by storing intermediate data in memory make people fall in love with all kinds of strange small Bugs and a steep learning curve are also frustrating. Well, everyone with discernment knows that Spark is the future trend (memory will be cheaper and cheaper). Under the condition that the main business is placed on Hadoop, some small modules can be appropriately switched to Spark, and at the same time, pay attention to the development of the Spark community. The performance gains you get from Spark quickly pay for the learning time you've invested in it.

    The 5th little bit: Make good use of tools
    Making good use of tools can be divided into 4 levels: search engines; do not believe in repetition; code snippets; automation
    When I first entered the industry, a friend who majored in computer but became a civil servant asked me, you have never learned programming at all, how do you usually write code? I said, Google, and I was ruthlessly ridiculed, so that my account was called 2shou everywhere, and I told myself that I was a shameless second-hand programmer. It's a joke, but if you asked me now, I'd still Google it. The growth of programmers is like a swollen round pie. Outside is an endless sea. The bigger the round pie, the bigger the surface that is in contact with the sea. The more you know, the more you don’t understand. The disciplines that are changing rapidly are also the disciplines with the best knowledge on the Internet. It is difficult to use the traditional classroom-style teaching and learning methods. On the contrary, it is easy to obtain the latest knowledge through search engines. I don’t believe in repetition. The master’s words are called the DRY principle (Dont repeat yourself). If you write too much code, there will be artificial intuition to judge good and bad code. My standard is simplicity and standardization. The less you give yourself, the less chance you have to make mistakes, and the less maintenance costs you will have to pay later.

    If you are unfortunate enough to lose the code from three weeks ago, you may be able to rewrite the remaining fragments in your mind with your extraordinary memory, but if you lose the code from three months ago, I am afraid you will not have such good luck. The ideal programmer will focus on finding an effective way to save data, and save short snippets of code, scripts, configurations, experiences, etc., written in a flash of inspiration at work, so that they can be reviewed at any time.

    The ideal programmer must be lazy. To them, repeated steps are as ugly as repeated code, and if you realize that a job has the potential to be repeated for a long time, the sooner you automate it, the better.

    6th little bit: managing time
    The reason why time management is especially important to the programmer's profession is that you have to "walk alone" like a wolf in the wilderness when completing tasks. If you can stably control yourself without external constraints, and ensure that you can work and study efficiently, you will definitely become better than the average person over time. Programmers do high-intensity mental work. Generally, 4-5 hours a day is enough to deal with their own work, but outside of work, they must arrange time for study. In addition to studying, it is also necessary to take some time to let yourself go. Use the time between making tea or drinking coffee to save precious time for yourself, thinking about the future, and doing more with less.

     Having said so much, some people must ask, what is the use of working hard to become an ideal programmer? Will there be high salaries? Do not. Can I get a promotion? Not necessarily. What about marrying Bai Fumei? Better to sell dogs. Kazuo Inamori once told a story that the craftsmen in the Meiji period were summoned by the emperor. Although they were all countrymen who did not read, but they did one thing conscientiously all their lives, they naturally had a noble temperament. The ideal programmer should follow this noble temperament.