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