Eureka's story, focus can make you see things others can't see.

There is such an old proverb:

If you have a hammer in your hand, everything looks like a nail.

In fact, this is a cliché in the old song, we programmers have a lot of hammers: OO, design patterns, languages (c, C + +, Java, Python, Ruby, etc), a variety of architecture tricks&workarounds, And a bunch of software process methodologies (Agile, XP, Scrum, etc), and so on.

Some of the stories:

1. Arjuna ("Out of the Software Workshop"):

I used to lead the architecture group. Architecture Group of people in the 2002, crazy fascinated by the UML and design patterns, the hands of a "com Essence" and "design mode." My men have a novice, is everywhere is the class, everywhere is abstract, everywhere is the encapsulation, everywhere is separates, tries to make the code high cohesion low coupling. But such a code too cumbersome, he spent a lot of time, he looked at his code is pleasing, others see his code foggy, do not read "design mode" in accordance with the conventional understanding of business thinking to read his code is not understand, do not know why he wrote code, weird very. Originally, this wanted to achieve maintainability, readable, but really lost the maintainability, readability. This and I read a few days ago, my friend Greatlypraised wrote "Boulevard to Jane" wrote: Some people want to take UML to unify users and software designers. However, UML designers think that UML can describe everything because of how difficult it is to understand it. In this sense, to understand your code also to read the "design mode", which is too high a requirement.

Fortunately, the novice himself every time he wrote tired, slowly also lazy, feel really need to separate when the separation, feel no need to bother to do. He said in his self-deprecating words: was flattened. In fact, in my view, he now this code state is just good, that is, take care of the design extension, and take care of the practical. True Pure oo, pure design patterns, may exist only in teaching and science, and not in our commercial software development. We as a business development, the emphasis is on the basis of praise, so the compromise is necessary, customers and our own two suitable for OK, whether it is in line with the authentic, not in our business development and management category.

The novice also wrote a lot of notes. In each source code file header is written on the number of months, XX created, this original code file is mainly what, but also the lily to write the copyright, the company name. It seems that this code should be open source, or may be stolen by other companies to show the company's copyright. Even every function is written with comments, what each parameter means, and what the value of each parameter may mean is written. Over time, also lazy maintenance. Code changes, parameters expanded, parameter status values have changed, note description but did not follow the changes, so that later look at the code of the people old misunderstanding, rather than write these comments.

I told him: do not go to extremes. It is wrong to write all comments, or not to write comments. I only write notes where I think I should be careful, or where I find it hard to understand. Otherwise, I might have been wrong for a while. If I see a piece of code, I can read it, and I won't write a comment. We do enterprise management software, in-depth technology is not, as long as the code can be complex business process to describe the logic of clarity on the OK. Although the ability to understand is different, I can quickly understand the novice can not understand, but you see my code you understand. (Excerpt from the Software Workshop: Code of Things)

Another paragraph:

There are a part of the so-called architect, the technology is super deep, the framework is similar to spring, but a person to write the framework constantly optimized, exhausted use of the most advanced technical ideas, hoping to integrate the most luxurious design patterns, hoping to melt into OSGi, hope to integrate AOP into, All ignore the application function development colleagues who want to use the framework to reduce their workload and improve their productivity. Is it in the company's pay to play the technology, or to meet the personal technical fantasy, or in the experiment? What the hell are you doing? Where is the value?

There are people who don't promote their own framework. The lack of words, the illusion that the technical director can be through the executive order to use the framework, can not write their own code to write their own code, can be handed to the framework to do the framework. But the technical director's call was over, and everyone was still doing their own research, making the framework developers very lonely.

Others will not promote their own framework, indulge in their own ideal world. Finally, the technical director summoned everyone to listen to the framework how to apply, but self-talk, full of their own most proud vocabulary, listening to business function developers enveloping. We ask some questions, such as the business development problem, how to solve the framework? As a result, the framework developer argued with the business developer. The framework developer feels that this is simply not going to allow the client to be a pervert, and business developers say this is the situation. The framework developer says you can do this, the business developer says it's too much trouble, and the framework developer immediately answer back the problem? So both sides uncompromising, the framework also did not promote success.

I have a framework developer under my hand. His technical desire is very strong, in order to overcome technical difficulties, can not eat not to sleep. and technology sensitivity is very strong, learning is fast. So when I felt like he was a programmer, I took him to my men.

But there is a problem, he wrote the framework code, in peacetime development of business functions is very troublesome. What you may need is a spade, but he gives everyone n different lengths of different weights of different materials of the stick, n different shapes and different uses of the spade head. There will be n combinations of people. Not only did he write code for the old hyper-mission period, but it also made the user feel less helpful. It is complex to use, and there are too many places to be aware of when configuring this configuration. Business Development team colleagues are reluctant to use, rather than the code to write their own direct death. Extended also affects the use of business function development groups. Originally was to want to speed up their work efficiency. You promised to provide a feature for the business development team this week, but you didn't take it out. Delay the progress of others. You can not come out many times, others business development team is not as good as their own development, ask for their own.

I finally warned him: If you think you have enough skills, you have to prove that you can do it quickly. If you think you have enough skills, it's better to have a cow, and just provide a function to solve their problem. Don't do this. The proxy class, the aggregate class, is the only instance class. It is better not even the parameters, we call to write a code is OK. Even if you do well, you don't have to call your code, you can include it in the underlying framework, and you decide for yourself when and where the application needs to perform this action. If you think you are skilled enough, then when the business function needs change, you can ensure that the interface is still suitable for changes in the case, this is enough for you cattle. Don't let the people in the Business Development group follow you and change their own code, so the design sucks.

The boy listened to my words. Progress assurance, code interface concise. (Excerpt from the SOFTWARE Workshop: people walking the Tightrope)

2. A story that is familiar to everyone:

In the words of Unilever new batch of automatic soap packaging machine, often appear soap box is empty without soap, and at the end of the assembly line with manual inspection because efficiency problem is not likely and not insurance. This is not, an automated, mechanical, mechatronics and other professional doctor composed of solution team to solve this problem, not long they developed on the assembly line of the head of the automatic X-ray transmission inspection line, transmission inspection all the assembly line at the end of the waiting box of soap boxes, if there is free to use the robotic arm to take away.

Unfortunately, a Chinese township enterprises to produce SOAP also encountered similar problems, the boss ordered the online work must come up with a strategy, the handyman took an electric fan on the head of the assembly line, the final product blown, empty box was blown away, the problem to solve. (Excerpt from a discussion on toplanguage. ）

So

• There is a hammer in the heart, it is easy for their enslavement: in the face of the problem is not specific analysis, but the bottom of the head, no matter 3,721 first on the Golden sledge, and often still have a sense of accomplishment, but will be the real problem of their own to be solved behind the brain. never forget to remind yourself, "What is the problem?" "
• But there is no doubt that no hammer is absolutely impossible, no one will be foolish enough to nail nails. The point is to choose the right tool for you. This also requires that you always remember the scope of the tool when you learn it.

The right attitude should be:

Hammer in hand, no hammer in heart.

Allow me to explain this sentence specifically: Any tool has its scope and premise. However, when we learn the tool because of the investment of time, often in the emotional face of the tool produced too strong feelings, we have invested time, of course, the heart wants to be able to use these tools, so it is easy to forget the application of the premise, pleasantly no matter 3,721 on the Golden Sledgehammer to show their own bad. But if we change our attitude and just see it as another tool in our toolkit, we can objectively assess it and use it as it is-always remember what the problem is. Why is always before how.

There is another sentence that corresponds to the above (which I actually invented: D):

If you want to nail a nail, everything looks like a hammer.

In the case of plain English, if you focus on the problem you want to solve, what you see will present a side that you have not seen before.

Example:

1. Archimedes bathed for a lifetime, but only then, when he wanted to solve the crown density problem, he thought that the volume of the irregular object could be measured using the drainage volume (Eureka is Greek, meaning: I found it, I found it).

2. If you also like to see the "Monk", you will feel the problem in the heart, even to become a problem, the problem is their role-when Monk's subconscious is always thinking how, why, who did it these issues, all the information around the environment will show another face, a Details that are not normally noticed at all can also be the key to solving the problem, and seemingly irrelevant information can bring unexpected inspiration.

3. bentobjects

If you're like me, and you're used to putting questions in your brain for days, you'll definitely have a Eureka experience.

Or, if you like to focus on a topic for a while, you'll be reading the book material with the problem glasses, seeing things you don't normally see, and thinking differently than usual.

Turn yourself into a nail, this is the mystery of Eureka.

Eureka's story, focus can make you see things others can't see.