They should indeed. In IT this often translates, for managers, to LoC, # of files touched, # of commits and tasks closed. Especially the first one is ofcourse a horrible metric but still quite prevalent IME. # of commits depends on the person; I commit a lot; I think because I remember too much lost work in the past, not because someone is counting commits (it would be silly). I see clearly in some cultures of partners we work with that people are deemed ‘extremely good’ if some combination of LoC x #files x commits x #tasks x timespan is as high as possible, even if the end result is far far worse than the people who have a far lower rate. Also in those cultures there are more design patterns in use; with some design patterns from OO in java/c# (which now creeped in Typescript at those places too) you change code in 10+ files and have to write 100s of lines of plumbing even for basic things; this really helps with getting the metrics up; it is copy/paste/change (so fast) while ‘delivering a lot’.
I always sigh when I hear ‘mate, you only committed X lines and you ask $xxxx for that?’; yes and yes because they are the same lines as your ‘star programmer’ (the working to the above metrics) would distill after making far more hours because wanting to look more productive. Luckily I am just a consultant as I would not survive in those places.
on the other hand, I wonder if "accomplishments" is a red herring too. Can it measure helping someone out, which is good for the company, but not for personal productivity?
In professional settings yes. In “rote”/“routine”/“unskilled” roles absolutely not. Class (and other isms) determines access to “adult” jobs, in other jobs so long as the distinction exists merit is a terrible way to apportion comp. It completely disincentivizes any kind of realization of anyone’s potential that wasn’t predisposed to realize.
In the real world, in quite a few companies, in order to accomplish X, you must sit through many meetings with others that have nothing to do with accomplishing X.
There are also many other logistical hurdles that you must overcome to accomplish X. The problem is that often, I do not need to attend the meetings, nor do I need to overcome the logistical/political) hurdles to accomplish X, and more often than not these are impediments to accomplishing X.
It really varies from company to company, my point is, I want to get paid for the time, because I can never be certain how much I will have to waste in meetings and other un-related tasks before I can complete a given accomplishment, due to dependencies on others.
Add to all of that the litmus test of a completed "accomplishment" can be very subjective, e.g. something one person thinks is done, is not seen that way by someone else, and you don't get paid until everyone agrees it is done?
There's also the old scope creep monster, that rears it's ugly head. What you had to accomplish at the beginning of the project changed half way through and now you have do twice the work to complete the "accomplishment".
My time is the most valuable thing I have and the older I get the move valuable it becomes. I'm not going to roll the dice that whoever is writing the checks will have the same perception that something was accomplished as I do. I don't want to have to spend more time to "accomplish" something, just because someone "moved the goal-post".
On the other hand if you are a consultant and it's a vendor/customer relationship, then it's up to you as the vendor to define the "accomplishment" and build in a way that both vendor and customer can agree on when an "accomplishment" is finished. Scope creep is handled by additional statements of work, etc.
When there are contracts and potentially lawyers involved, paying for accomplishments is a little more tenable, in an employer employee relationship, where as the employee if you don't like it you can find another job, not so much.
Imagine if every time you got paid you had to have a meeting with your manager to determine exactly what you had accomplished, with the manager making the final decision on whether it was done or not? Suppose they decide that program you wrote needs more testing to be "accomplished", or an extra feature that was not originally scoped needs to be added and until such time, they aren't going to pay you? That sounds like the stuff of nightmares to me.
I always sigh when I hear ‘mate, you only committed X lines and you ask $xxxx for that?’; yes and yes because they are the same lines as your ‘star programmer’ (the working to the above metrics) would distill after making far more hours because wanting to look more productive. Luckily I am just a consultant as I would not survive in those places.