4 ms·

Show HN: How to keep your dev team happy

5 points by andrewpierno 7y ago

majkinetor 7y ago
Automatic dev team metrics sounds like a great thing. Gitlab has something integrated along those lines. I doubt tho in non-FOSS tool given that such metrics must be extensible - you simply do not know all the things I want to measure productivity.
existencebox 7y ago
But the _really hard_ question, which never seems to be answered in a way people will agree on, is how one measures "performance." 6 months ago I rewrote the entire frontend of a product, generating thousands of LOC a month. 6 months before that I was in GDPR-hell, entirely performing compliance, audit, and data management tasks. Almost 0 LOC, large portions of meetings/discussions/reading docs. Now I'm mentoring engineers, ramping up new hires, overseeing ops infra development, writing "some" code but mostly producing artifacts, reviewing specs/PRs, and sitting in meetings. Where was I most productive? How do I even measure that with a consistent set of KPIs? Even if we roll up to the team level, I'd ask the same question, given the volatility that can be present even in "user visible velocity" (and I shouldn't need to mention that "user visible velocity" is just one dimension of progress, and backing off to a meta-indicator like "story points" introduces its own problems in terms of estimation accuracy, black box tasks, scope creep, etc.)
- majkinetor 7y ago
  Good questions. There are even more problems. For instance if LOC is one part of the performance metric, one could add excessive comments and/or choose code formatting style that increases LOC. Conversely, some developers using concise styles and generally shorter code would be perceived as less performant. It seems to me that such 'low level' metrics are hard to grasp correctly and should only be used along with big number of other such metrics (commit frequency/distribution, tickets closed, builds run, lines reviewed, features built ...) and even then only as a additional info and not final word.
Chyzwar 7y ago
Suggested approach with silly metrics of commits or code changed is stupid. It is easy to game and does not measure the value of the individual. You want to have a happy dev team - pay fairly and keep work-life balance - provide opportunities to learn new things - allow choosing a tech stack and tools - allow choosing OS, the hardware of dev machine - treat the same as other stakeholders If you want to measure your team perfomance you just need to talk to them (shoking).

5 points by andrewpierno 7y ago

Automatic dev team metrics sounds like a great thing. Gitlab has something integrated along those lines. I doubt tho in non-FOSS tool given that such metrics must be extensible - you simply do not know all the things I want to measure productivity.

existencebox 7y ago

But the _really hard_ question, which never seems to be answered in a way people will agree on, is how one measures "performance." 6 months ago I rewrote the entire frontend of a product, generating thousands of LOC a month. 6 months before that I was in GDPR-hell, entirely performing compliance, audit, and data management tasks. Almost 0 LOC, large portions of meetings/discussions/reading docs. Now I'm mentoring engineers, ramping up new hires, overseeing ops infra development, writing "some" code but mostly producing artifacts, reviewing specs/PRs, and sitting in meetings. Where was I most productive? How do I even measure that with a consistent set of KPIs? Even if we roll up to the team level, I'd ask the same question, given the volatility that can be present even in "user visible velocity" (and I shouldn't need to mention that "user visible velocity" is just one dimension of progress, and backing off to a meta-indicator like "story points" introduces its own problems in terms of estimation accuracy, black box tasks, scope creep, etc.)

majkinetor 7y ago
Good questions. There are even more problems. For instance if LOC is one part of the performance metric, one could add excessive comments and/or choose code formatting style that increases LOC. Conversely, some developers using concise styles and generally shorter code would be perceived as less performant. It seems to me that such 'low level' metrics are hard to grasp correctly and should only be used along with big number of other such metrics (commit frequency/distribution, tickets closed, builds run, lines reviewed, features built ...) and even then only as a additional info and not final word.

Chyzwar 7y ago

Suggested approach with silly metrics of commits or code changed is stupid. It is easy to game and does not measure the value of the individual. You want to have a happy dev team - pay fairly and keep work-life balance - provide opportunities to learn new things - allow choosing a tech stack and tools - allow choosing OS, the hardware of dev machine - treat the same as other stakeholders If you want to measure your team perfomance you just need to talk to them (shoking).