[jillesvangurp]

That book was written in the seventies, 45 years ago. It still has valid points but obviously a few things have changed in terms of how we do things. For example, we use version control systems these days and have sophisticated refactoring tooling.

But one of the things that hasn't changed is that we haven't really come up with any better metrics than time spent and nr. of things changed per time unit. There are a lot of people complaining these things are not representative (for the last five decades) but not a whole lot of people coming up with better productivity metrics and even fewer that did the leg work of actually validating their work in something that might pass scientific scrutiny (which is hard). If you do work in this space, you'll find yourself citing articles that are decades old.

These days, I tend to look at the activity statistics on github projects when joining a new project. It tells me in a glance of an eye who are the movers and shakers on a project in terms of lines of code added/removed and amount of commits and the time distribution of those commits. It's not perfect and doesn't tell you the complete story but it it's rarely completely wrong. Usually it's quite easy to spot patterns like Weekends, Christmas, vacations, and that people tend to get back energized from a good break (a little spike in productivity).

Also these numbers confirm the notion of a 10x programmer: a handful of people tends to be responsible for the vast majority of commits and line changes. Not all software engineers are created equally. Diffstats on pull requests tell me a lot as well; though of course these numbers are inflated by e.g. refactorings (more so on languages that have proper tools for this). But refactoring is a good thing and combined with code reviews tell you a lot about the quality of engineering.

[andrewstuart]

>> we haven't really come up with any better metrics than time spent and nr. of things changed per time unit

Does anyone give a shit about metrics any more? I seem to recall the whole metrics thing fizzled out entirely about 15 years ago.

[jillesvangurp]

Individual engineers don't and never did; managers/planners do (at least the more competent ones) and always did. There's a difference between running a bunch of primadonnas and running an engineering organization that gets things done on a schedule & budget consistently. It generally doesn't involve just winging it with some full stack ninjas and hoping for the best and tends to involve lots of planning, KPIs, metrics, resource planning, etc.

[downerending]

There are people that care, but metrics are as useless as ever for measuring programmer quality.

What's that law? Something like "Once a number becomes a goal, it ceases to be a useful measure."

[tfigment]

OKRs are a thing in tech circles. John Doerr wrote a book on it. My company rolled it out and most people struggle with coming up with meaningful metrics for their job.

[karatestomp]

We added OKR junk at an agency I worked at. For developers our options were:

1) use silly, useless metrics that are of a sort management will accept anyway,

2) uselessly tag along with initiatives in areas that are easier to measure (sales, marketing kind of though their metrics are still usually bad, just no-one cares),

3) start a year ago gathering data for a baseline for bad development metrics,

4) start 2-3 years ago gathering data for good development metrics, though they’ll probably still be pretty limited and narrow.

We picked 1 and 2 of course. What a waste of time. I wish anyone who wanted to be more than a line worker anywhere had to answer some basic questions about games and measuring things. Not just in development, managers and directors everywhere are, on average, terrible at it as far as I can tell.