Evaluation of the work done per day by a programmer, how to evaluate?

Question

Personnel Management

Production rate according to commit information (new files, changed, insertions, deletions). This is how I evaluate the work done.
A day is included in the commit approximately:

77 files changed, 1129 insertions(+), 351 deletions(-)

Of course, there are fewer files usually, today was such a day.
I'm wondering how much is that? What is the norm for others? You? What should be? When is a lot, a little, and normal? Numbers? Is there any statistics? And what other options are there to evaluate the amount of work done per day? Sometimes you write a feature, there is a lot of code, but there is no feature yet.

Answer 1

How many tasks are closed, of those that were planned in the morning
How many tasks until the end of the sprint / week from what the PM set
Have all the approvals that are needed for tasks for tomorrow been made?
The number of lines of code does not bother anyone at all.
If you want to smell the CSF - count the money that was earned per day

Answer 2

It is unambiguously necessary to evaluate by the number of lines. Scrum is bullshit, and so are its metrics.

Answer 3

Very much depends on the project and measurement technique. If I move a large file, does your technique think that I deleted thousands of lines and added the same number? Usually, a lot of code is written at the beginning of a project/feature, but over time, more and more time is spent on debugging, testing and thinking, and you can spend the whole day shamanizing optimization that fits in a couple of lines.
Funny: Legend has it that Microsoft once published statistics that the average was less than three lines per day per person.

Answer 4

there is such a group of plugins with the names power-mode
first saw one for atom . now there is for almost everyone .
you go into the programming room, it's so quiet, everyone is wearing headphones, but you can see the labor coders from a mile away.

Answer 5

Any commercial application can be in only two states: it either solves the company's problem or not. I don't know any third one.
The result of your work is a working application, implemented features, fixed bugs, improved tests, etc. You can't see the back-end with your eye. The number of new files/lines when not an indicator at all.
How do you know if you are doing well or not? You approach your team leader/boss and ask: "Are you satisfied with the way I work." The answer is yes, so keep up the good work.

Answer 6

The amount of work is not estimated by line - it's just another metric on top of everything else.
But on the right - this should be done by the project manager. He is financially responsible for the project to the employees, and he is trying to extort finance from the customer. And his task is to satisfy the customer, so that there is money, and satisfy the developers and testers, so that people who perform the assigned tasks work on the project.
If you want to evaluate yourself - what is your goal? To measure up with someone? Silly. You can measure yourself at all sorts of hackathons, where at least approximately the same task is being set, and so - everyone has different conditions.

Answer 7

You need to evaluate by the result of the work done and by what this result brought profit. And counting how many and who wrote the lines of code ... I have never heard of such a thing. Yes, and this is generally stupid, because. tasks are completely different: code review, research, search for the causes of a bug, etc. By completing these tasks, you are unlikely to commit anything.
For example, I had periods when I didn’t write a single line of code in 1-2 weeks :)