I suppose this depends largely on what you mean by "tracking progress". Are you wishing to track personal progress? Or, is it the progress of colleagues, subordinates, students, potential employees/contractors, etc. (or some combination)?
The idea of "progress" is highly personal, and as such it is often a mistake to try to put numbers on things like skill and experience. Well, to a point, anyhow.
From the point of view of a hiring manager (in a past life), my thoughts on some of your criteria:
- Posts/XP on Perlmonks is largely irrelevant: I'm sure there are fantastic Perl programmers who rarely post, and may hardly log in to read (or may not have bothered with an account). Maybe they simply don't think Perlmonks is a good idea, or a host of other factors that have little or no relevance to skill.
- CPAN modules used/written. Well, what about someone who solved many problems that are unique to a field, and CPAN wasn't as helpful -- further, they may not have been allowed by management to publish the modules they write to CPAN.
- Salary increase is an odd measure, because there are other perks that geeky people are likely to value. I've taken pay cuts to work for managers with a clue, or to take work with seasonal companies (summers off!).
- I would rephrase the bit about other languages: someone might be a minor Perl diety and not know other languages at all. It's unlikely, but nothing about deciding to focus energy on being an excellent Perl programmer would necessarily be a bad thing. There is value in knowing something about other languages, but I wouldn't weight that knowledge very heavily.
- Number of projects completed is worthless without an understanding of the complexity of those projects. And by complexity, I mean problem-complexity. One of the projects I'm most proud of took me two years -- the majority of which was analysis and experimentation to pin down the problem -- and ended up being "small" in terms of code size; still, it's a very elegant solution that has now been in production without modification for three years, and saves that organization hundreds of thousands of dollars a year.
- Ability to pay more bills is a nice perk to being a good programmer, but it's not a way to measure progress. See my comments about salary increases.
- Riding the corporate ladder is often inversely proportionate to programming skill. Corporate advancement is about understanding office politics more than being a skilled developer. In fact, as a manager, I'd rather just reward my skilled developers with more pay, more vacation, and other perks than "promote" them within the corporation -- a lot of fantastic developers don't want to manage, because it means less time for what they are good at and enjoy (writing code).
If I were to try to score a potential employee, the criteria would be something like:
- real-world experience (time)
- familiarity with solving diverse types of problems
- familiarity with a number of Perl resources (knows about Perlmonks, various USENET groups, CPAN, etc.)
- ability to spot common "gotchas" in code (e.g. spot where a use of '||' instead of 'or' might cause problems)
- knowledge of best practices for writing new code (e.g. use of strict, warnings, POD)
- knowledge of when Perl is not the correct choice, and ideas about alternatives
- understanding of different development models (e.g. RUP, XP), and methods (e.g. procedural, OO, functional)
- willingness to find/use existing modules to solve problems (perhaps tested by development of a simple solution for a made-up, but realistic, problem that is 90% solved on CPAN)
- an awareness of what (s)he does not know
Even these would be rather hard to assign numerical values to without a large degree of subjectivity...
Yoda would agree with Perl design: there is no try{}
| [reply] |
It is an interesting thought to somehow link your Perl programming progress to your ability to enjoy life. "I did a Schwartzian transform today and I'm in heaven!"
CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law
| [reply] |
My ability to enjoy life is hierarchically:
- Pay my obligations and debts
- Help others
- Get 100% completion on GTA: San Andreas
Perl helps with all three of these.
| [reply] |
Pray tell, how can Perl help you with completing GTA: San Andreas? I didn't know it has a Perl-accessible interface.
CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law
| [reply] |
Who is the beneficiary of the metrics?
Some of your metrics are important from the perspective of a boss or manager. Others are of concern to the coder him/herself. Others could be looked at as a measure of one's contribution to the software community at large. A Larry Wall or Damian Conway or Randal Schwartz might not show up as well on boss-oriented metrics as some rut-oriented geek, but I'm sure glad they're around.
I've known lots of coders who infest a place and crank out lots of "progress" that didn't solve a single worthwhile problem for the organization they worked for. As a company owner, I much prefer the guy who takes long walks on my time, but then comes back in and whammo! makes things a whole lot better with a 30-line script. The way I look at it, if he does that two or three times a month, I'm way ahead of the game.
As you can probably infer, I'm all in favor of #12. A coder who is a whole person is a hell of a lot more valuable in the big picture than by any other measure. :D | [reply] |
| [reply] |
I just wrote for the hack of it. I guess, after some years, you get more time to enjoy life with established methods and less worry about debugging.
| [reply]
[d/l] |
Measurement is something which has to have some type of numbers. That
eliminates things like confidence level.
This is bullshit. The first part is an inane truism, and overall it
has no logic whatsoever.
I'm getting tired of the recent stream of inane posts, with characters
of dubious cluefulnes and common-sense displaying specious reasoning,
lofty great schemes and hazy ideas (it's hard to even call them ideas) in a
vane attempt at ego-based self-gratification.
And anyway, I don't get the whole point of your post. You want
some numbers? Consult an astrologist!
7. Developed systems of solving probelms.
Yes I have one: Cut the hype!
| [reply] |
I think that many of the categories you have listed above have little to do with someone's Perl or any programming ability. If anyone tracked the "ability" of a programmer by any of the above, I would suggest intense therapy and shock treatment. Programming skills can usually be seen in the little things. We did technical interviews for C programmers a while the very bad programmers weeded themselves out quickly, the little things showed us who the good programmers were. Some of the things we looked for were:
- No syntax errors on whiteboard coding. The great programmers rarely had one.
- Immediately wrote down a closing curly ("}") after opening a block. They often had to erase as they went on, but it gave an interesting glimpse into their thought processes.
- Had a very strong editor preference. We didn't care if they prefered emacs or vi, we just cared that there was a preference. Some even expressed preferences by operating system.
- Used the (0 == foo) style syntax in conditionals. These people had been
burned by an assignment in a conditional and learned from their mistakes.
The little things quickly separated the adequate programmers from the good and great programmers. Several articles have been written in the past regarding similar traits of good programmers. There is one caution though. Good traits in one programming language do not necessarily translate to other programming languages. Be careful to define the little things appropriately for the language you have questions about.
| [reply]
[d/l] |