quality & context

The quality of the code I write is very dependent on the team I’m in.

The quality of my thinking about software is very dependent on the team I’m in.

These are both observational statements. I don’t have metrics. I didn’t measure myself. I can only really use my sense of achievement, technically, or lack of it, and my sense of the quality of the code I produced. But that latter sense of quality is based on my sense of my use of the language, the code as poetry, not in measured metrics, except in that it did what was wanted by the people who asked me to write it.

Now, I like to think I’m pretty good. In terms of my own criteria for pretty good at programming, I am pretty good, unsurprisingly. I’m not the best, by my own criteria, by a long shot. That unawarded achievement goes to the designers, original and ongoing, of the languages, and the guys who really use well to produce seriously good quality products.

But the clue to the problem with this belief is in the statement ‘by my own criteria’. Who doesn’t believe they’re pretty good at what they do, professionally? The problem is those criteria.

This problem is seen elsewhere. Most car drivers think they’re pretty good, especially the crap ones. Car driving can be measured objectively, such things as breaking the rules of the road, & involvement in accidents, can reveal relative quality. Yet the drivers who are objectively crap tend to think they’re not. So, me thinking I’m not a bad programmer is not a sign of being not a bad programmer: if anything, it’s a hint of the opposite.

So I need metrics to measure my skills, and to help me improve them. I’ve access to the research; I’m a member of the ACM and the IEEE. Perhaps I should get my finger out and go look’see. It could be painful.

: : blog : : subject  year : :