
Show HN: How to keep your dev team happy - andrewpierno
https://medium.com/@AndrewPierno/how-to-keep-your-developers-happy-22c4264a809a
======
Chyzwar
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).

------
majkinetor
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
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
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.

