This is an advertisement for their git commit-based metrics service, which is about as awful as one can get.
I get these emails constantly as I have an admin account on our enterprise Pluralsight account, and I manage a developer team, and honestly this idea of “let’s use commit metrics to judge your developers” is not something I think anyone would welcome. Let me share a recent email they sent:
Hey Adam,
You can’t lead to what you can’t measure, and every day Engineers create troves of data that are currently unused.
Sales, marketing, and finance use data daily to refine their processes.
However, your engineering team’s git history is an untapped goldmine of data that can help you manage your teams and communicate with external stakeholders. There’s almost limitless data in your Git history waiting to be used.
Ready to advocate for your team with concrete metrics?
I have some availability this week to connect, when works for you?
This reads like a horoscope. And within it are really questionable assertions. “A developer in the zone produces evenly spaced, similarly sized pull requests”. Do people actually believe this?
Well, I do think there is valuable data in the git history but not to judge developers. For example, the files with the most commits or the most authors are hot spots and a refactoring should be considered.
I flirted with Codermetrics[1] after reading the O’Reilly book back in the day. I think it could genuinely be useful as a tool for self-improvement. Inevitably, though, it would be turned into a performance management tool and thence gamed or otherwise take on a life of its own.
In my personal experience I’ve seen a fair number of very talented, but young, developers combine hoarding and domain championing as a way to establish themselves and, I think, stave off boredom and burnout. In these cases, I suspect that the answer is to make sure these individuals are challenged and push them to work more closely with their (perhaps less skillful or less motivated) teammates.
I think you’d need to be pretty careful about judging the personalities involved. Making sure they’re challenged is almost certainly the right call, but if someone is already altering their work style to stave off boredom and burnout, pushing them to work more closely with less-skillful or less-motivated teammates may cause them to become even more bored and burned out rather than becoming energized by the opportunity to mentor.
Obviously domain championing and hoarding are not healthy for a team, though.
This is a well-thought-out list. I’ve seen nearly all of these at one point or another in my career, and the situations have often played out the way the paper predicts.
I’m a bit disappointed that they take it as an absolute given, not even worth mentioning, that everyone is using Scrum or something like it; while many of the high-level patterns have nothing to do with a specific agile methodology, there are a lot of “look for thing X at point Y in your sprints to see if this is happening” guidelines that make no sense for, say, a team that’s using Kanban where there’s no concept of a “sprint.”
The other assumption I’d call out, though I think this is just an artifact of the document being written for the kind of audience that would buy Pluralsight’s products, is that the team is large and is part of a mature organization with clearly-defined roles. A number of the patterns have pretty different implications if your engineering organization is very small, if the developers are also the product owners, or if you’re exploring a problem space rather than working to implement a well-understood solution to a well-understood problem before a well-understood deadline.
But those are minor complaints; generally this is a nice piece of work.
I can’t agree with the “clean as you go” engineer. I guess this depends on how one defines adjacent code. Refactoring working legacy code adds unnecessary risk and increases time to deliver the change that was asked of you.
I once worked at a project which had excellent test coverage. Automatic unit test, functional test, integration tests and acceptance / system / scenario test.
It was incredibly easy to work there. We where always pair programming and we always refactored code. We often refactored code as part of understanding the code which we where working in.
The refactoring itself never really caused any problems as far as I can remember.
However, this was a very special place, and a long time ago. I’ve never seen such a well functioning team or code base since then.
There is a saying, that all code that is easy to refactor will ultimately be replaced by code that is hard to refactor (because nobody will want to touch the hard-to-refactor code). That’s why I’m generally against refactoring as well, especially during work on a clearly-defined task.
Unless there is an explicit task to perform refactoring, then I’m not against it ;), but it must be calculated, i.e. main question is what benefits refactoring will provide, and what are the risks.
Had an encounter with a Hero a few years back - he stonewalled on an issue for over a month (“you lot can’t fix it”), blocking two data architects, then when I gave in and fixed it, immediately reverted my fix and put his own in instead. I quit a week later.
I suppose he was technically correct in that his fix solved the problem but then my fix also solved the problem. He just didn’t want anyone else making changes to his* code.
*He wasn’t actually on the project any more; just refused to let go and management couldn’t really do anything.
I can relate to these, both as someone doing the very things they call out, or observing it in others. Domain Champion especially… when I started working I was very guilty of this until I realized how much of a liability it made me. Now I just teach teach teach (well, I did when I was at a larger company… now that I’m in a small place with 3 engineers it’s back to violating all of these principles, lol).
Domain champion is weirdly phrased, I love when there’s one person who actually has an overview, knows what the thing does and can do reviews. It’s only bad if no one else does, or no one wants to learn or the champion blocks access for others.
This is an advertisement for their git commit-based metrics service, which is about as awful as one can get.
I get these emails constantly as I have an admin account on our enterprise Pluralsight account, and I manage a developer team, and honestly this idea of “let’s use commit metrics to judge your developers” is not something I think anyone would welcome. Let me share a recent email they sent:
This reads like a horoscope. And within it are really questionable assertions. “A developer in the zone produces evenly spaced, similarly sized pull requests”. Do people actually believe this?
If the opposite means giving devs an hour between each meeting to complete their work, being in the zone is a wonderful thing.
Well, I do think there is valuable data in the git history but not to judge developers. For example, the files with the most commits or the most authors are hot spots and a refactoring should be considered.
Maybe welcomed by the ones doing the judging; the ones being judged, not so much. :)
I flirted with Codermetrics[1] after reading the O’Reilly book back in the day. I think it could genuinely be useful as a tool for self-improvement. Inevitably, though, it would be turned into a performance management tool and thence gamed or otherwise take on a life of its own.
[1] https://codermetrics.org/
In my personal experience I’ve seen a fair number of very talented, but young, developers combine hoarding and domain championing as a way to establish themselves and, I think, stave off boredom and burnout. In these cases, I suspect that the answer is to make sure these individuals are challenged and push them to work more closely with their (perhaps less skillful or less motivated) teammates.
I think you’d need to be pretty careful about judging the personalities involved. Making sure they’re challenged is almost certainly the right call, but if someone is already altering their work style to stave off boredom and burnout, pushing them to work more closely with less-skillful or less-motivated teammates may cause them to become even more bored and burned out rather than becoming energized by the opportunity to mentor.
Obviously domain championing and hoarding are not healthy for a team, though.
This is a well-thought-out list. I’ve seen nearly all of these at one point or another in my career, and the situations have often played out the way the paper predicts.
I’m a bit disappointed that they take it as an absolute given, not even worth mentioning, that everyone is using Scrum or something like it; while many of the high-level patterns have nothing to do with a specific agile methodology, there are a lot of “look for thing X at point Y in your sprints to see if this is happening” guidelines that make no sense for, say, a team that’s using Kanban where there’s no concept of a “sprint.”
The other assumption I’d call out, though I think this is just an artifact of the document being written for the kind of audience that would buy Pluralsight’s products, is that the team is large and is part of a mature organization with clearly-defined roles. A number of the patterns have pretty different implications if your engineering organization is very small, if the developers are also the product owners, or if you’re exploring a problem space rather than working to implement a well-understood solution to a well-understood problem before a well-understood deadline.
But those are minor complaints; generally this is a nice piece of work.
I can’t agree with the “clean as you go” engineer. I guess this depends on how one defines adjacent code. Refactoring working legacy code adds unnecessary risk and increases time to deliver the change that was asked of you.
I once worked at a project which had excellent test coverage. Automatic unit test, functional test, integration tests and acceptance / system / scenario test. It was incredibly easy to work there. We where always pair programming and we always refactored code. We often refactored code as part of understanding the code which we where working in. The refactoring itself never really caused any problems as far as I can remember.
However, this was a very special place, and a long time ago. I’ve never seen such a well functioning team or code base since then.
There is a saying, that all code that is easy to refactor will ultimately be replaced by code that is hard to refactor (because nobody will want to touch the hard-to-refactor code). That’s why I’m generally against refactoring as well, especially during work on a clearly-defined task.
Unless there is an explicit task to perform refactoring, then I’m not against it ;), but it must be calculated, i.e. main question is what benefits refactoring will provide, and what are the risks.
Had an encounter with a Hero a few years back - he stonewalled on an issue for over a month (“you lot can’t fix it”), blocking two data architects, then when I gave in and fixed it, immediately reverted my fix and put his own in instead. I quit a week later.
So … was he right?
I suppose he was technically correct in that his fix solved the problem but then my fix also solved the problem. He just didn’t want anyone else making changes to his* code.
*He wasn’t actually on the project any more; just refused to let go and management couldn’t really do anything.
I can relate to these, both as someone doing the very things they call out, or observing it in others. Domain Champion especially… when I started working I was very guilty of this until I realized how much of a liability it made me. Now I just teach teach teach (well, I did when I was at a larger company… now that I’m in a small place with 3 engineers it’s back to violating all of these principles, lol).
Domain champion is weirdly phrased, I love when there’s one person who actually has an overview, knows what the thing does and can do reviews. It’s only bad if no one else does, or no one wants to learn or the champion blocks access for others.