Lazy + stupid = Excellent programmers

These two words seem incredible in connection with excellence. However, from a dialectical perspective, these two elements are indeed what a good programmer should possess. Refer to the original article of Philipp lenssen here. This article is not entirely literal translated from the original, but I agree with the author's point of view.

　　LazyOnly lazy programmers can write automated tools that can ultimately replace their jobs, it will not take days to write large sections of redundant code to achieve similar functions-this code is often the natural enemy of software maintenance and reconstruction. Generally, tools and programs driven by inertia will eventually greatly increase the speed of production and development.

Of course, for a programmer, it is still not enough to have the element of laziness. Before being lazy, he must study ways to free himself with the greatest enthusiasm and efficiency. For example, finding the tool that is most helpful for development can best reflect "one write, the Design of code architecture with the spirit of multiple reuse. Only after these necessary jobs can you really enjoy the fun of programming.

So the essence of "lazy" is described in an old saying, that is, the power of sharpening a knife without mistake. If you don't want to sharpen the knives in your hands, even if you cut firewood 24 hours a day, it would be better to take a sharp ax for only one hour a day.

From this perspective, Google's 20% free time to its employees is completely "lazy. To better enjoy the fun of laziness, employees can perform their tasks more creatively and efficiently.

To put it simply, laziness is the driving force behind human progress.

　　StupidThis seems more unacceptable than laziness. Before explaining the specific meanings of dummies, let's look at what a smart person (or a smart person) will do:

1) stop learning new things
2) unwilling to take a critical view of your work

The 1st point will make it hard for us to accept or take the initiative to study a new technology-even if the new technology brings him more convenience at work. 2nd points will make it impossible for us to clearly analyze the problems of our work, and it is more difficult to improve or reconstruct it.

From these two points, being a programmer is too self-righteous and not necessarily a good thing. Because you are too confident in yourself, you often cannot view yourself and your work objectively. On the contrary, being stupid (or humble, to be specific) sometimes helps to develop smoothly. For example, when a program encounters a bug, it is best to acknowledge that the problem lies in your own code rather than the compiler (unless it is a matter of byte high/low bit encoding, the compiler will be one of the root causes of the error ). If you think that your program is okay, and you guess it may be a problem with the compiler or other external factors, then you may take a long detour during the debugging process.

The more important reason why programmers should be stupid is that when we need to think about the best solution to the problem, we often need to jump out of the mindset first. The more you know about the system, the more experience you have accumulated, the more difficult it is to get out of the existing limitations, and the smaller the scope you can try. On the contrary, for a layman who does not understand anything, there is no "impossible" because there is no memory for failure or potential rule constraints, what this brain can bring out is often the key point that professionals need to solve their problems.

Many programmers may have similar experiences. When describing a bug in the face of others (especially in other departments, you must put yourself in the perspective of a common user rather than a program developer to analyze the problem. Otherwise, you may never think that this kind of error will happen. The more you can make yourself stupid, the more quickly you can locate the problem. Let's take a look at the conversation between programmers and customer service personnel about web development:

"Since yesterday, our users have not seen the logo on our site ."
"Has he tried restarting the browser ?"
"Yes ."
"Has he tried to restart the computer ?"
"Yes ."
"Has he cleared the browser cache ?"
"Yes ."
"Is his browser version IE6 ?"
"Yes ."
"Are you sure you really can't see the logo ?"
"Yes ."
"Is he looking at our site on a computer display screen ?"
"What ?"
"For example, it may be printed and cannot be seen ?"
"No. He looked at the monitor ."
"Apart from the Website Logo, can he not see any other images ?"
"What? Oh. I will ask him again ."

In this conversation, it is estimated that the user has actually disabled the function of displaying images in the browser (or by his son ). However, if you are not looking for answers in this silly way of thinking, you may not be able to find the root cause of the problem.

In many cases, the problem discoverers often describe the problem in a very one-sided manner and add subjective speculation to it. If you cannot discover the actual appearance of a problem through these subjective descriptions, or simply judge the problem by yourself based on the programmer's experience logic, you will go astray and further.

Only an idiot-level question can be answered by an idiot's behavior.

Even if you are a programmer, but you are not familiar with your program, you will often have the following question: "Why did I call your code wrong ?" The answer to this kind of question is often because they call the wrong method, call the wrong library file, or use the library file version improperly, or are not connected to the library file at all. When you want a colleague to help you check for an inexplicable bug in the program, the less you want him to know about your system, the better, only in this way will he ask some "stupid" questions that you think are absolutely impossible.

So the essence of "stupid" lies in how you think about the problem: Do not assume something, making your assumptions perfect or making others' assumptions clever will make you ignore some simple facts. The premise of thinking must be a complete fact representation, and the process of thinking must be a problem tracking that abandons prejudice. If you think too much and think too much before discovering the facts, it is better to act as an idiot.

Of course, one extreme that you don't think about is to do it directly regardless of the situation, and the other extreme is to completely break away from facts and use your thoughts to do things. A good programmer should make a good balance. It is not fatal to make the first mistake in the ten decisions; it is worse to make five correct decisions without any decision for the other five.

The last story is the story of the blind. It was good to walk quickly with hundreds of his feet, but he never took the time to think about why. One day, a bug asked him, "How did you manage your hundreds of feet? Don't you think this is a very difficult thing ?" The bug left after it was asked. The only thing left is that you are sitting on the ground and constantly thinking about this problem, but you have never been able to think about it. From then on, this cockroach can no longer walk well.