an article by Justin James of TechRepublic
Takeaway: Being a great programmer involves more than writing code that works. Justin James lists the hallmarks of programmers who rise to the top ranks of their profession.
In order to be an effective programmer, you need to possess a combination of traits that allow your skill, experience, and knowledge to produce working code. There are some technically skilled developers who will never be effective because they lack the other traits needed. Here are seven traits that are necessary to become a great programmer.
1. Learn new tech and non-tech skills of their own accord
Bad programmers only learn things when it’s absolutely necessary. Good programmers learn new technical skills proactively. Great programmers not only learn new technical skills on their own but also learn non-technical skills, and have an open mind to sources of knowledge that others may shut out.
To put it in concrete terms, the bad programmer learned XAML when they started a project using WPF; the good programmer learned it a year before because it looked interesting; and the great programmer also read about the design guidelines of WPF applications, usability theory, or some similar course of study so they could make exceptional UIs.
2. Are pragmatic, not dogmatic
Rigid adherence to the unwritten “rules of programming” is usually a luxury that very few developers can afford. I can almost guarantee that if your specs are written by or influenced by someone who is not a top developer, you are not in this group.
All too often, I encounter programmers who cannot or refuse to do the work because the answer is not in the list of commonly accepted best practices. Business requirements are rarely constrained by the technical consequences of implementing them; no one is going to say, “maybe we shouldn’t include that in the spec, because the programmer will have to do something that has a bad code smell to it.”
At the end of the day, the programmer’s job is to produce a working application, not technical perfection. I am not advocating writing garbage code. I am saying there will be times you will write code that you would not show someone else as an example of how things should be done. It’s not bad code if there’s only way to write it — just make sure you have exhausted your other possibilities.
3. Know how to research for answers
Researching for answers means more than typing several keywords into a search engine or posting a question at Stack Overflow or the MSDN forums. I have entered problems into search engines that generate no results, and every question I posted on Stack Overflow or the MSDN forums never got anything resembling an answer, yet I solved the issues and moved on. I’m not a magician — I just know how to find answers or discover root causes.
Many problems are situational, and if you depend on search engines and forums, you can waste a lot of time going down a rabbit hole and possibly never getting a solution. Learn to perform root cause analysis, learn enough about the underlying system to look for other clues and solutions, and learn to take a long distance view of an issue before deep diving into it.
4. Have passion
You cannot rise to the top in this profession without loving the work. There are some very good “it’s just a job” programmers (I’ve been one at times), but if that is your outlook, you won’t be willing to do whatever it takes to succeed. This idea gets a lot of folks in a huff, because they feel it is a personal insult. “I’m a good programmer, but I have other priorities and can’t make work my life.” I understand completely; I have other priorities too. As much as I hate to say it, when I am passionate about my work, I am willing (though not eager) to abandon my other priorities to finish the job. It is not an insult to say that if you aren’t willing to pull out all the stops you can’t be the best, it is a fact.
You must be passionate about more than programming — you must also be excited about your job, the technology you are using, your employer, your project, and so on. I have seen very good and even great programmers operating at mediocre levels because something was not a good fit, such as they hated the project or were using a technology they disliked. I have been that developer, and I have worked with that developer, and I don’t like it from either side of the fence. If you find yourself in that situation, you need to address it immediately by discovering something about the job or project to get psyched about, or get out of there. It’s not worth it.
5. Leave their egos at the door
Many developers have huge egos. Being smarter, more knowledgeable, or more experienced than someone else does not mean you are better than that person. You need to treat people with respect, listen and truly consider another person’s ideas, ask for help when needed, and don’t look down on anyone else. You should also care more about whether the team succeeds than if you get credit for your work.
6. Have entrepreneurial spirits
The best developers are not drones. They have a true sense of entrepreneurship and feel ownership in the product. To them, the product’s success means more than just the continuation of their paychecks. Because they have emotional skin in the game, they work for the good of the project, and go the distance.
7. Measure twice, cut once… but do not measure more than three times
One of the worst mistakes a developer can make is to dive headfirst into code without any idea of what they are doing (it’s even worse when they call this Agile, like trying to paint it as Agile makes it better). When great developers jump into coding, it is because the specs are very similar to a pattern they implemented before. When great developers are confronted with a new issue, they think, plan, and research.
The best of the best developers do not let themselves get sucked into the “analysis paralysis” trap. They know to be more cautious about some things (e.g., anything that touches money or personal data), which is why I say it is fine to “measure three times.” Anything past three times, and you are just wasting your time (there are very rare exceptions, such as nuclear reactors, spacecraft, and hedge fund accounting systems).
It’s important to stop planning after a certain point and start coding, and then see where you need to adjust your plans. Incidentally, this is one reason why I’ve become a big fan of Agile. The best developers I know are willing to sacrifice a plan if the plan is no longer suitable or is discovered to be flawed.
And a journey ends…
It saddens me to write this article. After more than seven years of being a TechRepublic contributing writer, it has unfortunately become time to take down my freelancer shingle for now, because I am extraordinarily busy at my full-time position. In the past year, I had to pull back from my TechRepublic writing commitments for the 10 Things blog, the Patch Tuesday series, and now the Software Engineer blog.
I have loved every moment of my time with TechRepublic, and I have enjoyed getting to know the readers, my fellow contributing writers, and the TechRepublic staff. The hidden hero behind my writing for the Software Engineer blog has been my editor, Mary Weilage, who has kept me from looking like a fool, a jerk, and a grammatically-challenged person on numerous occasions.
Thanks to all of you for reading. I hope to be able to return to writing for TechRepublic in the future.
