'Programmers' is a coherent grouping in terms of "people who write code as a job", but it doesn't generalize well to "people whose daily work is similar". At the extremes, it's a bit like calling a typist, a copy editor, and a poet all "writers" because they produce text. That's a useful grouping when you're designing Microsoft Word, but it's a lot less useful when you're judging everyone on "lines written today". (I worry that there's a value implication in those three careers, and it's not intended; I just wanted vastly different daily workflows.)

And so the GitPrime result seems useful to know about, but there are clear cases like yours where its inapplicable. I suspect it would also run into issues with things like embedded or critical-failure code - NASA's commit patterns might have nothing in common with the industry standard. Even in my largely standard work, I realize that of my last two projects, one had ~50 commits and the other had ~3. The 3-commit one was a tech-debt project with lots of reading and documentation work, and I'm skeptical the two are at all comparable.

Even within similar work, I imagine things like branching strategies and test coverage alter commit frequency. For the near future, we'll probably continue to see the value of a given assessment stay company-and-role specific.

Those that self-identify as programmers may or may not be current HS or undergrad students. They often know a single language moderately well, maybe a second. Though they know the language, they often don't know what is available to them in the language of choice's standard library, so they often fall victim to re-inventing the wheel.

A developer has a few seasons under their belt. They may know several languages, and even have a fair grasp upon what the standard library of those various languages offer and so less likely to reinvent the wheel (although they still sometimes do). They're more likely to have a larger toolbox and decent grasp on when it's reasonable to use a certain tool (language or framework to tackle a new problem).

An Engineer is more likely to involve tools to solve problems. Got a performance problem? Going to profile instead of running by gut feel. If your company can afford it, vTune is a great tool here. Engineers are more adapt and comfortable using tools such as gdb, valgrind and strace on Linux or say Windbg on Windows. Bonus: they usually don't need to refer to the manuals to specify the correct commands or interpret the results. This doesn't come from accident or pure reading - you have to have real world practice and experience to know when and which tool is appropriate for the problem at hand.

The Senior Engineer knows all of the Engineer as I've briefly outlined above, but also takes the time to teach/mentor/coach the juniors around him or her when they see room for improvement in the junior. And this should not be in the form of "you're doing it wrong, do this instead", but there should be a "why" component in the "you're doing it wrong".