Working at an established org right now, where the team is still remote first. I tried suggesting this, but got pushback and the team actually settled on the opposite. For example, they want any optional changes (e.g. suggestions) in pull requests not to be left as comments but discussed in private which 90% of the time means calls. They seem to dislike discussion threads in Slack and want meetings for things instead. I’ve also noticed things like the person who reviews a pull request being the one who has to merge it and essentially take responsibility for it, versus just giving approval and the author merging it and making sure everything is okay after CD.
I’m very much the opposite and prefer to have things in writing and like asynchronous communication. But when it is written messages, usually people either ask for a call or just do “Hey.” I actually made this a while ago hah: https://quick-answers.kronis.dev Either way, people also really seem to dislike writing README files, or all that many code comments, or making the occasional onboarding script or introducing tooling to do some things automatically. I don't get it.
What you have is people using a tool for different objectives, and when their chosen behavior hinders your objectives things seem out of whack.
I'm against shoving an eye of sauron communication hose down people's throats. I simply give my constructive feedback after the fact. E.g. when someone dm's me I say, "so-so is waiting for this to be done for their thing, so mention this part in the channel." or "the other team would need to know this for a refactor, so add this info to the wiki." If someone feels the need for dm'ing for some psychological safety so be it. But the cost of that safety is additional communication overhead for filling in gaps that the person should be ok with. And the people that value the psychological safety they gain usually don't object or have no grounds to object to a duplication of communication to fill those gaps when someone points out those gaps exists.
Realistically, if the team decides that synchronous communication and not keeping too much of a historic record works best for them then I guess that's it, it's up to them to deal with that long term, since I'm just a colleague and it'd be counterproductive to try and change everyone's mind. If I did something like that, I'd probably just come across as a bit of a jerk.
You can show people the benefits of a particular approach but whether they accept that those are benefits (e.g. looking at a pull request of mine from 2-5 years ago that shows context for why a certain change was done a particular way, has images of benchmarks, descriptions of other factors to consider etc.) is up to them. Same for synchronous communication: to them, being able to call someone and have a conversation might be easier and more productive than the alternatives, they might just be unbothered by context switching or interruptions... somehow.
Though one could probably argue that some practices (like version control and CI/CD, for example) are objectively good to have, regardless of personal preference, for the sake of the development landscape not looking like The Wild West. How far that might extend, however, I have no idea.
This sounds like a hellish existence to me, tbh.
I'm not saying that either my preference or these folks' preference is objectively correct, but I am saying that I don't think I could work in this sort of environment long-term.
- Public communication about pull requests encourages knowledge sharing, not just between reviewer and reviewed, but anyone reading. It stores this knowledge sharing long term, so that any future reader can read up on the context and back-and-forth done to get to the chosen solution.
- Meetings are transient. Unless someone takes minutes or a recording/transcription is made and shared, it means the communication in that meeting will be duplicated when it has to be shared elsewhere.
- While I do think the author and reviewer share responsibility for the code in question, merging should be done by the author so that they know when it was merged and can jump in if something goes wrong. That said, in an ideal world it shouldn't matter who hits the merge button, and in fact, something should be automatically merged if it's approved and the pipelines are green, but that's uncommon.
I'd take notes if you ever notice waste from e.g. private / unrecorded meetings, or if someone has to repeat things said in a meeting; take it to a manager and hint that there is a lot of waste.
But ultimately, don't make it a hill to die on. I dislike people going "hey can we do a call" as well - I'm usually busy / elsewhere / focused on something, and there not even being a hint on what it's about is aggravating. The person asking it clearly believes their time and attention is more important (as in "I need feedback on this now"). Sending people that link (after ignoring them for X amount of time after sending a "hey") is passive-aggressive, but educational. Ultimately though, it should be higher-ups that encourage a culture and the etiquette of asynchronous communication.
I worked on some teams that had that and it wasn't bad at all. In the end, what's on the main branch is everyone's shared responsibility (...was our thinking).
It encourages real PR reviews, where the reviewer is paying attention to the changes, spend time on the review until they understand what is happening and why, and when they feel comfortable, they merge it as if the PR were their own. It doesn't sound efficient, but in the end it means you always have a backup person to turn to in case there is an issue, and we mainly only had "exotic" bugs.
This only works with the right team and leadership. It was completely normal to say "yesterday morning I spent half the day reviewing that PR".
OTOH, I was also on a team where PR approval means someone scrolled through your changes in 1 minute and didn't find anything blatantly wrong, go ahead and merge and hope for the best. This team broke the main branch in a significant way 2-3 times a week.
Meanwhile if you have a call to discuss it or do it in person, you can rapidly answer any questions and get the reviewer to fully understand what they are looking at.