I found an interesting failure mode already: one person creates a whole bunch of "golden master" / snapshot system tests, where the expected outputs are all in their own files. At least one of these tests fails every time any code is changed, forcing the programmer who made the change to update the snapshot. Et voila, the creator of the tests gets credited with "influence."
Wouldn't that apply in general to high coupling? I mean, a test that has to change whenever the implementation changes is just a specific case of high coupling, isn't it?
Correct. From www.testdesiderata.com I'd call those tests in general "structure coupled". Snapshot tests testing to be behavior coupled (which is good) but produce many false failures (the system is fine but the test fails). These false failures can be mitigated somewhat with good tooling (see also my sponsor Screenshotbot.
I'd love to see a way to track the propagation of coding styles across a codebase. I'm thinking of the common scenario where an engineer introduces a distinct way of structuring a class or function and then that pattern (or anti-pattern) gets picked up and replicated elsewhere. Is there a name for this?
That's an interesting behavior to track but different. I'm thinking about spotting diffs that just insert blank lines in functions being examples of that tidying. Could you produce a model that would spot many/all of the tidyings? And then, since these are metrics, how would folks abuse/game those metrics?
I wonder how the following type of developer might influence (see what I did there?) this analysis:
There's a developer persona I've encountered many times in my experience, a persona I call Edison. Edison is not a junior programmer, he has experience and skills that allow him to effectively solve problems on his own. However, Edison tends to invent solutions for every story or incident he takes on, rather than looking around the code base to see if similar problems or needs have been solved before. Edison will tend to create lots of new files (right? I think so), but he's not actually playing nice with the rest of the team who are better about reuse and following existing patterns. As such, many of Edison's inventions get worked on by other team members who come along and either de-emphasize their use or work to bring them in line with established other solutions.
Not all of Edison's inventions are "mistakes," sometimes he has a novel _and_ better solution. But that's not the common case.
To steal an idea from another commenter, Edison's _impact _might be large, but his _influence_ isn't necessarily. In fact, you might not (probably don't) want to reward or encourage that impact very much. Lots of variables at play in that decision, but speaking in generalizations here.
How do we differentiate between the edits that were made to
1. fix something that was not working
versus
2. edits that were made to add functionality?
I guess more edits of type 1 would mean that the code had a lot of issues in the first place, which does not imply influence.
Type 2 implies influence - I agree.
That’s the art of it, to figure out questions like yours. Also why you don’t create short-sighted incentives like “must be in the top right quadrant”.
I found an interesting failure mode already: one person creates a whole bunch of "golden master" / snapshot system tests, where the expected outputs are all in their own files. At least one of these tests fails every time any code is changed, forcing the programmer who made the change to update the snapshot. Et voila, the creator of the tests gets credited with "influence."
I wanted to try it with only source code. But that risks missing important decisions. Updating a snapshot test is not an important decision.
Wouldn't that apply in general to high coupling? I mean, a test that has to change whenever the implementation changes is just a specific case of high coupling, isn't it?
Correct. From www.testdesiderata.com I'd call those tests in general "structure coupled". Snapshot tests testing to be behavior coupled (which is good) but produce many false failures (the system is fine but the test fails). These false failures can be mitigated somewhat with good tooling (see also my sponsor Screenshotbot.
I'd love to see a way to track the propagation of coding styles across a codebase. I'm thinking of the common scenario where an engineer introduces a distinct way of structuring a class or function and then that pattern (or anti-pattern) gets picked up and replicated elsewhere. Is there a name for this?
It reminds me of the diffusion of innovation as in crossing the chasm
I wonder if you could detect tidyings in a diff?
Would lines deleted serve as a heuristic? I know that doesn't capture all tidyings but is it an ok place to start?
Also, how do you think about engineer influence vs impact in this post?
That's an interesting behavior to track but different. I'm thinking about spotting diffs that just insert blank lines in functions being examples of that tidying. Could you produce a model that would spot many/all of the tidyings? And then, since these are metrics, how would folks abuse/game those metrics?
Eep, sorry. I misread “tidying” as general cleaning up, not the distinct concept from your writings. I feel very silly now.
I know you detail a bunch of different tidyings. Is there one that you think shows up most often? Or one that lends itself well to detection?
Tidying ™️
Eep, sorry. I misread “tidying” as general cleaning up, not the distinct concept from your writings. I feel very silly now.
It's called "cross selling". No need to blush.
This is definitely a Substack issue, because your images have a transparent background, they are effectively invisible in dark mode 🙃
Data without understanding leads to bad decisions. I think it had to be data + the feedback of people around the programmer
I wonder how the following type of developer might influence (see what I did there?) this analysis:
There's a developer persona I've encountered many times in my experience, a persona I call Edison. Edison is not a junior programmer, he has experience and skills that allow him to effectively solve problems on his own. However, Edison tends to invent solutions for every story or incident he takes on, rather than looking around the code base to see if similar problems or needs have been solved before. Edison will tend to create lots of new files (right? I think so), but he's not actually playing nice with the rest of the team who are better about reuse and following existing patterns. As such, many of Edison's inventions get worked on by other team members who come along and either de-emphasize their use or work to bring them in line with established other solutions.
Not all of Edison's inventions are "mistakes," sometimes he has a novel _and_ better solution. But that's not the common case.
To steal an idea from another commenter, Edison's _impact _might be large, but his _influence_ isn't necessarily. In fact, you might not (probably don't) want to reward or encourage that impact very much. Lots of variables at play in that decision, but speaking in generalizations here.