re: Is “Defensive Programming” actually healthy? VIEW POST

re: A PR should be merged if it solves a problem and does not break/prevent future changes. Then you can always do a followup PR to fix styling, compl...

Yup, I totally agree that if you want to raise the level of expertise on the team it has to come from mentoring. But it’s kinda important to mention that:

  • some people don’t want to pair program
  • on remote teams the code review is that primary mentoring opportunity

So while I love pair programming personally, sometimes I have to use the code review as my chance to learn and to teach.


I was speaking in broad terms, I totally agree, this is not a one shoe fits all situation. :)

Both of those examples however present a less than ideal situation, that could be resolved outside of the PR.

Such as, keep people that need to learn on site, and not remote. And to teach people the importance or pair programming, especially in a learning setting.

If these can’t be done, then the mitigating action can be to use the PR.

But it really should be considered last option, as it is super unproductive, compared to alternatives. At least in my humble experience.

“keep people that need to learn onsite”

I work at a 100% remote company, so there is no “onsite” location

“teach people the importance of pair programming”

Good idea! In fact I tried that today. I’m on a pair programming break right now. :) It’s tough going at first, but I’ll be sharing my learnings on it in a future article.

Thank you for the fun conversation. I hope you subscribe/ keep reading. I like having readers who challenge my assumptions! :)

code of conduct - report abuse