7 common traits of effective programmers

Introduction: To be a great programmer, you need more than just being able to write code that works. Justin James gives several typical traits that programmers who can become the best in the industry should have.

To be an effective programmer, you need to have a combination of skills, experience, and knowledge to write effective code. Some developers have some technical skills, but they can never be effective programmers because they lack the other qualities required. This article will give you the 7 qualities that you must have to be a great programmer.

1. Actively learn new technical and non-technical knowledge

Bad programmers only start learning when they are at their wits' end. Good programmers take the initiative to learn new technical knowledge. Great programmers not only learn new technical knowledge on their own, but also learn non-technical knowledge, and have an open mind to various sources of knowledge, instead of being self-satisfied like some people.

To be more specific, a bad programmer starts learning XAML only when he joins a project that uses WPF; a good programmer learned XAML a year ago because he finds it interesting; and a great programmer also reads the design guidelines for WPF applications, usability theory or some similar learning course, so he can create an outstanding UI.

2. Be pragmatic but not dogmatic

Strict adherence to the unwritten "rules of programming" is often a luxury that few developers can afford. If your specifications were not written by or under the guidance of the best developers, I can assure you that you probably can't afford it either.

I often come across programmers who are unable or refuse to do a task simply because the way to accomplish that task is not generally accepted by best practices. Business requirements are rarely constrained by the technology used to implement them; no one says, "We shouldn't put this requirement in the specification because to implement it, the programmer will have to write a piece of stinky code."

At the end of the day, a programmer's job is to produce a working application, not to be technically perfect. I'm not defending bad code. What I'm saying is that there will always be times when you write code that you will never use as an example to show others the right way to do something. If there is only one way to write it, then it's not bad code - but make sure you have exhausted all other possible solutions.

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, nor is it posting a question on a site like Stack Overflow or the MSDN forums. I've run into problems that I couldn't find answers to in search engines, and all my Stack Overflow or MSDN forum posts didn't yield any decent answers, but I still solved the problem and was able to continue working. I'm not a magician -- I just know how to find answers, how to get to the root cause of a problem.

Many questions are situational, and if you rely on search engines or forums, you will waste a lot of time browsing links without getting the real answer. Learn how to do root cause analysis, learn the underlying systems to find other clues and solutions, and learn how to analyze the problem in depth after having a global understanding of the problem.

4. Have a passion

You can't be the best at something if you don't love it. There are some pretty good programmers who just treat programming as a job, but if that's your attitude, you're less likely to be willing to do all the things that will lead to your success. This statement offends a lot of people because they take it as a personal insult. "I'm a good programmer, but I have other important things to do, and I can't let my work be everything to me." I totally get it; I have other more important things to do. As much as I hate to say it, when I'm passionate about my work, I'm willing (though not eager) to put aside my other more important things to get the job done first. To say you can't be the best if you're not willing to put your heart and soul into it is not a personal insult, it's just a fact.

Your passion can't just be about programming - you have to be passionate about your job, the technology you use, your boss, your projects, and so on. I've seen very good and even great programmers become mediocre simply because some conditions weren't right. For example, they didn't like the project they were working on, or the technology they were working on was off-putting to them. I've been a programmer like that, and I've worked with programmers like that. I don't like programmers like that in any way. If you find yourself in this situation, you need to address it immediately, either by finding something interesting about the job or project that makes you happy, or by not doing it anymore. It's not worth it.

5. Leave your ego at the door

Many developers have big egos. Just because you're smarter, know more, or have more experience than someone else doesn't make you a good person compared to them. You need to respect others, really listen to and consider their perspectives, ask for help when you need it, and not look down on others. You also need to care more about the success of the team than you do about your own work.

6. Have an entrepreneurial spirit

The best developers are not idlers. For them, the success of the product means more than just their salary. Because they are passionate about their work, they work for the better development of the project and will never stop moving forward.

7. Measure twice and cut once... But do not measure more than three times

One of the worst mistakes a developer can make is to just jump into code without really knowing what to do. (It's even worse when they call this Agile Development, as if using the word Agile makes it any better.) When great developers jump into code, it's because the requirements spec is very similar to something they've implemented before. Great programmers think, plan, and research when faced with a new problem.

The best developers don't fall into the trap of "analysis paralysis." They know to be cautious about certain things (like when it comes to money or personal data), and only those special areas are suitable for what I call "measure three times." Anything more than three times means you are wasting your time (except in rare cases, such as nuclear reactors, spacecraft, and hedge fund accounting systems).

It's very important to stop planning at a certain point, start coding, and then see where your plan needs to be adjusted. This, by the way, is one of the reasons why I'm a fan of Agile methods. The best developers I know are willing to abandon a plan when it no longer fits or when they find it flawed.