Live data from Hacker News

Why public chats are better than direct messages

teamplify.com

131–139 of 139 posts

Re: Why public chats are better than direct messages

#131
post #32

Earlier quoted context omitted.

Honestly, that does sound difficult. I get what you're trying to achieve, but if I'm trying to land a change, having a synchronous conversation (ideally in person) will resolve any misunderstandings between us on the order of minutes. Having an asynchronous back-and-forth takes on the order of hours or even days. And what do you get for your time? A nice record you can look back on? What are you going to use that for…

I'm happy that you haven't made the opposite experience. > if I'm trying to land a change, having a synchronous conversation (ideally in person) will resolve any misunderstandings between us on the order of minutes. That does not match with my experience. Imagine I wrote a comment on Steve's PR in foo.py line 31 that said "I see what you are doing here. Do you think this would be more readable if you used the itertoo…

Why would someone join a call to read you the itertools documentation? Seems like a very contrived example. If it were possible to use itertools, wouldn't they just research that, update the PR, and say OK in a comment? The fact that itertools was used for the implementation is not something that even needs to be documented as part of the "public discourse"

Re: Why public chats are better than direct messages

#132
post #131

Earlier quoted context omitted.

I'm happy that you haven't made the opposite experience. > if I'm trying to land a change, having a synchronous conversation (ideally in person) will resolve any misunderstandings between us on the order of minutes. That does not match with my experience. Imagine I wrote a comment on Steve's PR in foo.py line 31 that said "I see what you are doing here. Do you think this would be more readable if you used the itertoo…

Why would someone join a call to read you the itertools documentation? Seems like a very contrived example. If it were possible to use itertools, wouldn't they just research that, update the PR, and say OK in a comment? The fact that itertools was used for the implementation is not something that even needs to be documented as part of the "public discourse"

> Seems like a very contrived example.

It was based on my real-life experience working with a colleague from another team.

> If it were possible to use itertools, wouldn't they just research that, update the PR, and say OK in a comment?

Time spent on a call is time you are publicly perceived as working. Time you spend researching itertools is time during which someone can interrupt you by pinging you in Slack. In that employee's shoes, it seems clear which one of those gives you less of a headache at the end of the day.

Politics aside: Exactly what you describe - the capability to research a library, respond to a PR comment concisely and appropriately - are skills that no one learns during a CS degree, nor doing code monkey work. Ideally, this is the sort of thing a junior engineer gets taught during their first years on the job if supported by a capable mentor. But if they don't have one? Tough.

Re: Why public chats are better than direct messages

#133
post #131

Earlier quoted context omitted.

Why would someone join a call to read you the itertools documentation? Seems like a very contrived example. If it were possible to use itertools, wouldn't they just research that, update the PR, and say OK in a comment? The fact that itertools was used for the implementation is not something that even needs to be documented as part of the "public discourse"

> Seems like a very contrived example. It was based on my real-life experience working with a colleague from another team. > If it were possible to use itertools, wouldn't they just research that, update the PR, and say OK in a comment? Time spent on a call is time you are publicly perceived as working. Time you spend researching itertools is time during which someone can interrupt you by pinging you in Slack. In tha…

> Time spent on a call is time you are publicly perceived as working. Time you spend researching itertools is time during which someone can interrupt you by pinging you in Slack. In that employee's shoes, it seems clear which one of those gives you less of a headache at the end of the day.

I think you have a very strange view of development work. At least in my experience, a vast majority of work involves going off on your own and implementing things, which often involves reading documentation. Meeting with a colleague is also considered work, but I wouldn't say meeting with a colleague is somehow considered "more work like" than solo development or that many developers prefer one form of work over the other.

Re: Why public chats are better than direct messages

#134
post #133

Earlier quoted context omitted.

> Seems like a very contrived example. It was based on my real-life experience working with a colleague from another team. > If it were possible to use itertools, wouldn't they just research that, update the PR, and say OK in a comment? Time spent on a call is time you are publicly perceived as working. Time you spend researching itertools is time during which someone can interrupt you by pinging you in Slack. In tha…

> Time spent on a call is time you are publicly perceived as working. Time you spend researching itertools is time during which someone can interrupt you by pinging you in Slack. In that employee's shoes, it seems clear which one of those gives you less of a headache at the end of the day. I think you have a very strange view of development work. At least in my experience, a vast majority of work involves going off o…

> I think you have a very strange view of development work.

I did not present my view of development work - I presented that employee's view of development work.

> At least in my experience, a vast majority of work involves going off on your own and implementing things, which often involves reading documentation. Meeting with a colleague is also considered work, but I wouldn't say meeting with a colleague is somehow considered "more work like" than solo development or that many developers prefer one form of work over the other.

In my experience, every single developer wishes they could spend less time in meetings and more time "doing real work" (their perspective, not mine). Everyone with the opposite view is promoted out of being an Individual Contributor.

Re: Why public chats are better than direct messages

#135

Earlier quoted context omitted.

Speaking in public can invite unwanted opinions. There’s always someone who wants to argue, seemingly for sport. Closed channels for teams are good but not everything is a democracy. I let my team make decisions but I can veto any of them, if needed.

Exactly. There is a goal to be achieved - building some feature, say - and we need to find the best way to achieve that goal with the people on hand. If forcing all communication to be done in public makes the goal harder to achieve, then ffs do something else. Don't just force people to be inefficient because of some dogma. The goal is not "make all communication public". The goal is to get the job done.

> The goal is not "make all communication public". The goal is to get the job done.

Just adding that "get the job done" shouldn't be confused with personal productivity. Many younger/inexperienced devs that are highly motivated go through a phase (some get stuck here) that optimizes their personal productivity above the team's productivity. You end up with pockets of people that share knowledge (or hoard knowledge) with others left behind. You also end up with different subsets of people making different decisions, younger devs clinging to each other for feedback/guidance (yikes), and way more thrash that needed.

Re: Why public chats are better than direct messages

#136

Earlier quoted context omitted.

It's not my job to fix someone else's dysfunction. It's their job to speak in public about work. Being uncomfortable isn't a veto. All your criticism is just framing. It presupposes pathological work practices are actually just personal quirks. If you can't type a question in a slack with 20 members you are basically useless.

I’m actually saying that pathological work rules will mean you don’t get the most out of your team.

This is just word salad. Youre defining pathological work rules by the subjective mental state of fearful dysfunctionals. This is backwards and incoherent.

Re: Why public chats are better than direct messages

#137

Earlier quoted context omitted.

The private chats should be for non-work conversations. DMs are for private/personal/rapport-building conversations. There's no reason you can't have both going at the exact same time.

Except sometimes private chats are the best place for work conversations.

I already accounted fort that: I said should not must.

Re: Why public chats are better than direct messages

#138
post #75

Earlier quoted context omitted.

> Some people (especially people not using their first language) can find working in public stressful Which is fine coming in, but the culture should be one that reassures these folks that public forums in the company are safe regardless of their proficiency with the main language. Half of the people I work with speak English as a 2nd language (most are very proficient since they're mostly French-Canadian but there a…

On the opposite spectrum there's the experience I had at a Japanese company as a fluent but not native person. All communication happened in public, and I was made fun of whenever I had to ask clarifying questions. The entire team would see this and got the impression that I was hard to work with since asking questions can be seen as rude in Japanese, and the Japanese staff would understand things the first time arou…

I think you just proved my point? I said it's a culture thing and you gave an example of terrible work culture.

Re: Why public chats are better than direct messages

#139
post #75

Earlier quoted context omitted.

On the opposite spectrum there's the experience I had at a Japanese company as a fluent but not native person. All communication happened in public, and I was made fun of whenever I had to ask clarifying questions. The entire team would see this and got the impression that I was hard to work with since asking questions can be seen as rude in Japanese, and the Japanese staff would understand things the first time arou…

I think you just proved my point? I said it's a culture thing and you gave an example of terrible work culture.

I wasn't disagreeing with you. I agree culture is the most important factor regardless. Maybe doing work in the open can exacerbate a toxic culture, but idk it was just one experience.
Post reply on HN