> Denisov-Blanch acknowledged that counting code commits is a flawed way to measure productivity but it can reveal inactivity.
Heh, a few years back I spent like a month diagnosing a problem where the fix was two hexadecimal characters on the same line.
Some bespoke hardware was dying by kernel panic within ~30s of starting up, after a bunch of library/kernel/vendor-drivers upgrades. I don't think a month is too bad considering I had zero C/C++ experience (yes, I pointed this out to them repeatedly), each recompile/test/lab-install cycle was really long, and the problem wasn't really in the kernel at all, but actually a pre-existing collision/corruption of the memory space where the kernel was being loaded.
I think this article and its "research" is not healthy. Anecdotally, I've spent many hours debugging issues with code, where the fix was 1-2 lines of code. Or what if I am an engineer that "--amends" my every commit? What if I pair program? If a "researcher" looked at my productivity for that particular timeline and determined I was a "ghost" engineer, what would happen? Would the research be truthful?
There are lazy developers out there, but we know who they are. Most managers do, too.
The article, does make the caveat at the end, but I think the damage is done:
>> Before you start side-eyeing your coworkers, it’s worth noting that measuring productivity in software engineering is notoriously tricky. Commit counts or hours logged are often poor indicators of true impact. Some high-performing engineers—the mythical “10x engineers”—produce significant results with fewer, well-thought-out contributions.
Soon CTOs will be making performance judgements based solely on commits! Forcing. Developers. To. Commit. Every. Single. Little. Change.
And yet there are still huge profits. Seems like some people (execs, for example) are still making way too much money. Try giving more of that to your workers and lemme know if morale and productivity improve.
Heh, a few years back I spent like a month diagnosing a problem where the fix was two hexadecimal characters on the same line.
Some bespoke hardware was dying by kernel panic within ~30s of starting up, after a bunch of library/kernel/vendor-drivers upgrades. I don't think a month is too bad considering I had zero C/C++ experience (yes, I pointed this out to them repeatedly), each recompile/test/lab-install cycle was really long, and the problem wasn't really in the kernel at all, but actually a pre-existing collision/corruption of the memory space where the kernel was being loaded.
reply