2 ms·

This sounds interesting! So instead of someone else asynchronously asking clarifying questions of the author, one person synchronously asks clarifying questions

by kqr 4y ago

This sounds interesting! So instead of someone else asynchronously asking clarifying questions of the author, one person synchronously asks clarifying questions of someone who is not the author? I really like the idea that the artifact should be understandable to people who don't have immediate access to the author. What was the process if the artifact was "rejected" in this type of review and neither half of the pair had enough understanding to fix it?

m3047 4y ago
Good questions! > instead of ... asynchronously Yes. > What was the process if the artifact was "rejected" We only did it once a week and all code was not reviewed. Well, I should say not all code was formally reviewed. And we had tests, and some of them came from "real" Engineering (level 1). We didn't have 100% coverage, but "more tests" was a frequent outcome, and it was implicit that this wasn't limited to the specific artifacts which were reviewed. There might be a timing or integrity issue and so there might be some attempt to determine what the appropriate scope of testing was (the emails / meetings I mentioned). I don't recall that anything was ever rejected in one of these. [Edit - added] This was mostly front-loaded, because we never wrote code until there was some consensus on what change was needed. So some of these were somebody bringing a "problem child" and either walking through it or enjoying the entertainment as some rando did it. The process existed with the implicit goal of levelling everybody into some shared framework of discussing code. We would reach out to peers all the time for informal review and it was pretty frictionless (email somebody with a branch and particular range of LOC). About the only time you wouldn't reach out like that was if you had pretty close to 100% test coverage. 8-) > neither ... of the pair had enough understanding to fix it In another fine example of "moral hazard for good" that never happened! Less facetiously those ended up being the requirements / architecture issues. So as far as the process was concerned the pair reached a consensus. > synchronously asks clarifying questions of someone who is not the author Yes, about half the time the person explaining the code was the one who'd never seen it before that moment. LOL. Brutal. OTOH I don't know if it's more brutal than explaining code to someone whose job doesn't actually include coding... Just different. Like I said, it improves people's ability to talk about code and creates a culture that makes it easier to seek help the rest of the time.
- kqr 4y ago
  Thank you for sharing! It's clear you've thought about this a bit. Do you happen to have a blog or similar where you publish more of your thoughts?
  - m3047 4y ago
    > Do you happen to have a blog No I do not. I've got an unindexed web server where I post random stuff from time to time, and occasionally I write articles on LinkedIn. I'm heartened you care. I care about quality, what gets me up in the morning is helping people up their game. But like security (which is largely a quality problem) quality is something you do not something you buy (baseball comment farther upthread) and it's been an even harder sell since the VCs were given zero interest money to throw around. The disciplines where people (are supposed to) care about quality and measurement seem to be captured by vendors with checklists and pseudo managers with alphabet soup after their names. I'm in a niche market which largely gets papered over by those parties. Most of what I'd write has been or would be co-opted and therefore would sound the same as what they'd write and I'd just be lost in the noise. I'm open to smart ideas for finding the people who care enough about quality to realize that it's actually something you have people do utilizing the expensive toys you buy.

by kqr 4y ago

m3047 4y ago

Good questions! > instead of ... asynchronously Yes. > What was the process if the artifact was "rejected" We only did it once a week and all code was not reviewed. Well, I should say not all code was formally reviewed. And we had tests, and some of them came from "real" Engineering (level 1). We didn't have 100% coverage, but "more tests" was a frequent outcome, and it was implicit that this wasn't limited to the specific artifacts which were reviewed. There might be a timing or integrity issue and so there might be some attempt to determine what the appropriate scope of testing was (the emails / meetings I mentioned). I don't recall that anything was ever rejected in one of these. [Edit - added] This was mostly front-loaded, because we never wrote code until there was some consensus on what change was needed. So some of these were somebody bringing a "problem child" and either walking through it or enjoying the entertainment as some rando did it. The process existed with the implicit goal of levelling everybody into some shared framework of discussing code. We would reach out to peers all the time for informal review and it was pretty frictionless (email somebody with a branch and particular range of LOC). About the only time you wouldn't reach out like that was if you had pretty close to 100% test coverage. 8-) > neither ... of the pair had enough understanding to fix it In another fine example of "moral hazard for good" that never happened! Less facetiously those ended up being the requirements / architecture issues. So as far as the process was concerned the pair reached a consensus. > synchronously asks clarifying questions of someone who is not the author Yes, about half the time the person explaining the code was the one who'd never seen it before that moment. LOL. Brutal. OTOH I don't know if it's more brutal than explaining code to someone whose job doesn't actually include coding... Just different. Like I said, it improves people's ability to talk about code and creates a culture that makes it easier to seek help the rest of the time.

kqr 4y ago
Thank you for sharing! It's clear you've thought about this a bit. Do you happen to have a blog or similar where you publish more of your thoughts?
- m3047 4y ago
  > Do you happen to have a blog No I do not. I've got an unindexed web server where I post random stuff from time to time, and occasionally I write articles on LinkedIn. I'm heartened you care. I care about quality, what gets me up in the morning is helping people up their game. But like security (which is largely a quality problem) quality is something you do not something you buy (baseball comment farther upthread) and it's been an even harder sell since the VCs were given zero interest money to throw around. The disciplines where people (are supposed to) care about quality and measurement seem to be captured by vendors with checklists and pseudo managers with alphabet soup after their names. I'm in a niche market which largely gets papered over by those parties. Most of what I'd write has been or would be co-opted and therefore would sound the same as what they'd write and I'd just be lost in the noise. I'm open to smart ideas for finding the people who care enough about quality to realize that it's actually something you have people do utilizing the expensive toys you buy.