Apps discover

Seven traits of effective programmers

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.

J.Ja

Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.

About

Justin James is the Lead Architect for Conigent.

24 comments
ukikM
ukikM

a recipe for a brainless monkey

cmckinney
cmckinney

Thank you for everything. I read your column religiously and often pass it on to others that I think will like it. I always feel you are on the money and write from a true developer's perspective. I look forward to your return.

Justin James
Justin James

Thanks to everyone for the well wishes! I would have responded sooner, but I was at a conference all week, juggling a poor Internet connection and lots of issues in Production. :( J.Ja

jkameleon
jkameleon

He is blissfully ignorant of the fact, that his job is always done cheaper somewhere else. We live in the globalized world, and cheap labour is a lifeblood of the IT industry. PS: Good luck with your new career.

harriskam
harriskam

Thank you for sharing and contributing alot in TechRepublic.we wish you the very best in your endeavor.

ScottatStarSite
ScottatStarSite

It seems that when I would click on an iteresting title and read the article, your name would be there at the bottom. Going to miss your stuff. Wish you the best and hope to hear from you again soon.

choc101
choc101

Justin - I've never been one to really get into the comment wars I often see, but I've always enjoyed reading your articles/blogs. Over the past 4-5 yrs I've been reading them I've often felt a sense of commonality in your writings because sometimes I've felt alone on a island in some of the things I feel and your writing on top of being informative reminded me that I'm not the only one having these thought. Your blogs were always [mostly] short, to the point, very level headed and induced a level of thinking at times that I've needed when feeling a little stale. Thanks for your time and writings and all the best to you and your future endeavors.

dbFactor
dbFactor

...and thanks for all the fish!

hasanhd
hasanhd

I read most of your articles and learned many things from it. Thank you for your good works and wish you a very happy life. I hope to see your new articles soon :)

sysop-dr
sysop-dr

I've learned from you, will miss your insights. Ysrd

jim.bassett
jim.bassett

I think it is a good article but I disagree with the number 3 item because I have had just the opposite experience nearly the entire time I have work in this field (over 20 years). I have found solutions or hints in a few minutes to a solution by doing searches via Google or Bing or on various forums. I have also posted descriptions of an issue I am having with a coding problem and have received an answer or hint back in as little as five minutes or a few hours or the next day while I went on to work on something else. The author is correct about performing a root cause analysis and from that one knows how to enter information into a search engine or forum to help find a solution or get a hint to a solution to a problem

julieferguson
julieferguson

I have always enjoyed your articles as you have a good mix of theory and hands-on practicality. But, I completely understand the pull of many commitments. I hope to see your byline again. Best wishes for all that you do.

david.lloydjones
david.lloydjones

1.) Vegetarian programmers recognise pepperoni as an honorary vegetable. 2.) Realise that the younger generation don't understand "It's all been downhill since LISP." 3.) Able to write documentation maybe 30% more wordy and human than Bell Labs stuff, but with zero, nil, nada advertising garbage between the lines.

tech_sud
tech_sud

for all the wonderful posts you have done and wish you all the best for your future endeavors. Ahmed.

1000313975
1000313975

You have to be really smart. I have the other 7, but sadly I'm only slightly above averagely smart, and so as a software engineer I'll never be more than a good craftsman. :-(

barrynovak5
barrynovak5

Justin, thanks for all your contributions. I've enjoyed and learned quite a bit from reading your blog--and this from someone who's been programming since 1976. I was amazed how long you hung in there at TechRepublic given your workload. All the best in your career and family life.

Cmd_Line_Dino
Cmd_Line_Dino

I agree with the other commenters. Good articles and always worth reading. All the best in your journey.

Tony Hopkinson
Tony Hopkinson

I've become more effective as a result of your stuff over the years, whether its was what to do, or what not to do. :) Sad to see you leave. One less blog that isn't a shameless advert, not many left now on TR.

fretinator
fretinator

1. Makes effective use of acronyms. For example, A.A.A.A. - All Acronyms Are Awful. 2. Generates high-quality design documentation, preferable after the product is delivered to the customer. 3. Maintains proper familiarity with the C.M.M.I model, and generates artifacts demonstrating processes in increasing compliance to desired C.M.M.I. level. Considers this a much higher priority than actually performing said processes. 4. Diligent in completing time-tracking data that mimics supervisors requested charges. Does not allow actual tasks performed to interfere with this process. 5. Adept at task switching. For example, switching from Facebook to Eclipse in less than 1 second. 6. Amicable to team members, especially the team leader / project manager. Always smiles and nods at management requests, without letting these requests harms the quality of the end product. 7. Includes helpful, detailed comments in code artifacts. For example, properly documents un-sanitized code from new, billable team members "provided" by management: "/* Be sure to add header file, will_compile_and_run_when_hell_freezes_over.h */”.

Joey Indolos
Joey Indolos

I am going to sorely miss your byline Justin. Good luck with your full time job, and I hope your schedule eases off enough eventually for you to start contributing here again. It would also mean a better balance in your life.

cougar.b
cougar.b

Whenever I've seen your name on an article, I trust it and I read it with interest. When I was a senior tech writer, I worked for an architecture guy who you reminded me of, and to this day, 12 years later, I keep in touch. Good luck. Your development team has a brilliantly lucky find in you.

HAL 9000
HAL 9000

You get no prizes for killing yourself at work JJ. The more that you do the more that you are expected to do and eventually it gets your back up. ;) Col

Slayer_
Slayer_

For example, I used to comment everything, not anymore. Variable naming, that's gone, now sTemp, iTemp, dTemp, dtTemp are my favorite variable names. With the occasional iI or iA thrown in for good measure.

Justin James
Justin James

We have a small, tight-knit group. We're not the kind of place where being "the person who is effective" earns you a bigger pile of work. For one thing, I am managing a group of developers. Secondly, we work as a team. People all recognize that my workload is already quite high, and they work their tails off to take load off of me. The fundamental issue is that we've been doing a lot of really big, important, complex changes, and I'm the only one who really has the skill set for so much of it that it mostly all is in my lap. Luckily, we've cleared through it, have one or two more major issues (which I believe I have fixes for), and we're in the clear going forwards. :) J.Ja