Possible Duplicate:
How Can I Know Whether I Am a Good Programmer?

There are a number of questions here about recognising or considering someone as a good/bad programmer. These are all subjective.

What I'd like to know is if there is a way to measure this. I realise there will and should be a subjective element to it. But is it also possible to have some actual numbers to back up (or contradict) such an assessment?

  • 26
    Shoe size. Works every time. Feb 23, 2011 at 5:25
  • 4
    StackOverflow rep.
    – SLaks
    Feb 23, 2011 at 14:06
  • 7
    Throw them in a pond. If they sink and drown, they are good programmers. If they float, they are bad programmers.
    – user1249
    Nov 30, 2011 at 22:28

10 Answers 10


The Programmer Competency Matrix is a notable resource amongst programmers. It lists criteria of 4 proficiency levels for 32 kinds of programmer competencies (skills) which are in turn grouped in 5 sections:

Computer Science

  • data structures
  • algorithms
  • systems programming

Software Engineering

  • source code version control
  • build automation
  • automated testing


  • problem decomposition
  • systems decomposition
  • communication
  • code organization within a file
  • code organization across files
  • source tree organization
  • code readability
  • defensive coding
  • error handling
  • IDE
  • API
  • frameworks
  • requirements
  • scripting
  • database


  • languages with professional experience
  • platforms with professional experience
  • years of professional experience
  • domain knowledge


  • tool knowledge
  • languages exposed to
  • codebase knowledge
  • knowledge of upcoming technologies
  • platform internals
  • books
  • blogs
  • 15
    ...notable, but definitely neither great nor the last word. Just for one point, it places far too much emphasis on breadth of knowledge, and far too little on depth. For another, its "cumulative" requirement is ridiculous, at least in places. Does he honestly believe I'm not even a "level 0" programmer because I've never owned a single "21 days" or "24 hours" or "for dummies" book? Having studied Knuth, Wirth, K&R, etc., before those were being published renders me ignorant and incompetent? What nonsense! Feb 23, 2011 at 5:47
  • 1
    @Jerry: Completely true. This is merely the equivalent of an IQ measuring intelligence (i.e. it'll effectively distinguish between the great and the dismal programmers, but wouldn't be accurate for those lying in the middle.
    – J.K.
    Feb 23, 2011 at 6:02
  • 5
    @Johathan Khoo: I'm not sure it has much (if anything) to qualify greatness either. I see no spots for "invented an algorithm that's now in wide use", or "wrote [or contributed to, or even proofread] a widely recognized reference book", or anything on that order. Feb 23, 2011 at 6:11
  • 8
    Perhaps wee need a "programmer measurement"-measurement?
    – user1249
    Feb 23, 2011 at 11:05
  • 1
    Worth mentioning that the competency matrix measures potential, not excellence. I've worked with too many really smart developers that weren't productive. Some of them were burnt out, some wouldn't stoop to problems that were below them, and some were just lazy. Being brilliant and having a lot of experience doesn't mean you'll make a substantial contribution. Good programmers contribute. May 12, 2011 at 15:07

Eventual Efficiency

Davy Brion says:

The only way to objectively measure this is to define a new metric which holds into account the extra effort that will be introduced later on.I'd call this metric Eventual Efficiency.


Unfortunately, we'll probably never get to the point where we can actually measure the Eventual Efficiency of developers.

From this article

I tend to agree. But since we need something "Peer reviews" and a competency matrix will have to do. For the matrix I would not go with a general one but put one together that matters for my organisation. And it would include only things you can measure or grade. Suggestions like:

  • peer reviews
  • basic knowledge (ask questions about the programming knowledge that is relevant for your organisation)
  • problem solving
  • experiences sofar
  • presentational skills (doesn't need to be a real presentation but at least the programmer needs to be able to motivate his choices)
  • domain knowledge
  • extra knowledge besides the core competency (project management, infrastructure, security etc. )
  • shoe size of course (the smaller the better)
  • if it is for evaluations the accuracy of the programmers personal planning (when he/she says it will be done in 3 days, is it in general done in 3 days.
  • if it is for evaluations does the programmer help others
  • if it is for evaluations does the programmer also is interested in solving problems outside of his own responsibilities

Things I really don't care about.

  • lines of code obviously
  • meeting external dead lines
  • the ability to say a lot of buzzwords and put them in a sentence

In the teams I've worked with, I've noticed the following roles:

  • The developer that fixes the bugs no one else can fix
  • The it-works-on-my-machine developer
  • The cinematographer
  • The developer that reduces 1000 lines of code to 100 that are much easier to understand
  • The prima donna
  • The developer that can break a huge complex problem down into small manageable pieces
  • The write-once developer - for some reason, they get it right the first time with very few bugs
  • Donna
  • The architect that can visualize data moving from system to system to system
  • El Gaucho
  • The process tinkerer that's constantly improving the way we build, test, and deploy
  • The sandbagger

There are no written rules as to who qualifies for each role, yet everyone on the team knows who they are. Formally or not, we're all measured and we all understand the result.

One interesting observation is that a programmer's worth sometimes goes unnoticed until he or she finds the right team. Likewise, a very productive programmer might stink in a different team. I think team productivity is a more interesting measurement and it's simple: Do they ship often, on time, and without a hassle?

  • 8
    cinematographer? Donna? El Gaucho? sandbagger?
    – ozz
    Feb 23, 2011 at 9:26
  • 5
    For those with a different cultural background - like me - it would be nice if you explained all the roles. Single word explanations are hard to understand.
    – user1249
    Feb 23, 2011 at 11:08
  • 2
    "yet everyone on the team knows who they are": I seriously doubt your "prima donna" knows they're a prima donna. It really sounds like your personnal opinion about your colleagues to me, not at all like a measure done by the team as a whole. Feb 23, 2011 at 11:10
  • 1
    You forgot the ROAD warrior. (retired on active duty - just waiting for the paperwork) Feb 23, 2011 at 12:55

Steve McConnell, who wrote Code Complete, uses a Professional Development Ladder.

The top level, master, is defined as

The employee performs reference work in an area and has deep experience across multiple projects. The employee has generally taught seminars or classes or has written papers or books that extend the body of knowledge. The employee provides industry-level leadership and is recognized outside Construx [McConnell's company] for expertise in the area.

More details on his website


Here are some criteria I would use:

  • A good programmer in a given language will understand every single line in his projects in that language (including comments), and can explain why each line is necessary and what would happen if any line is removed.
    No magic incantations or cargo-cult clipboard usage.

  • A good programmer will understand how and when his functions are called by external code.
    (When dealing with UI frameworks or threading)


I've used Dreyfus Modelling very successfully in a number of different programmer-related skills. Dreyfus Modelling looks at five levels of competency:

  • novice
  • experienced beginner
  • competent (I tend to use "practitioner")
  • knowledgeable practitioner
  • expert

The two to pay most attention to are the novice and practitioner levels. Novices learn by following practices step-by-step. Competent practitioners are safe to try things on their own. It's like driving, in that you start very consciously, following instructions. Eventually you get your license. You're still quite likely to have an accident, but you probably won't kill anyone. Knowledgeable practitioners tend to lose all conscious effort required, and experts have a sound understanding of the theory involved, maybe teaching or doing something extraordinary with it.

I usually assign the numbers 1 to 5 to these, to get a numeric result. It's very useful for using to measure the results of trainers and coaches.

You can use this model for every aspect of programming - TDD, continuous integration, language, OO design, etc. Just work out how people start trying a skill and what they do differently when they're successful. You may need to go seek some successful people to get an idea.

A word of caution, though. This can only be used as a personal measure. If you try to use it to, say, work out how much people should be paid, it will cause hell (but I believe any metric will do so anyway). I find it most useful to use as a roadmap, in conjunction with coaching to help people work out where they'd like to be learning more and what resources are available to them to do so.

I don't believe it's possible to get accurate measurements, because of the ability to game the system to make yourself look better than you are. I do believe that if you keep this stuff personal and private, and focus on strengths rather than weaknesses, a team can improve rapidly and dramatically, wherever they started from.


I couldn't define a list of qualities or fields of expertise that define a good programmer. But I could certainly point one out if I had worked with them for six months.

I don't even know if that is possible to codify, but I bet most established teams you could ask everyone separately the question "who is the best programmer here" and they would all give the same answer.

Actually, that would be a really interesting survey to do. Scientists should totally get on that one.


Yes and no. In theory it's possible, in practice I suspect it's not something you can do in an efficient manner (that is any benefit you might gain from it would more than offset the cost incurred in doing so).

But to give you an example of the sort of issues you face, try and define "good" (and indeed "programmer").

It will vary from company to company and indeed situation to situation. Is it the person who provides the technically best solution? Or the fastest / cheapest solution? Or the one which makes the customer happiest? Or the one which makes management happiest? And even that will likely depend on what the precise problem is in this instance.

And while the person is a programmer, what if they find a really great solution that is more in the realms of system administration (a free third party product perhaps)? I'd say that it should be viewed as a great solution but I bet it's not going to fit well into any programmer metrics.

  • +1 I'd add another indicator.
    – JustinC
    Feb 23, 2011 at 14:49
  • +1 I'd add another indicator.
    – JustinC
    Feb 23, 2011 at 14:49

I guess the answer depends on your point of view : do you mean, a "good programmer" as a colleague, as somebody who is going to replace him, as his manager, as his client...

As a programmer, I'd say the first quality is perseverance. It's allright if you don't know everything (who does, anyway ? I'm pretty ignorant in computer sciences since it's was not what I studied initially, so I'm very tolerant). But not looking for a solution is really something that bugs me.

So I'd say a good programmer is always trying to fix problems. A great programmer is someone who spent a lot of time doing that.


Tbe best sign of a good to great programmer is one, who always assumes there is something more to learn and to master, and practices strong self-discipline to make sure every step of their craft is done well...

To me it's the desire to learn, the desire to master your craft, and have pride in your work, and the ability to view the long term consequences of the process you use.

Not the answer you're looking for? Browse other questions tagged or ask your own question.