4 ms·

I cannot tell if you are aware you're setting devs up for failure or not. Half your mentioned metrics are tackled by hard forcing your devs to run branch CI pri

I cannot tell if you are aware you're setting devs up for failure or not. Half your mentioned metrics are tackled by hard forcing your devs to run branch CI prior to merging and giving them a slap on the wrist for not running CI checks locally pre-push. If they are important enough to measure, why not hard force them and focus on the remaining metrics instead?

malux85 4y ago
See where I said “none taken as absolute because there are assumptions in each one” And “Use these as a springboard for deeper analysis of devs” These are only used as high level metrics to guide further analysis, we are keenly aware of the faults of these metrics - but the alternative of no-metrics or worse, “gut feel”, is slow and riddled with more problems. It doesn’t mean a dev is bad, maybe it means there’s some tooling failure, or organisational problem, or personal problem they need help with. These metrics give visibility into anomalies, and their imperfect nature doesn’t mean they are useless. There’s also like 20 more metrics but I’m on my phone and couldn’t recall them all right now Also I don’t know where all of this nonsense about “forcing” to run CI/CD before branch merges and “slap on the wrist” - all our devs can run the test suites locally in docker and inside their IDE, nobody is forced to do anything in the pipeline severs, and also nobody gets a slap on the wrist for CI/CD failures, actually I like to see larger changes with more failures because it means the dev is trying and I consider this normal behaviour, your incorrect assumptions about our test environment and how we interpret these metrics sound like you’re projecting.
- enord 4y ago
  If you _need_ «metrics» it’s because you _really_ don’t understand the contribution of your reports. i.e. you are not a competent manager by the usual understanding of «competent».
  - malux85 4y ago
    I’m not a manager, I’m a dev (well senior dev, that’s why I know about the metrics), but I am measured by the same standards as everyone else. When I became aware of then I viewed my own reports, and found areas I can improve on. I like it. The metrics actually showed no surprises when I saw them, had I been asked to name the worst 5 devs, I would have named the same people that the metrics would have highlighted.
    - _djo_ 4y ago
      So what you're saying is that it's useful for devs to be able to view their own stats for this on a no blame basis, and you have used your privileged position of access to them to improve your own performance, but you don't let the other devs do the same because you want to keep using these as secret metrics to manage them. Do I have that right?
      - malux85 4y ago
        No, I was asked my management to review the reports and help them interpret them, I would gladly give all the devs access to the reports, but that decision is not mine. I raised this suggestion with management, but since we had a handful of devs who were drastically underperforming we decided to help them out first with increased mentorship, in order not to embarrass them in front of their colleagues. I don’t know why you’re assuming the worst and malicious intent, it’s a great place to work, especially when we have a good vibe and all enjoy working together. I think what contributes to this positive environment is not employing developers who instantly assume malicious intent, and aren’t paranoid about being discovered as incompetent. These people are usually the ones most opposed to metrics, and also are the ones who the metrics show are the worst performers. Instead of objectively assessing the facts they attack the messenger, full of emotion and vitriol because of their insecurities and inabilities. There are many factors that go into firing a dev, if someone needs help we mentor them and grow them, but if someone has a bad attitude, assumes the worst and is full of negativity, then we are very quick to fire them.
        _djo_ 4y ago

malux85 4y ago

See where I said “none taken as absolute because there are assumptions in each one” And “Use these as a springboard for deeper analysis of devs” These are only used as high level metrics to guide further analysis, we are keenly aware of the faults of these metrics - but the alternative of no-metrics or worse, “gut feel”, is slow and riddled with more problems. It doesn’t mean a dev is bad, maybe it means there’s some tooling failure, or organisational problem, or personal problem they need help with. These metrics give visibility into anomalies, and their imperfect nature doesn’t mean they are useless. There’s also like 20 more metrics but I’m on my phone and couldn’t recall them all right now Also I don’t know where all of this nonsense about “forcing” to run CI/CD before branch merges and “slap on the wrist” - all our devs can run the test suites locally in docker and inside their IDE, nobody is forced to do anything in the pipeline severs, and also nobody gets a slap on the wrist for CI/CD failures, actually I like to see larger changes with more failures because it means the dev is trying and I consider this normal behaviour, your incorrect assumptions about our test environment and how we interpret these metrics sound like you’re projecting.

enord 4y ago
If you _need_ «metrics» it’s because you _really_ don’t understand the contribution of your reports. i.e. you are not a competent manager by the usual understanding of «competent».
- malux85 4y ago
  I’m not a manager, I’m a dev (well senior dev, that’s why I know about the metrics), but I am measured by the same standards as everyone else. When I became aware of then I viewed my own reports, and found areas I can improve on. I like it. The metrics actually showed no surprises when I saw them, had I been asked to name the worst 5 devs, I would have named the same people that the metrics would have highlighted.
  - _djo_ 4y ago
    So what you're saying is that it's useful for devs to be able to view their own stats for this on a no blame basis, and you have used your privileged position of access to them to improve your own performance, but you don't let the other devs do the same because you want to keep using these as secret metrics to manage them. Do I have that right?
    - malux85 4y ago
      No, I was asked my management to review the reports and help them interpret them, I would gladly give all the devs access to the reports, but that decision is not mine. I raised this suggestion with management, but since we had a handful of devs who were drastically underperforming we decided to help them out first with increased mentorship, in order not to embarrass them in front of their colleagues. I don’t know why you’re assuming the worst and malicious intent, it’s a great place to work, especially when we have a good vibe and all enjoy working together. I think what contributes to this positive environment is not employing developers who instantly assume malicious intent, and aren’t paranoid about being discovered as incompetent. These people are usually the ones most opposed to metrics, and also are the ones who the metrics show are the worst performers. Instead of objectively assessing the facts they attack the messenger, full of emotion and vitriol because of their insecurities and inabilities. There are many factors that go into firing a dev, if someone needs help we mentor them and grow them, but if someone has a bad attitude, assumes the worst and is full of negativity, then we are very quick to fire them.
      - _djo_ 4y ago