Answer by Glyn Williams:

Many engineers think that the quality of a programmer, is their comprehension of some complex thing. Their mastery of best practice. Their dominance of killer methodologies….  These are what I call “inputs”. These are things programmers put into a project.

Artists don’t see the world like this. Artists tend to judge other artists by their body of work.   They make a judgement, not on methodology but on output alone. They look at the outcomes.

In my view, the artists have this right.

We should judge good programmers by the outcomes:
Did the project ship?
Did it ship on time?
Was the program stable? - and so on. Because this is what matters more than the other stuff.

I can hear the engineers howling in protest. What about the quality of code? What about <insert fashionable technique> methodology?  Reusability, Unit tests etc.

The thing is, good programmers will indeed use those methodologies. Just as good artists will employ the right sort of brush technique.
But the truth is, so do bad programmers and bad artists.

Good programmers ship.  Bad programmers congratulate themselves about clever methodologies, while missing deadlines.

How do you identify a good programmer?

How do you identify a good programmer?