←back to thread

238 points aml183 | 1 comments | | HN request time: 0.258s | source

We are a remote company. Everything is going well. No plans to be in person, but I’d say we can do a better job at communicating. Any tips or articles to read?
Show context
paxys ◴[] No.42150868[source]
Make conversations public by default. If you use Slack, make team channels, project channels, announcement channels etc. all public. Discourage 1:1 and private communication unless really necessary, especially for engineering topics. This single change will have an immense impact on overall company culture.
replies(15): >>42150920 #>>42150993 #>>42151105 #>>42152006 #>>42152011 #>>42152642 #>>42155060 #>>42155607 #>>42158830 #>>42185599 #>>42185634 #>>42185891 #>>42185940 #>>42186302 #>>42192048 #
KronisLV ◴[] No.42155607[source]
> Discourage 1:1 and private communication unless really necessary, especially for engineering topics.

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.

replies(8): >>42156312 #>>42186441 #>>42186588 #>>42186857 #>>42186951 #>>42187222 #>>42187425 #>>42188414 #
1. serial_dev ◴[] No.42186951[source]
> 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, ...

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.