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?
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
Programming
- 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
Experience
- languages with professional experience
- platforms with professional experience
- years of professional experience
- domain knowledge
Knowledge
- tool knowledge
- languages exposed to
- codebase knowledge
- knowledge of upcoming technologies
- platform internals
- books
- blogs
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.
and
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:
Things I really don't care about.
In the teams I've worked with, I've noticed the following roles:
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?
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:
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.
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.
