Re: measuring job performance
From: Gawnsoft (xlucid_at_users.sourceforge.remove.this.antispam.net)
Date: 04/05/04
- Next message: MSCHAEF.COM: "Re: GUI vs: CLI (was: Shell command in VB6)"
- Previous message: Gawnsoft: "Re: renaming files"
- In reply to: Rogue Petunia: "measuring job performance"
- Next in thread: Nick Landsberg: "Re: measuring job performance"
- Reply: Nick Landsberg: "Re: measuring job performance"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 05 Apr 2004 22:33:51 +0100
On Sun, 04 Apr 2004 21:16:40 GMT, "Rogue Petunia"
<roguepetunia@nospam.com> wrote (more or less):
>Hello,
>I'd like to hear your ideas on how to measure a programmer's job
>performance, particularly the output. Our company requires each employee to
>set goals for the year. My manager has told me that my output must increase
>and this must be one of my goals for this year. This is a vague, nebulous
>statement. How can one quantify this?
>
>If I were a salesperson, I could say, my goal is to sell 10% more vacuums.
>Programming is different. Can't say, my goal is to complete 5 projects this
>year because the size of projects vary.
>
>I don't believe in LOC (lines of code) as a job performance metric because a
>good programmer writes compact, efficient code that leads to application
>stability. Sprawling, uncontrolled code full of workarounds might have a
>lot more lines but it's worse.
>
>Our company's goal setting guidelines encourage that we set quantifiable
>goals. A goal such as, "to improve technical skills" is a poor goal. It
>would be better stated as, "to learn COM+". And even that is not so good
>because what constitutes having "learned" something? Perhaps, "to write a
>COM+ component" really narrows it down and leaves little room for
>interpretation. At the year end performance review you've either written a
>COM+ component or you haven't. You've either met the goal or you haven't.
>
>I'd like to hear from those of you with experience in a corporate setting
>where goal setting and performance reviews are standard fare. Do you have
>suggestions on how to quantify the goal of "to increase my output".
Why not make the measurements to do with quality, not quantity?
e.g. 'fewer bugs discovered by end-users in code I have created this
year vs. code I created last year'.
'Fewer bugs per 1000 lines of code escaping to Acceptance testing'.
Or 'higher % coverage of your code by your unit tests this year than
next'.
Or something like 'my coding practices to become 5% more Agile than
before' :-)
Cheers,
Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki: http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk
- Next message: MSCHAEF.COM: "Re: GUI vs: CLI (was: Shell command in VB6)"
- Previous message: Gawnsoft: "Re: renaming files"
- In reply to: Rogue Petunia: "measuring job performance"
- Next in thread: Nick Landsberg: "Re: measuring job performance"
- Reply: Nick Landsberg: "Re: measuring job performance"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|