What makes a good programmer?

techfounder Web development July 22nd, 2009 by Eran Galperin

Some casual surfing led me to this article from a couple of years ago, titled "How to recognize a good programmer". It was a nice read, but as many in the comments pointed out, the criteria the author set forth most likely describe himself and are not really useful as rules-of-thumb on how to recognize a good programmer.

It got me thinking though, on what are the attributes I consider useful in fellow programmers. So what makes a good programmer?

An analytical thinker

Programmers need to be problem solvers. The process of programming requires that we systematically break complicated problems down, plan and implement solutions and find / eliminate small inconsistencies in code (bugs).

Analytical thinking also manifests in the ability to follow complicated logic through disparate code segments and understand it. It allows us to grasp abstract concepts such as Object Oriented methodology and design patterns and implement it in practice.

Has his priorities straight

If I would ask you to rate the following according to priority, how would you order them?

  • Security
  • Maintainability
  • Usability
  • Performance
  • LOC (lines-of-code) count

Take a moment to think about that, and then consider:

  1. If you picked LOC count first, you failed big time in my book. In fact, LOC optimization can often go directly against the other metrics (such as maintainability). A lower LOC count should never be a goal, only a result of careful application of well factored architecture.
  2. If you picked performance first, you are probably the guy who keeps writing articles about how you should use a while loop instead of a for loop since it came out a few milliseconds faster in your benchmarks. You might be inflicted with a case of premature optimization.

    We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
    Donald Knuth

    Performance should only be good enough to satisfy the requirements of the application. Aside from caveats to well-known pitfalls (such as executing queries in each iteration of a long loop), performance optimizations should be deferred to the very last and even then should be used appropriately (profile ... profile ... profile ... optimize).

    The only exception to this is if you are primarily developing performance dependent applications (such as low-level system drivers).

  3. Security is on somewhat of a middle ground. Depending on the application and distribution model it can be completely useless or mission critical. It's mostly somewhere in between, and thus can't be ranked as number one.
  4. Maintainability is definitely one of the most important attributes of a software application. High maintainability allows you to improve other attributes (such as performance), when it is needed.

    Maintainability is the single most important factor for keeping productivity up and costs down. For a long time I strongly believed this to be the most important attribute of software design.
    However ...

  5. The most important attribute is usability. In the end, the worth of your application is only as much value as it delivers to the end-user.

    We should always remember - software is not written to serve its developers or the systems they run on. They are written to solve problems. If those problems are not solved, then the project is a failure.

    I wrote usability here as a more general term than just UI/UX effectiveness. Even a command line application or a background service has its usability factor in the sense of how well it answers a specific need.

Gets things done

In principle, it’s simple. You’re looking for people who are

1. Smart, and
2. Get things done.
Joel Spolsky

Quite possibly the single most important trait in a developer. You can excel at all the previous attributes and still be a mediocre programmer if you just can't get things done. One average but productive developer could easily replace several highly talented but slowly moving developers, depending on his responsibilities.

At the end of the day you definitely want more highly-productive developers than those who are high on theory but not actual work.

Does more than "just enough"

Getting things done is important. Getting things done "the right way" is even more important.

Constantly paying off your technical debt is crucial - if you keep accruing debt by "hacking" quick fixes that work now but are not maintainable, you only create the appearance of progress. In reality, the cost of getting rid of a large technical debt could become prohibitive before you know it.

Taking the time to constantly refactor code into a more maintainable state is the best way to prevent the spiral into project oblivion.

Responsible

A person could be a very capable programmer on technical ability alone, however if he does not own up to his mistakes and does not respect deadlines he could become a liability very quickly.

Responsibility also means to know where to let go of your ego for the good of the project. We developer often high large egos as we consider ourselves experts on many things. Putting the project first is a sign of a good developer.

Good human relations

Another all-around useful trait, this one applies to programmers as well. There is some stereotype that programmers are reclusive, unsociable creatures - programmers are still people ;).

In order to be a part of a team or handle clients, a programmer must have above basic social skills. Rudeness, arrogance, short-temper - do not have a place in a professional work environment. All it takes is one bad apple to ruin the mood for everybody.

That's about it

If you answer to all of the above, you are probably a pretty good programmer (and you are welcome to apply with us :)).

If you read the article I mentioned at the beginning, you might notice I didn't mention passion or technological diversity as qualifying traits. Simply put, I don't think they're very relevant to the quality of a programmer.

Passion is nice to have, however I've known many very professional and high-quality developers who were just content to go about their work professionally from 9 to 5 and then go home and have a meaningful and fulfilling family life. A programmer can definitely completely professional without being passionate about programming.

Technological diversity is another nice to have but not a prerequisite - as long as you are in command of the technologies you work with, a lack of diversity shouldn't affect you too much. Decision makers need to be well aware of all the options before starting a project, however nowadays the choice of technology simply is not that important.

You can achieve good results regardless of the programming language and database engine among other consideration. The biggest consideration should be the type of skills available to your personnel.

I hope to see more suggestions and thoughts in the comments on what you think make a good programmer.

Tags: , ,

Enter your email address to receive notification about new posts.

If you liked this article you should follow me on Twitter and/or share below:
  • Steve Reynolds

    I agree. Usability and maintainability are key. From a developers perspective, I always hated to come behind someone and then determine that just rewriting the whole piece of code was a better use of my time.

    Now that I’m a Project Mgr, it’s even more important because I’m dealing with developers during the project, during implementation and launch, and then with developers after the launch. It’s often the case that the actual developers are changing during the process and those that started coding aren’t the ones maintaining it.

  • Steve Reynolds

    I agree. Usability and maintainability are key. From a developers perspective, I always hated to come behind someone and then determine that just rewriting the whole piece of code was a better use of my time.

    Now that I’m a Project Mgr, it’s even more important because I’m dealing with developers during the project, during implementation and launch, and then with developers after the launch. It’s often the case that the actual developers are changing during the process and those that started coding aren’t the ones maintaining it.

  • http://goit-postal.blogspot.com Georgi

    Interesting post and I too agree. The question “what makes a good programmer” once brought me to the point which types of programmers are out there (if you want to read, here is the blog: http://goit-postal.blogspot.com/2006/10/different-types-of-programmers.html).
    Nevertheless, my favorites in your list are “analytical thinker” “gets things done” and – more and more necessary – “good human relations”. The latter is, in my opinion, at least as necessary as the other two ones, nowadays.

    Greetings, Georgi

  • http://goit-postal.blogspot.com Georgi

    Interesting post and I too agree. The question “what makes a good programmer” once brought me to the point which types of programmers are out there (if you want to read, here is the blog: http://goit-postal.blogspot.com/2006/10/different-types-of-programmers.html).
    Nevertheless, my favorites in your list are “analytical thinker” “gets things done” and – more and more necessary – “good human relations”. The latter is, in my opinion, at least as necessary as the other two ones, nowadays.

    Greetings, Georgi

  • http://lescinskas.lt Paulius

    I would disagree with this opinion. “Designers create for the people, developers – for computers”, one said.

    There are various developers, but in the teamwork there should be various people – designer, analytic, developer etc. and each should do its own job. And from this point of view, programmer should mostly do coding. If the programmer can do better in UI, visual design or analytic part, it means either this person is more than a programmer or other people are too weak.

  • http://lescinskas.lt Paulius

    I would disagree with this opinion. “Designers create for the people, developers – for computers”, one said.

    There are various developers, but in the teamwork there should be various people – designer, analytic, developer etc. and each should do its own job. And from this point of view, programmer should mostly do coding. If the programmer can do better in UI, visual design or analytic part, it means either this person is more than a programmer or other people are too weak.

  • http://www.techfounder.net Eran Galperin

    @paulius
    I’m not talking about programmers doing graphic / interface design. I’m talking about making sure the software works as intended, and recognizing that it’s more important than performance / security or any other specific metrics. This includes using different kinds of automatic / manual testing, which are vital for a product success.

    Many times I’ve seen developers miss critical usability issues (such as certain features crashing when used from the UI) since they were much more focused on other aspects than testing that the application works as intended.

    And programmers create for people too, which is exactly my point. We need to think of people as our costumers, not computers.

  • http://www.techfounder.net Eran Galperin

    @paulius
    I’m not talking about programmers doing graphic / interface design. I’m talking about making sure the software works as intended, and recognizing that it’s more important than performance / security or any other specific metrics. This includes using different kinds of automatic / manual testing, which are vital for a product success.

    Many times I’ve seen developers miss critical usability issues (such as certain features crashing when used from the UI) since they were much more focused on other aspects than testing that the application works as intended.

    And programmers create for people too, which is exactly my point. We need to think of people as our costumers, not computers.

  • Victor

    Though you wrote about Usability in more general term than just UI/UX but from my experience as Project Manager is that if programmers are given a clickable prototype, instead of just that big written specs, of what the end users will experience it increases their perspective and quality of product is much better.
    We use http://www.irise.com though tools like http://www.simulify.com or http://www.axure are also good.

  • Victor

    Though you wrote about Usability in more general term than just UI/UX but from my experience as Project Manager is that if programmers are given a clickable prototype, instead of just that big written specs, of what the end users will experience it increases their perspective and quality of product is much better.
    We use http://www.irise.com though tools like http://www.simulify.com or http://www.axure are also good.

  • http://www.techfounder.net Eran Galperin

    Thanks for links, Victor. Some nice stuff in there.

  • http://www.techfounder.net Eran Galperin

    Thanks for links, Victor. Some nice stuff in there.

  • http://plind.dk Fake51

    Overall, the criteria are good – it’s great to see the stress on things that are fundamental to being good at what you do, instead of focusing on specific things that may or may not be valuable in any given situation. It’s like the old question: would you prefer to hire a person that knows a specific thing really well, or a person that knows how to learn really well? If it’s the first, you should probably consider contracting work rather than hiring – otherwise you’ll be stuck with experts that can do one thing for you but nothing else.

    There’s one point I have a problem with, though: the priorities point. While lines-of-code typically come in last, you simply can’t rate the others without knowing the context. Are we dealing with code for financial institutes? If so, then security MUST come first: you don’t compromise on that, unless you want the media to write on how you lost (yet another) unencrypted backup with credit card numbers. In other words, whether maintainability, security or usability comes first depends on what you’re developing and who you’re doing it for.

    Regards
    Fake

  • http://plind.dk Fake51

    Overall, the criteria are good – it’s great to see the stress on things that are fundamental to being good at what you do, instead of focusing on specific things that may or may not be valuable in any given situation. It’s like the old question: would you prefer to hire a person that knows a specific thing really well, or a person that knows how to learn really well? If it’s the first, you should probably consider contracting work rather than hiring – otherwise you’ll be stuck with experts that can do one thing for you but nothing else.

    There’s one point I have a problem with, though: the priorities point. While lines-of-code typically come in last, you simply can’t rate the others without knowing the context. Are we dealing with code for financial institutes? If so, then security MUST come first: you don’t compromise on that, unless you want the media to write on how you lost (yet another) unencrypted backup with credit card numbers. In other words, whether maintainability, security or usability comes first depends on what you’re developing and who you’re doing it for.

    Regards
    Fake

  • http://www.techfounder.net Eran Galperin

    As I wrote in the article, the importance of security is dependent on the specific application (performance too). However, there is a big problem if the application is not usable or maintainable due to security concerns.

    There are exceptions that rescale those priorities, for sure. But for the general case, it’s important for the programmer to be aware of the end goals of the software product and not indulge in personal pet-peeves (such as performance optimizations or hacker-proofing).

  • http://www.techfounder.net Eran Galperin

    As I wrote in the article, the importance of security is dependent on the specific application (performance too). However, there is a big problem if the application is not usable or maintainable due to security concerns.

    There are exceptions that rescale those priorities, for sure. But for the general case, it’s important for the programmer to be aware of the end goals of the software product and not indulge in personal pet-peeves (such as performance optimizations or hacker-proofing).

  • http://plind.dk Fake51

    I whole-heartedly agree. However, the end goals of the software product do not match one particular point on your list – that was my point. The good programmer knows how to prioritize between different things and equally important: she knows what is the priority for THIS project.

  • http://plind.dk Fake51

    I whole-heartedly agree. However, the end goals of the software product do not match one particular point on your list – that was my point. The good programmer knows how to prioritize between different things and equally important: she knows what is the priority for THIS project.

  • http://leomangione.blogspot.com Leonardo

    Very good article, i agree with you and everything you just wrote, a programmer doesn´t need to know everything about usability, but it is a good thing if he knows what he CANT do instead. Kudos to Maintainability too. No one likes HARD CODE. Get things done people. :)

  • http://leomangione.blogspot.com Leonardo

    Very good article, i agree with you and everything you just wrote, a programmer doesn´t need to know everything about usability, but it is a good thing if he knows what he CANT do instead. Kudos to Maintainability too. No one likes HARD CODE. Get things done people. :)

  • http://johntantalo.com John Tantalo

    I’d rank “correctness” over “security”. Correctness, for me, includes proper input validation to prevent a program from entering invalid states.

  • http://johntantalo.com John Tantalo

    I’d rank “correctness” over “security”. Correctness, for me, includes proper input validation to prevent a program from entering invalid states.

  • http://www.leobaiano.com Leo Baiano

    I liked the article, the technology has been much more important in the development of a project but today I believe it makes much difference since most of the technologies have good alternatives to solve problems through software.

    Congratulations!

  • http://www.leobaiano.com Leo Baiano

    I liked the article, the technology has been much more important in the development of a project but today I believe it makes much difference since most of the technologies have good alternatives to solve problems through software.

    Congratulations!

  • http://www.jenkins-web.co.uk Ian Jenkins

    Excellent article. You say that getting things done and usability comes before maintainability and ultimately your absolutely right.

    However, where do you stand on developers who get things done, on the money every time, but when you look at the code it’s a mess, and maintaining the code is a nightmare?

    My thoughts are that yes, getting things done and usability comes first but only after a ‘maintainable threshold’ has been reached, i.e. the code is at least reasonably maintainable

  • http://www.jenkins-web.co.uk Ian Jenkins

    Excellent article. You say that getting things done and usability comes before maintainability and ultimately your absolutely right.

    However, where do you stand on developers who get things done, on the money every time, but when you look at the code it’s a mess, and maintaining the code is a nightmare?

    My thoughts are that yes, getting things done and usability comes first but only after a ‘maintainable threshold’ has been reached, i.e. the code is at least reasonably maintainable

  • http://www.techfounder.net Eran Galperin

    Maintainability is very high on my list, just a hair behind usability.
    Someone who gets things done but leaves a mess for others just isn’t worth it – you need people who hit all the right notes on the list I presented in the article.

  • http://www.techfounder.net Eran Galperin

    Maintainability is very high on my list, just a hair behind usability.
    Someone who gets things done but leaves a mess for others just isn’t worth it – you need people who hit all the right notes on the list I presented in the article.

  • Pingback: Making the Good Programmer … Better | Javalobby « Webtrails

  • http://israel-hightech-networking.ning.com/ Meir Amarin

    Nice post. Why not also publish it at:

    http://israel-hightech-networking.ning.com/

    Hope to see you there,

    Meir

  • http://israel-hightech-networking.ning.com/ Meir Amarin

    Nice post. Why not also publish it at:

    http://israel-hightech-networking.ning.com/

    Hope to see you there,

    Meir

  • Pingback: links for 2009-07-29 | Dan Silva

  • Pingback: Depois eu leio » Visão panorâmica

  • http://chr.ishenry.com chrishenry

    Depending on your business, doing “Just Enough” could be exactly what you want. When launching something new, you have absolutely idea what “enough” is. Do “too much,” and you can wind up sinking time and energy into a failure. Or go “too far” in the wrong direction.

    By doing “Just Enough,” you get out into the real world, get feedback, and iterate.

  • http://chr.ishenry.com Chris Henry

    Depending on your business, doing “Just Enough” could be exactly what you want. When launching something new, you have absolutely idea what “enough” is. Do “too much,” and you can wind up sinking time and energy into a failure. Or go “too far” in the wrong direction.

    By doing “Just Enough,” you get out into the real world, get feedback, and iterate.

  • Pingback: [Tradução] O que faz um bom programador? | Share Anything for Everyone in the World

  • Pingback: Cool articles – SEO, blogging, internet marketing(july19-august16 2009) « Stefanm, my link collection

  • http://rkulla.com ryan kulla

    Communication (including listening, not just speaking) is also extremely important. If the programmer can’t communicate with his managers, team mates and clients, it’s all over. This mostly falls under your “people skills” category but also extends into writing clear documentation, meaningful function and variable names and code comments for other programmers, etc.

    Great article.

  • http://rkulla.com ryan kulla

    Communication (including listening, not just speaking) is also extremely important. If the programmer can’t communicate with his managers, team mates and clients, it’s all over. This mostly falls under your “people skills” category but also extends into writing clear documentation, meaningful function and variable names and code comments for other programmers, etc.

    Great article.

  • http://www.techfounder.net Eran Galperin

    I consider documentation and meaningful function / variable names a part of the coding standards that any self respecting programmer should adhere to. That is mostly the maintainability part of the equation, rather then communications skills.

  • http://www.techfounder.net Eran Galperin

    I consider documentation and meaningful function / variable names a part of the coding standards that any self respecting programmer should adhere to. That is mostly the maintainability part of the equation, rather then communications skills.

  • Pingback: Desenvolvedores e plataformas poliglotas « Guilherme Garnier

  • Myemailum14

    I always liked programming and now that i have discovered that its associated with social outcasts, i feel confused as to whether my interest in programming is due to lack of some other things.

  • Smart

    Without conversation between team members there cant be any meaningful teamwork.

  • Pingback: Making the Good Programmer … Better | jamessugrue.ie

  • Pingback: O que faz um bom programador? | SWX Softwares - Desenvolvimento e Design Web