Due to lazy motivation, enhance the quality of the product

I recognize a very perverse phenomenon, and good programmers are both lazy and silly.

Because of lazy, he will write a variety of tools to work for himself. Because of laziness, he will find ways to avoid writing boring repetitive code - so to avoid redundancy of the code, reducing the cost of maintenance, making reconstruction easy. Ultimately, these tools and best practices for programming that have been developed as a result of laziness have improved product quality.

Lazy programmers have therefore become excellent programmers. Of course, that's only part of the story; from being a lazy programmer to being a good programmer, he / she will show amazing laziness while learning how to stay lazy forever - that is, what kind of software tools Can make it easier for yourself to work, what method can avoid the cumbersome, how to make the work easier to maintain and reconstruction.

Second, (I'll explain this a little more because I find it harder to accept than the first.) Good programmers are stupid. Why? Because if he is smart or he knows he is smart, he will:

a) stop learning

b) no longer high standards and high demands on their work

The first point will lead him not to work hard to discover new technologies and make himself work faster. The second point will cause his code to become difficult to debug, difficult to refactor. In an endless war between programmers and compilers, programmers should preferably surrender themselves at first, recognizing their own fault, not the compiler's fault (unless it is true that some compilers have problems with character encoding).

However, there is one more, more important reason why good programmers must be stupid. In order to find a better solution to the problem, he must maintain a modest attitude, he must jump out of the model to ask questions. To some extent, this will get them back to the child's mindset; be creative with a never-hit hit.

The opposite mode of thinking is not so innovative, will think well aware of the status quo, will accept the status quo. But who knows how much you think it is impossible? The less you know, the more aggressive you are. The better you develop the tools, the better your product will be because of their quality.

As I learned from my work, a good programmer needs a clumsy mindset when identifying a need from a manager; he asks from the simplest, childlike question. He will not take for granted the information provided by this problem provider. A typical conversation in web development is this:

"Yesterday, one client said that the logo image on our site could not be displayed."

"Did he restart the browser?"

"Yes."

"Has he restarted the computer?"

"Yes."

"Has he cleared the cache yet?"

"Yes."

"Does he use IE6?"

"Yes."

"Is he sure you did not see it?"

"Yes."

"Did he see our website on the computer screen?"

"what?"

"That's it, he might have printed it out."

"No, it's just staring at the screen."

"Can he see other pictures on the site besides the logo?"

"What? Oh, I ask."

To illustrate our theme (the story is completely fictitious), let's assume that the client really closed the browser's image display. Maybe his son did it. Anyway, if you think in "smart" mode, you find it hard to find such an answer. Therefore, the programmer asked the question does not require any programming knowledge. Because this is a silly question, so only a silly solution can be solved.

A few years ago, I had a long phone conversation about things that broke my site because of one of my updates ... It turns out that guy was banning CSS from his browser. Since then, I began to doubt everything, not because of such a simple matter to listen to what is a half-hour code quality complaints. In the end, the guess is that my update has a problem ... just a guess. If you want to solve the problem, the best way is to just listen to the facts, do not listen to what they think is the possible cause.

Similarly, when a colleague asked me, "Why is this not good?" Most of the time because they changed the wrong one (for example, he wanted to link lib1, but he actually linked to lib2, or in fact he did not link any lib). When you ask a colleague, especially programming, you generally do not tell him more about the project. When he asks silly questions, you subconsciously boycott the answer because you think you know it very well, but in fact you are not.

Of course there is another side of things. Too stupid also can not think of any way, doing wrong, can not solve any problem. And too smart like to sit and plan the problem, but rarely move. Pragmatist programmers take them. He knew that a mistake in 10 decisions was a lot better than having only five correct decisions and five others doing nothing.

It's a bit like a centipede story. Centipede is very good at using it's 100 legs to walk together. It never wondered how it did it. Until one day, a bug asked him, "How do you control so many legs to walk? Do not you think it is hard to let them walk with a certain rhythm?" The bug left and the centipede sat still thinking , Thinking how to walk, puzzled, or even (the first time in my life) a bit worried. Since then, the centipede never took a step back.

So if you want to do something, do not think too much. Of course, this is only half the story ....