[zibby8]

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? Most changes likely aren't ever referenced again. Even if you, by some small chance, look back on a specific change and find the record missing, you just go "oh well, I guess we won't know exactly why that was done" and move on your with your life.

[jrootabega]

Let's not forget that you can go in both directions. If you capture what you want to talk about publicly, you still have the option of having a private direct conversation about that. I agree that blindly following public-only-async-only all the time is not good. I just happen to think that the balance is unfairly and unhealthily tipped towards the direct interruption pattern.

I think a lot of the effort that people perceive has to go towards async discussions is actually just resistance effort, too. When multiple people embrace it it can be surprisingly easy.

And a lot of times people push the async method because the environment is already difficult -- for them. Sometimes certain team members get bogged down in focus work and want to get that done as much as others want to have a discussion. How to have good conversations in the ideal workplace is one thing; how to have them in more dysfunctional situations is another.

[ThePadawan]

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 itertools from the standard library instead of implementing this yourself?".

Now Steve asks me if he can have a call with me about my comments. I join the call and he opens the PR. He reads my comment aloud, then he says "OK" and opens up the documentation for itertools and reads it silently. I'm still in the call.

This goes on for every comment.

I see what you mean and wish that that was how it worked - and I've made good experiences doing this after 90% of comments in the "written comments" stage are worked on by the author. But just skipping it sounds like insanity to me.

[zibby8]

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"

[ThePadawan]

> 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.

[zibby8]

> 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.

[ThePadawan]

> 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.

[rodrigodlu]

If you work on a healthy team, public comments are better from my POV.

I can remember many times, specially on new teams that I just joined, that by reading PRs, specially following https://conventionalcomments.org/, I get much faster the motto and the spirit of the team.

You have the context and the focused discussions on the same place. You can also check how much time it took to deliver and even connect easier to the outcomes of the deliverables.

If the discussion gets too subjective, use the team private chat, with threaded comms, then a direct call.

I know it depends on the urgency as well, but we should strive for general efficiency, not efficiency only during rush / at the end of sprint.

That's why also I prefer to open WIP PRs with incomplete code. Open discussions beforehand.

Also, repeated questions and similar problems can be retrieved from the chat / comments history.

Now, for early designs, spikes, initial research on an epic/hard tasks, needs some sync comms, followed by some asynchronous comments and questions.

Even things like "yesterday we discussed during a call x, y and z, and we agreed on w. it still holds up? In this case, I will use the strategy N to develop the solution, please comment back if you changed your mind".

It helps me a lot, and the people that I asked about this kind of message are heavily positive on it, because it's neutral enough and consolidates the agreement.

Then after a few weeks working close to someone (same team, for instance), I can make that phrase shorter, because we established a protocol.

Now that said, under my new contract, the entire team is almost silent on chat and everything is a direct call with 4 people on avg. I'm wrecked today because of 5 consecutive 30min~1h meetings to sync information yesterday.

[dsr_]

It is certainly the case that in most archives, most messages will never be looked at again.

This is the price we pay for not knowing what's going to be important in the future. If we knew that, we could mark the messages immediately and have them pushed into the FAQ or the wiki or whatever.

By obvious corollary, message archives need good full-text searching or else they are useless.

[intrasight]

Our team includes a technician. One of his jobs is to copy important info from email threads to the FAQ wiki. We have a policy to not use one-on-one messages for anything that should be known by the larger team. I preach bus problem avoidance so I am totally on board with that policy.

[doctor_eval]

I agree. The only thing that matters is the change that ultimately gets committed. It’s rare enough to need to go through the commit logs, but optimising for this instead of optimising for getting the job done quickly and well, makes no sense to me. And anything contentious or tricky should be commented in the code itself.

There is a place for everything - PR comments, public slack channels, private DMs, in-person meetings, video calls, 1:1s - even phone calls! - but what’s critical is to use the tool that best gets the job done. And most of the time the job is not “teach everyone all the time”.