Programmer Musings

On Proficiency

In order to become proficient at any activity, a person needs four things:

• aptitude
• interest
• knowledge
• skills

To some extent, you should be able to judge a person's proficiency by measuring each of the four attributes.

The first of these is the only one that a person has no control over. If you don't have the aptitude (or talent or knack) for an activity, no amount of the other attributes will make you truly proficient. For example, very few programmers have the physical aptitude to play professional sports. No amount of interest or training will make one of us into a linebacker for the NFL. In most cases this isn't a problem, because most people that have no aptitude for an activity either have no interest in it or lose interest in it after repeated failure. This is not a bad thing because different people have different aptitudes.

Interest is the quality that usually causes an aptitude to be noticed. If you have a true talent for music, but no interest, you probably will not become proficient in that area. Unlike aptitude, interest can change over time. For instance, a person can be exposed to an activity and find that it comes easily and that person's interest increases. On the other hand, an activity that has always held your interest may turn out to require more work than you plan to supply and your interest can wane. Aptitude and interest together seem to be a requirement of becoming proficient in an activity.

Most activities require some abstract knowledge to become truly proficient. Different activities require differing quality and quantity of knowledge. A person can acquire this knowledge through books, classes, and reasoning about experience. Obviously, different activities handle the acquisition of knowledge differently. Unfortunately, abstract knowledge is not always directly applicable to an activity.

The last piece of the puzzle is a set of skills that are used as part of the activity. Skills can only be developed by doing the activity. Different activities rely on differing amounts of skills. Unfortunately, many people pick up skills in an activity by rote and tend not to recognize the acquisition. Skills are acquired either alone or though the help of a mentor or senior person in that field.

Some of these attributes are innate, like aptitude. Some can possibly be taught to anyone, like knowledge or skills. However, unless all of these attributes are present, someone will never really become proficient in an activity. In order to analyze the productivity of software developers, we need to identify and analyze these attributes. Although aptitude and interest are hard to analyze, we can identify which knowledge and skills might lead to more productive software developers.

Part of the disparity we currently see when measuring productivity in programmers is caused by ignoring one or more of these attributes. When attempting to measure productivity, we look at years of experience or education to recognize equivalent candidates to compare. Unfortunately, abstract knowledge and some skills are easy to identify, but they do not make up the whole of proficiency.

Review of Randal Schwartz's Perls of Wisdom

Randal Schwartz's Perls of Wisdom
Randal L. Schwartz
Apress, 2005

Randal Schwartz has been writing about Perl since the first edition of the Camel Book. This book collects articles that he has written for a number of magazines into one place, organized (loosely) by topic. These articles span almost a decade of writing on the topic.

In any book by Schwartz, you can expect lots of Perl code, clear explanations, and a bit of humor. In this book, you also get to see how some ideas have evolved over time. Different articles from different time periods on similar topics showing how Schwartz's understanding has changed. He also often provides some insight into why the code is written the way it is or the subtle meaning of some of his idioms.

This is the kind of information that is missing from most books on programming. Why do you choose to write the code this way rather than that way? This book gives you some of that from a veteran in Perl. I've been programming in Perl for over a decade, and I found several tidbits that I either never knew or had forgotten. Schwartz introduced modules that I hadn't used yet, and techniques that I had.

If you are doing any programming in Perl, I would definitely recommend this book very highly.