12 ms·

>> [Why not build programmer performance measurement tooling?] It's the job of a manager to know what their reports are up to, and whether they're doing a good

by ethbr1 2y ago

>> [Why not build programmer performance measurement tooling?] It's the job of a manager to know what their reports are up to, and whether they're doing a good job of it, and are generally effective. If they can't do that, then they themselves are ineffective, and that is the sort of thing that is the responsibility of THEIR manager, and so on up the line. Agreed wholeheartedly, but for slightly different reasons. To wit, laziness and Goodhart's law. [0] In the absence of infinite time, automation will excuse a lack of manager curiosity, as other competing tasks absorb the freed time. Consequently, most managers with automated dashboards showing performance metrics won't use those dashboards... plus all the person-to-person work they were previously doing. They'll only use those dashboards. Which then slowly but inexorably turns your employees into dashboard-optimization drones via operant conditioning. Helping a colleague doesn't show up on the dashboards? Fuck that. Digging into what looks like a security vulnerability isn't on the sprint board? Fuck that. Which is incredibly corrosive to quality, creative system design. And then, because this is the work reality you've created, the creative folks you really want working there bail for greener pastures, and you're left with bottom of the barrel talent and retention problems. [0] https://en.m.wikipedia.org/wiki/Goodhart's_law https://en.m.wikipedia.org/wiki/Goodhart's_law

bigiain 2y ago
> Helping a colleague doesn't show up on the dashboards? Fuck that. Digging into what looks like a security vulnerability isn't on the sprint board? Fuck that. Managers who are the sort of people who don't value helping your colleagues or being curious/concerned enough about potential security problems, are most likely the sort of people who won't pick up on any of that being a valuable use of your time during one on ones or in standups either. I think fundamentally you agree 100% with Rachel, shit managers are shit and nobody owes them tooling to make their job of being a shit manager easier. If you want all the employee loyalty and long tenure institutional knowledge of a micro managed call centre, sure - implement checkin and LOC dashboards, or Jira ticket "velocity" charts. Watch all your talented people leave and don';t be surprised when everybody is only there because they're desperate or comfortable. Your entire dev team will eventually be only working-visa-prisoners, talentless-seatwarmers, or people who've dialled the give-a-shit down so low it doesn't bother them just picking up their pay checks.
- chipdart 2y ago
  > Managers who are the sort of people who don't value helping your colleagues or being curious/concerned enough about potential security problems, are most likely the sort of people who won't pick up on any of that being a valuable use of your time during one on ones or in standups either. This is not a "sort of people" problem. This is a metrics problem. It's not only developers who are evaluated by using useless metrics that don't track the value you add to an organization. Low-level managers are too. Low-level managers need to evaluate the people assigned to them, they need to evaluate them objectively, and they need to give an unbiased and objectively verifiable score. This means something they can measure, such as metrics or verifiable goals. If low-level managers cannot do this, they will need to answer why they gave X and Y this score whereas poor little Z who outworked them both was scored lower. Not being able to objectively justify a score is a problem that no manager wants to have, as this is a major liability. Hence the bullshit metrics and absurd goals. They need something on paper to back up their decisions. A manager might be fully aware that you unblocked half your team members throughout the year with critical help, and that you are the go-to guy to solve critical issues. But if your team members close twice the tickets you did, they will have trouble justifying you are contributing as much as them.
  - gradstudent 2y ago
    > But if your team members close twice the tickets you did, they will have trouble justifying you are contributing as much as them. The metrics make reporting to higher ups easier, no doubt. But the situation you describe is a classic sign of a shit manager: one who cannot justify their decisions except via reference to made up metrics.
    - passwordoops 2y ago
      >the situation you describe is a classic sign of a shit manager Well then it means the vast, vast, vast majority of companies with a coherent corporate structure are shit. Welcome to reality
    - Arainach 2y ago
seb1204 2y ago
I would argue that a managers time will be filled no matter what she does. So she could prioritise knowing what her peers do, and acquire the basic knowledge to understand tech maybe? And then fill up the rest of the calendar. So I'm saying it is up to the manager to either suck upwards or support peers.
seb1204 2y ago
Stupid question but when digging into a potential security vulnerability, should that not be a ticket already that can get tracked?
- p1esk 2y ago
  Of course. Same as helping a colleague (unless it’s a few minute task). Whenever there’s something that I can spend my time on, it’s going to be converted into a ticket.
  - jachee 2y ago
    How do you prevent that from recursing infinitely?
    - happymellon 2y ago
      If you are measuring tickets, then you can't. Your job is to create tickets to close them. If you generate productivity along side that, then thats a bonus.
    - djtango 2y ago
      Because we're humans, not robots and a human manager with human managees should be capable of working within a process without abusing the most obvious of edge cases. When building software you have to be precise to the nth degree but with human processes you can afford some degree of ambiguity and judgment...
  - exe34 2y ago
    you create tickets for helping colleagues? I would understand "add this feature for me", but do you also have a ticket to "take x through this unfamiliar neighborhood of the codebase"?
    - ryandrake 2y ago
      I've seen tech companies that strongly encouraged that: Open a "task" or "process" ticket describing what you're doing, then do it, then close the ticket. Not all tickets are bugs and features. During review time, if you expended effort not described in a ticket, it's as if you never did it. When in doubt, open a ticket.
mirekrusin 2y ago
There is an interesting parallel with overfitting [0] which may mean solutions can also resemble each other. [0] https://news.ycombinator.com/item?id=41684082 https://news.ycombinator.com/item?id=41684082 (Too much efficiency makes everything worse (2022))
beAbU 2y ago
Based on my experience automated reporting dashboards start to cause damage where they are allowed to become visible by higher-ups in the org. A dashboard is immensely powerful for the immediate manager to know how their team is doing, identify problems and work with the members to resolve those problems. As with many things, the numbers on a dashboard must be read with context and the closer you are to that team, the better. The moment the dashboard is accessed by higher ups, several things happen: The devs become scrutinized by higher-ups that do not have all the context to make sense of the numbers, the manager is rendered ineffective because the knowledge and power they had while reporting to their superiors is taken away, and upper management will inevitably start caring about the numbers on the dashboard, and nothing else. There is a level of "managing upwards" that lazy direct managers struggle with, and they just pass on the reporting numbers as-is without really caring what this might result in.
- regularfry 2y ago
  Yep. It's for exactly this reason that I've told potential vendors in the past that not exposing, and preferably not gathering, individual contributor metrics was a hard requirement. I'd rather have individual team leads or scrum masters have to gather their own stats than have people with disproportionate organisational leverage exposed to information they don't know they aren't qualified to interpret.
- touristtam 2y ago
  It's about safe space. We're not just cogs in the machine. We exists as humans with our own sets of fluctuating of emotional and psychological states. Break that at your own peril.
- ethbr1 2y ago
  Excellent insight! Metrics are useful, but only with context. Any metrics reported at skip level by definition lack context: there's no ground-level engagement or time to dig into details. Ergo, the reported numbers are understood as the only numbers. With the exact solution you offered! Use them, but only at the level in which additional context is available, then report up new numbers that allow for enriching / adjusting the base numbers.
DrBazza 2y ago
The most interesting thing during COVID was seeing the switch from in-office to remote, followed by a round of redundancies, and the redundancies were fascinating. It was full of people that when in-office seemed gave the impression of hard-working, largely by a combination of 'face time', and just talking to other employees, and not necessarily about work. >> [Why not build programmer performance measurement tooling?] I'm pretty sure there wasn't any employee monitoring software other than completion of Jira tickets within individual teams. The whole sneaky monitoring/measurement software is totally counter-productive, and counter-intuitive. If I'm in an office, no one is going to care if I read the docs or an ebook, possibly on my tablet, but if I'm remote and not jiggling my mouse every few seconds I'm slacking off.
- ryandrake 2y ago
  > It was full of people that when in-office seemed gave the impression of hard-working, largely by a combination of 'face time', and just talking to other employees, and not necessarily about work. Hahah, we all know these people! They walk around the office, sometimes carrying a clipboard or stack of paper, initiating business-y conversations, always making sure they look very serious and busy, deliberately walking past the boss's office frequently so he can see them visibly DoingSeriousBusiness. When promotion time comes around, these social butterflies are always at the top of the list, because naive managers see them buzzing around everywhere, and they at least think they know that these guys are constantly doing work. These people were panicking during COVID and WFH. Their entire self-promotion vector disappeared overnight. Now that most companies have returned to in-person work, these hall-walkers are back and once again getting promoted based entirely on their presence and visibility.
mihaaly 2y ago
I work now for a long history smaller organization that formalized management and organization in the past 4-5 or so years. I joined midway of this - looking my way out now - and the focus on unconnected details only was odd right from the beginning. I attributed this to me being new and can't see the whole picture, digged into discovering my immediate vicinity. But after a year seeing we are still being obsessed only about those plenty of items that fit into a sprint multiple times remained sick to me. I discovered several embarrasing mistake in design of approaches, interaction or implementation that made me scared: how this went through at all, and how it remained there for so many years? Is this used at all actually?! People should desert us not paying for such nonsense (shit, actually). Reported these mistakes in our issue tracking system and those fit into less than half of a sprint landed back on me sooner or later, almost all. Not those first being very serious, but those fit into the schedule (but mixed in seriousity at least, those being serious first). My takeaways: - Seriousness and functionality is not the primary concern, company management is! - Others (about 2 dozens of engineers) did not take the effort to report. I am not brighter than them, I was novice in that environment and codebase and the actual technology, also what I was reporting stands out on usage level only, no tecnological knowledge necessary. - Apparently problems are positioned proactively on blind spot to remain unrecognised. There must be a serious level of ignorance involved. The company lived through decades of difficulties, never had investors but built and run by the increasing number of enthusiastic loyal people. The company organization was non-existing compared to today's norms meeting contemptuous looks from today'n collaborative organizational ninjas. I am sure several of the problems stems in the casual running of the organization, but the reorganization is not helping but making things worse, preserving, leaving in. The reorganization made the company look much shinier though. It looks much improved. As I later learned the reorganization was needed for selling the company. The founders pushing retirement age and want to cash out. Even my employement was part of that show, fitting into making the company look similar to trendy ones clueless investors can find appealing based on the facade. We are agile in all sense, we are technologically advanced (AI feature is pushed in for the sake of it), our recruited HR professional is like all other, we are uniquely successful like all others, we are team, we care of employees a lot, we have workplace well-being taken the most seriously (just like everything else in HR), we are family in matching uniforms smiling happily into the camera in a team building excercise, and above all we have top notch marketing with thick flow of photographically illustrated success stories and dynamism. And practically our backlog does not contain serious bugs. For the matter of how users stay with us my running theory is that there is no better choice than this. Others are similar (also the lock-in effect to something they learned and invested in is there). I see complaints, I see angry complaints now despite me being disconnected from the client facing report system, I see their efforts for trying to make it work, finding workarounds of workarounds only reporting when the combination of workarounds collapse. They try to use it, they need something like this. I feel their efforts, this is what I am doing in increasing level with Windows, and the various software tools I use. Those look similar on the surface, increasingly so and it deteriorates as we speak.
InfamousRece 2y ago
I used to work for a company that started using Gitprime to measure developer productivity. Gitprime would show a nice dashboard with stack ranked employees based on their git commits. Besides the obvious effect that it had on cooperation (you don’t want to help another developer lest they go before you in the stack rank) it had also funny effect on the code we wrote. For example, replacing old code with new code was penalized as “code churn”, so we had to write something like if (false) { // old code } // new code In Golang projects we avoided pushing the vendors directory in one commit. Instead we had to strategically commit it piece by piece to satisfy “frequent small commits” metric that apparently is a signature of good developers.
- jacobyoder 2y ago
  I worked in a place where... regardless of what I did in branches, someone else would merge it and their name would be the only thing that showed up in the git metrics, because we only looked at the final 'main' branch. I'd looked at the 'develop' - where feature branches were merged before master - and I think I had something like 75%+ of the commits (over a 14 month period). But to look at the daily dashboard, I was doing nothing, and someone who was barely in weekly meetings for more than 15 minutes was doing 95% of the work. I didn't particularly care, until people started looking at 'dashboard metrics' to see 'who's doing what'. I wasn't initially wanting visual credit, but when my contributions were effectively erased to the casual viewer, it pissed me off...
raxxorraxor 2y ago
> the creative folks you really want working there bail for greener pastures This is the main reason. Either pay 100k with boni and I work as a code monkey for some years. But even then I will bail after some time. A strategy that cannot be viable for any company, even those that just need a quick software solution to a problem. The knowledge management with changing employees only makes it even more expensive. If you want to burn money to see the commit log glow, please do so. I am unlikely to take any ownership of the code produced, but probably will come up with a commit here and there. Not every form of coding requires creativity, there is also a lot of mundane logic that just needs to be given form. But even those developers should not be subjected to such metrics or anyone really. What we created in other industries like logistics and call centers amounts to slavery aside from the fact that the employees decided to work there at some point. Something that also can be disputed how voluntary that decision was. Managers with such strategies are a liability for any company.
steveBK123 2y ago
Employee level metrics are a fast slipper slope to encouraging all the wrong behaviors. Most of what you actually want out of a good developer is not captured in metrics easily, but lots of superfluous stuff is. I recall one of my worst managers was a guy who would nitpick the "how" of every action (email/slack to users, internal runback documentation, etc), but rarely if ever call anyone out for inaction. He was also pretty indifferent to the what (actual functionality delivered to users). This created a tremendous bias to inaction in the team, and everyone developed slopey shoulders.. He eventually got fired but not before a lot of turmoil and turnover. As soon as you start rewarding devs based on story points, ticket counts, response times, ticket closure rates you get all sorts of bad behavior. You'd be better served based on quarterly changes in user satisfaction metrics as thats literally all that matters - the end product.

by ethbr1 2y ago

bigiain 2y ago

> Helping a colleague doesn't show up on the dashboards? Fuck that. Digging into what looks like a security vulnerability isn't on the sprint board? Fuck that. Managers who are the sort of people who don't value helping your colleagues or being curious/concerned enough about potential security problems, are most likely the sort of people who won't pick up on any of that being a valuable use of your time during one on ones or in standups either. I think fundamentally you agree 100% with Rachel, shit managers are shit and nobody owes them tooling to make their job of being a shit manager easier. If you want all the employee loyalty and long tenure institutional knowledge of a micro managed call centre, sure - implement checkin and LOC dashboards, or Jira ticket "velocity" charts. Watch all your talented people leave and don';t be surprised when everybody is only there because they're desperate or comfortable. Your entire dev team will eventually be only working-visa-prisoners, talentless-seatwarmers, or people who've dialled the give-a-shit down so low it doesn't bother them just picking up their pay checks.

chipdart 2y ago
> Managers who are the sort of people who don't value helping your colleagues or being curious/concerned enough about potential security problems, are most likely the sort of people who won't pick up on any of that being a valuable use of your time during one on ones or in standups either. This is not a "sort of people" problem. This is a metrics problem. It's not only developers who are evaluated by using useless metrics that don't track the value you add to an organization. Low-level managers are too. Low-level managers need to evaluate the people assigned to them, they need to evaluate them objectively, and they need to give an unbiased and objectively verifiable score. This means something they can measure, such as metrics or verifiable goals. If low-level managers cannot do this, they will need to answer why they gave X and Y this score whereas poor little Z who outworked them both was scored lower. Not being able to objectively justify a score is a problem that no manager wants to have, as this is a major liability. Hence the bullshit metrics and absurd goals. They need something on paper to back up their decisions. A manager might be fully aware that you unblocked half your team members throughout the year with critical help, and that you are the go-to guy to solve critical issues. But if your team members close twice the tickets you did, they will have trouble justifying you are contributing as much as them.
- gradstudent 2y ago
  > But if your team members close twice the tickets you did, they will have trouble justifying you are contributing as much as them. The metrics make reporting to higher ups easier, no doubt. But the situation you describe is a classic sign of a shit manager: one who cannot justify their decisions except via reference to made up metrics.
  - passwordoops 2y ago
    >the situation you describe is a classic sign of a shit manager Well then it means the vast, vast, vast majority of companies with a coherent corporate structure are shit. Welcome to reality
  - Arainach 2y ago

seb1204 2y ago

I would argue that a managers time will be filled no matter what she does. So she could prioritise knowing what her peers do, and acquire the basic knowledge to understand tech maybe? And then fill up the rest of the calendar. So I'm saying it is up to the manager to either suck upwards or support peers.

seb1204 2y ago

Stupid question but when digging into a potential security vulnerability, should that not be a ticket already that can get tracked?

p1esk 2y ago
Of course. Same as helping a colleague (unless it’s a few minute task). Whenever there’s something that I can spend my time on, it’s going to be converted into a ticket.
- jachee 2y ago
  How do you prevent that from recursing infinitely?
  - happymellon 2y ago
    If you are measuring tickets, then you can't. Your job is to create tickets to close them. If you generate productivity along side that, then thats a bonus.
  - djtango 2y ago
    Because we're humans, not robots and a human manager with human managees should be capable of working within a process without abusing the most obvious of edge cases. When building software you have to be precise to the nth degree but with human processes you can afford some degree of ambiguity and judgment...
- exe34 2y ago
  you create tickets for helping colleagues? I would understand "add this feature for me", but do you also have a ticket to "take x through this unfamiliar neighborhood of the codebase"?
  - ryandrake 2y ago
    I've seen tech companies that strongly encouraged that: Open a "task" or "process" ticket describing what you're doing, then do it, then close the ticket. Not all tickets are bugs and features. During review time, if you expended effort not described in a ticket, it's as if you never did it. When in doubt, open a ticket.

mirekrusin 2y ago

There is an interesting parallel with overfitting [0] which may mean solutions can also resemble each other. [0] https://news.ycombinator.com/item?id=41684082 https://news.ycombinator.com/item?id=41684082 (Too much efficiency makes everything worse (2022))

beAbU 2y ago

Based on my experience automated reporting dashboards start to cause damage where they are allowed to become visible by higher-ups in the org. A dashboard is immensely powerful for the immediate manager to know how their team is doing, identify problems and work with the members to resolve those problems. As with many things, the numbers on a dashboard must be read with context and the closer you are to that team, the better. The moment the dashboard is accessed by higher ups, several things happen: The devs become scrutinized by higher-ups that do not have all the context to make sense of the numbers, the manager is rendered ineffective because the knowledge and power they had while reporting to their superiors is taken away, and upper management will inevitably start caring about the numbers on the dashboard, and nothing else. There is a level of "managing upwards" that lazy direct managers struggle with, and they just pass on the reporting numbers as-is without really caring what this might result in.

regularfry 2y ago
Yep. It's for exactly this reason that I've told potential vendors in the past that not exposing, and preferably not gathering, individual contributor metrics was a hard requirement. I'd rather have individual team leads or scrum masters have to gather their own stats than have people with disproportionate organisational leverage exposed to information they don't know they aren't qualified to interpret.
touristtam 2y ago
It's about safe space. We're not just cogs in the machine. We exists as humans with our own sets of fluctuating of emotional and psychological states. Break that at your own peril.
ethbr1 2y ago
Excellent insight! Metrics are useful, but only with context. Any metrics reported at skip level by definition lack context: there's no ground-level engagement or time to dig into details. Ergo, the reported numbers are understood as the only numbers. With the exact solution you offered! Use them, but only at the level in which additional context is available, then report up new numbers that allow for enriching / adjusting the base numbers.

DrBazza 2y ago

The most interesting thing during COVID was seeing the switch from in-office to remote, followed by a round of redundancies, and the redundancies were fascinating. It was full of people that when in-office seemed gave the impression of hard-working, largely by a combination of 'face time', and just talking to other employees, and not necessarily about work. >> [Why not build programmer performance measurement tooling?] I'm pretty sure there wasn't any employee monitoring software other than completion of Jira tickets within individual teams. The whole sneaky monitoring/measurement software is totally counter-productive, and counter-intuitive. If I'm in an office, no one is going to care if I read the docs or an ebook, possibly on my tablet, but if I'm remote and not jiggling my mouse every few seconds I'm slacking off.

ryandrake 2y ago
> It was full of people that when in-office seemed gave the impression of hard-working, largely by a combination of 'face time', and just talking to other employees, and not necessarily about work. Hahah, we all know these people! They walk around the office, sometimes carrying a clipboard or stack of paper, initiating business-y conversations, always making sure they look very serious and busy, deliberately walking past the boss's office frequently so he can see them visibly DoingSeriousBusiness. When promotion time comes around, these social butterflies are always at the top of the list, because naive managers see them buzzing around everywhere, and they at least think they know that these guys are constantly doing work. These people were panicking during COVID and WFH. Their entire self-promotion vector disappeared overnight. Now that most companies have returned to in-person work, these hall-walkers are back and once again getting promoted based entirely on their presence and visibility.

mihaaly 2y ago

I work now for a long history smaller organization that formalized management and organization in the past 4-5 or so years. I joined midway of this - looking my way out now - and the focus on unconnected details only was odd right from the beginning. I attributed this to me being new and can't see the whole picture, digged into discovering my immediate vicinity. But after a year seeing we are still being obsessed only about those plenty of items that fit into a sprint multiple times remained sick to me. I discovered several embarrasing mistake in design of approaches, interaction or implementation that made me scared: how this went through at all, and how it remained there for so many years? Is this used at all actually?! People should desert us not paying for such nonsense (shit, actually). Reported these mistakes in our issue tracking system and those fit into less than half of a sprint landed back on me sooner or later, almost all. Not those first being very serious, but those fit into the schedule (but mixed in seriousity at least, those being serious first). My takeaways: - Seriousness and functionality is not the primary concern, company management is! - Others (about 2 dozens of engineers) did not take the effort to report. I am not brighter than them, I was novice in that environment and codebase and the actual technology, also what I was reporting stands out on usage level only, no tecnological knowledge necessary. - Apparently problems are positioned proactively on blind spot to remain unrecognised. There must be a serious level of ignorance involved. The company lived through decades of difficulties, never had investors but built and run by the increasing number of enthusiastic loyal people. The company organization was non-existing compared to today's norms meeting contemptuous looks from today'n collaborative organizational ninjas. I am sure several of the problems stems in the casual running of the organization, but the reorganization is not helping but making things worse, preserving, leaving in. The reorganization made the company look much shinier though. It looks much improved. As I later learned the reorganization was needed for selling the company. The founders pushing retirement age and want to cash out. Even my employement was part of that show, fitting into making the company look similar to trendy ones clueless investors can find appealing based on the facade. We are agile in all sense, we are technologically advanced (AI feature is pushed in for the sake of it), our recruited HR professional is like all other, we are uniquely successful like all others, we are team, we care of employees a lot, we have workplace well-being taken the most seriously (just like everything else in HR), we are family in matching uniforms smiling happily into the camera in a team building excercise, and above all we have top notch marketing with thick flow of photographically illustrated success stories and dynamism. And practically our backlog does not contain serious bugs. For the matter of how users stay with us my running theory is that there is no better choice than this. Others are similar (also the lock-in effect to something they learned and invested in is there). I see complaints, I see angry complaints now despite me being disconnected from the client facing report system, I see their efforts for trying to make it work, finding workarounds of workarounds only reporting when the combination of workarounds collapse. They try to use it, they need something like this. I feel their efforts, this is what I am doing in increasing level with Windows, and the various software tools I use. Those look similar on the surface, increasingly so and it deteriorates as we speak.

InfamousRece 2y ago

I used to work for a company that started using Gitprime to measure developer productivity. Gitprime would show a nice dashboard with stack ranked employees based on their git commits. Besides the obvious effect that it had on cooperation (you don’t want to help another developer lest they go before you in the stack rank) it had also funny effect on the code we wrote. For example, replacing old code with new code was penalized as “code churn”, so we had to write something like if (false) { // old code } // new code In Golang projects we avoided pushing the vendors directory in one commit. Instead we had to strategically commit it piece by piece to satisfy “frequent small commits” metric that apparently is a signature of good developers.

jacobyoder 2y ago
I worked in a place where... regardless of what I did in branches, someone else would merge it and their name would be the only thing that showed up in the git metrics, because we only looked at the final 'main' branch. I'd looked at the 'develop' - where feature branches were merged before master - and I think I had something like 75%+ of the commits (over a 14 month period). But to look at the daily dashboard, I was doing nothing, and someone who was barely in weekly meetings for more than 15 minutes was doing 95% of the work. I didn't particularly care, until people started looking at 'dashboard metrics' to see 'who's doing what'. I wasn't initially wanting visual credit, but when my contributions were effectively erased to the casual viewer, it pissed me off...

raxxorraxor 2y ago

> the creative folks you really want working there bail for greener pastures This is the main reason. Either pay 100k with boni and I work as a code monkey for some years. But even then I will bail after some time. A strategy that cannot be viable for any company, even those that just need a quick software solution to a problem. The knowledge management with changing employees only makes it even more expensive. If you want to burn money to see the commit log glow, please do so. I am unlikely to take any ownership of the code produced, but probably will come up with a commit here and there. Not every form of coding requires creativity, there is also a lot of mundane logic that just needs to be given form. But even those developers should not be subjected to such metrics or anyone really. What we created in other industries like logistics and call centers amounts to slavery aside from the fact that the employees decided to work there at some point. Something that also can be disputed how voluntary that decision was. Managers with such strategies are a liability for any company.

steveBK123 2y ago

Employee level metrics are a fast slipper slope to encouraging all the wrong behaviors. Most of what you actually want out of a good developer is not captured in metrics easily, but lots of superfluous stuff is. I recall one of my worst managers was a guy who would nitpick the "how" of every action (email/slack to users, internal runback documentation, etc), but rarely if ever call anyone out for inaction. He was also pretty indifferent to the what (actual functionality delivered to users). This created a tremendous bias to inaction in the team, and everyone developed slopey shoulders.. He eventually got fired but not before a lot of turmoil and turnover. As soon as you start rewarding devs based on story points, ticket counts, response times, ticket closure rates you get all sorts of bad behavior. You'd be better served based on quarterly changes in user satisfaction metrics as thats literally all that matters - the end product.