7 common features of an efficient programmer

Http://www.oschina.net/translate/seven-traits-of-effective-programmers

Guide: To be a great programmer, you need more than just the ability to write code that works. Justin James gives a few typical traits that programmers who can be the top players in the industry should have. To be an efficient programmer, you need to have a comprehensive quality that allows you to write effective code with the skills, experience and knowledge you possess. Some developers have some technical skills, but they can never become efficient programmers because they lack the other qualities they need. This article will give you the 7 qualities you must have to be a great programmer.

1. Proactively learn new technologies and non-technical knowledge Bad programmers start to learn knowledge only when they really can't. Good programmers take the initiative to learn new technical knowledge. Great programmers will not only learn new technical knowledge by themselves, but also learn non-technical knowledge and have an open mind to various sources of knowledge, rather than being complacent like some people. Specifically, bad programmers begin to learn XAML only when they participate in projects that use WPF; Good programmers learned XAML a year ago because he felt it was interesting, and great programmers read the design guidelines for WPF applications, Usability (usability) theory or something like that, so he can create a distinctive UI.

 

&nbs P;

2. Pragmatic and not dogmatic Strict adherence to those unwritten "programming rules" is often a luxury, and not many developers can afford. If your specification is not written by top developers, nor is it written under the guidance of top developers, I can assure you that you may not be able to afford it,, . I can often run into programmers who cannot or refuse to do a task simply because the practice of accomplishing this task is usually not accepted by best practices. Business requirements are rarely constrained by the technology used to implement the requirements; no one would say, "We shouldn't write this requirement into the spec, because the programmer has to write a very smelly piece of code to achieve this requirement." " At the end of the day, the programmer's task was to build a valid application, not a requirement to be technically perfect. I'm not defending the junk code. What I want to say is that there will always be times when you'll write some code that you'll never use as an example to show others the right way to do things. If there is only one way of writing, then this code is not bad code--   but make sure you have exhausted all the other possible scenarios.

 

3. Know how to find answers through research Finding answers through research is not just a matter of typing a few keywords into a search engine, or posting a question to a Web site like stack overflow or MSDN forums. I had a problem with the search engine that couldn't find the answer, and then I didn't have a decent answer to all the questions posted on my stack Overflow or MSDN forums, but I solved the problem that I had to keep the job going. I'm not a magician-I just know how to find the answer and how to find the root cause of the problem. The question of is situational, and if you rely on search engines or forums, you will waste a lot of time in various links and ultimately you won't get a real answer. To learn how to do root cause analysis, learn the knowledge of the underlying system to find other clues and solutions, but also to learn if there is a global understanding of the problem before it in-depth analysis.

 

4. Have a passion Don't like the job, you can't be the top player in the industry. There are also some programmers who just think of programming as a normal job, but if that's the case, you're less likely to do everything that leads to success. This view makes a lot of guys unhappy because they think it's a personal insult. "I am a very good programmer, but I have other important things to do, and I can't make the job my whole life." "I fully understand, and I have other, more important things." Although I hate to say that, when we are passionate about my work, I am willing (though not eager) to abandon my other more important things to finish the work at hand first. It is true that you do not want to be a master, not a personal insult. Your passion cannot be just one aspect of programming-you have to be passionate about your work, the technology you use, your boss, your projects, and so on. I've seen some very good and even great programmers who are mediocre in their performance, just because there are some conditions that are not appropriate. For example, they don't like the project at hand, or the technology used in the project makes them annoying. I used to be a programmer, and I worked with programmers like that. I don't like programmers from any angle. If you find this to be the case, you need to solve the problem immediately, either by digging out the work at hand or the interesting part of the project so that you can adjust your mood, or do not do it. Blame is not worth it.

 

5. Leave your ego outside the door Many developers are very conceited. Just being smarter, more knowledgeable or more experienced than some people doesn't mean you're a good person compared to those people. You have to respect others, listen to and think about other people's opinions, ask for help when you need them, and don't underestimate others.   You should also be more concerned about the team's victory and defeat, not just the honor and loss of your work. 6. The spirit of entrepreneurship The best developers will not be idle people. For them, the success of the product means more than just a fall in their salary. Because they are enthusiastic in their work, they work for a better development of the project and will indomitable.

 

7. Measure two times, the knife once ... But do not measure more than three times One of the worst mistakes a developer could make is not knowing what to do, just a opposing into the code. (It's even worse when they call it agile development, as if the word "agile" can make things better.) When great developers jump into the code, it's because the requirements specification is very similar to what they've done before. Great programmers are thinking, planning, and researching when they are faced with new problems. The most outstanding of the Developers will not fall into the "analysis paralysis" trap. They learn to be cautious about certain things (such as when it comes to money or personal data), and only these special areas are suitable for what I call "measuring three times". Anything more than three times will mean you're wasting your time (unless in rare cases, such as nuclear reactors, spaceships, hedge-fund accounting systems). It is important that Stop scheduling at a specific point in time, start coding, and then see where your plan needs to be adjusted accordingly. That, by the way, is one of the reasons why I became a fan of agile methods. The best developers I know will be willing to give up their plans when they are no longer appropriate or if they find their plans flawed.

 

This is the end of a journey ... Writing this article makes me feel a little sad. As a techrepublic writer for more than seven years, unfortunately it is time to temporarily unload my status as a freelance writer because our full-time job is really too busy. Just last year, I had to end up writing for the things blog and Patch Tuesday series, and now it has to stop software Engineer blog. I love the time I spent with TechRepublic. I am delighted to be able to recognize the readers, my co-authors and the TechRepublic staff. My editor, Mary Weilage, has always been a behind-the-scenes hero of the software engineer blog I wrote. It was he who made me look like a fool and a nerd, and he helped me correct a lot of grammatical mistakes on many occasions. Thanks to all the readers who read my article. I hope I can come back and continue writing for techrepublic in the future.

7 common features of an efficient programmer