As an engineer with 15 years of experience in the development, first let me start "naive child", it is the concise sentence:
Excellent code, is more capable of expression (expressive), but not impressive (impressive).
I remember myself am very confused, and the ability to express more impressive, what are their differences on the nature of it?
In fact, more expressive means clear, specific and concrete. Therefore, a better ability to express some code needs to solve a specific problem. Behind the time and effort to write a piece of code like this pay is very clear, clear, specific goals, and this code must also be able to truly achieve this goal.
While impressive, it is said to leave a visible mark or marks on the individual process of writing code. Period of their complex structure, mixed with a variety of codes esoteric algorithms, may be able to attract people's attention, praise and applause for you, fully satisfy your vanity, but also could be transformed into that to succeed you in the future to continue maintaining the code the anger felt by engineers. If he happens to be a bad-tempered and know where you live person, then what will happen next, I am afraid it will not make you feel so happy.
This is the programmer should choose wisely rather than smart reasons. A savvy kind of development engineers need to have the ability to be able to foresee what their behavior under what circumstances would the consequences, and can "write their own is what kind of code," right, "so why should write", and "these codes in the future may be how evolution" has a clear awareness of these three problems. Simply put, smart engineers will not do it "too late" type of fire development work, they believe that it should solve the problem once and for all when writing code.
The "smart" engineer is just the opposite, they start work to develop fast, but also know how to use a variety of methods dishonest to make the code may look "normal work." Clever engineers have an ability to quickly via "shortcut" to solve any of the problems at hand. But as time goes on, those constantly by the "band-aid" and "tape" cumulative build up the fragile building codes, will one day collapse, then let all the people to pay through the efforts of all feel shame. Like the famous American software engineer, Construx Software company founder Steve McConnell wrote to in his 1993 book "Code Complete" in:
Programming, can not work like that for the United States Central Intelligence Agency, sly, opportunistic and does not do any good.
Smart development engineers never do things both ways, they write code dull but simple and easy to understand, not too out of color, but it will not go wrong.
In addition, there are other smart engineers work worth studying habits.
ThoughtWorks chief scientist Martin Fowler thought,
Anyone, including fool can write code that a computer can understand, but only the best programmers to write code that other people can understand.
Programmers sometimes inexplicable feel need to prove what thing, or is required to show their ability to demonstrate to others that they can now qualified jobs. This idea will lead them in the process of trying to solve every problem in preference to those more complex, more difficult approach, ignoring a tidy front and is the most direct and simple solution. It is very easy to make every development engineer, but also the worst mistake.
Savvy programmers would simply write code that is easy to maintain in the follow-up work, optimization or reconstruction, without any wonderful or unexpected problems, other colleagues looked at the code can be accurately aware of its intentions and problem-solving ideas. Those new, unusual algorithm, or the development of ideas, adding programmer askew stayed up all night tired but proud expression, sometimes superiors or colleagues seems really great. But when it triggered a disastrous failure, it may also be more "dazzling."
No matter what time, as long as you're writing the code, if your ego influence begins to tempt you, then you'd better ask yourself this question: "If you leave the job two months, waiting for you to come back to continue work, but also be able to understand the code? "If your answer is yes, then you can fully in accordance with their own ideas and willingness to write this code, just ask for your mercy ── for successor this code does not require too much explanation, please add comments in the right position, reasonable for a variety of variable naming, and as much as possible to be modular processing.
High quality code, just as a joke. If you must pass in order to make additional explanation other people understand, that this is not a good section of the code.
The late Dutch system of scientific experts, well-known software development engineers, computer science pioneer Edsger W. Dijkstra has proposed,
Focus on "why" rather than on "what" makes you a better development engineer.
There are many ways to optimize the code, such as more memory can be called, or run faster, or using different algorithms and logical thinking. Which method is not useful, as long as the objective conditions permit, smart development engineers will decide wisely. But before starting any optimization work, they will strictly abide by "" Do not "test":
Why would I do that? These codes written enough, okay? Understand clearly how to use the program will be the case as well as its operating environment, if you run faster, then it will be any good? The question you should ask yourself in advance.
If a very important program to run slowly, while the development team and expect to maintain robustness, accuracy, clarity while allowing it gets faster when the optimization work in order to show significance in pay and costs. However, a quick run but got the opposite result with the expected program and still not make any sense. Efficient code optimization can often bring more benefits, but if you did not follow the right way to optimize, the result may be not only useless but also comes with more bugs.
Whether you do the work on the optimization of what should be the effect of a significant, measurable. Do not always rely on intuition, instinct is always bad compass.
Reuse instead of writing new code
Vic Gundotra, senior vice president of the company before Google Watch have raised a crucial question of point of view:
Before writing code, I have to go figure out what they really want.
Savvy programmers prefer to look at the code, and then look around for a viable, existing solutions. While some engineers prefer "to rebuild the right way" in. In most cases, these people are wasting time in making repeated rounds on this matter.
Do not be afraid to spend time searching on the Internet or looking at your code database solution that has been practiced in will help you to learn and master the general method to solve similar problems, and the associated various pros and cons. That's why savvy engineer before writing the code will take longer to see the code. Because the rewrite section of the new code, always to spend more time, cost and effort. Unless absolutely necessary, do not do it.
So when you need to complete a task, it is best to go look it up if someone has done something to solve similar problems, and this is not a shortcut to get smart, which is to save unnecessary consumption of energy.
Challenge yourself
Ancient Greek philosopher Aristotle once said,
If you are doing and there is no challenge, it will not let you do it better.
Savvy programmers will always challenge themselves, more precisely, to seize every opportunity to challenge the code they write their own. They always humbly recognize that no code is perfect, only better code.
Savvy programmers will not be easy to stay in their comfort zone, and then repeat the implementation of the deployment continue to work in the same mode. They consciously avoid their code parameters disturbed dogmatic ideas, and always will find suitable ways and means to do things better, even if it means the need to take the time to learn something new, they will still go all out.
Savvy programmers will not be attracted to grandiose ideas with fancy features. They can be very pragmatic and recognize that the perfect solution does not exist, each one outstanding feature or magic tricks are accompanied by various drawbacks.
Courage to help others
Ancient Greek playwright, poet Sophocles tragedy once believed,
If each of us can really do to help each other, it is no more need for good luck.
As a programmer, since that it will always be more rational, clever kind of person. In fact, there are a lot of development engineers really gifted. But sometimes, programmers will be over-confident that he is omniscient, can rely on their brains to solve any problems. After all, no one wants to admit at the workshop, "This I will not," or is about to deploy new functionality know nothing about.
So, they kept telling myself: "I will think of ways to solve I used to always rely on their own strength, and still can continue to do so.."
However, savvy programmers did not think so. They know just when to help and when to remain independent thinking. They knew that any delay can make the whole thing to the direction of uncontrollable and eventually evolved into everyone on the team will look at the project deadline in endless anxiety and pressure very desperate continually approaching . And this is the smart programmers are brave enough to expose their deficiencies in a timely manner and cause of others for help when necessary.
To others for help is not a question of their own capabilities, but in fact it reinforces others trust and confidence in you, because they see that you can do whatever it takes to perform their duties on time and deliver the work results in line with expectations. Your impression in the minds of others, will also become an aggressive, confident, and want to get better and better every day development engineer.
As India Award winner for best female presenters, actors, models Kubbra Sait said,
Ask questions is the first step to start to get better.
