Hacker News new | ask | show | jobs
by zibby8 1375 days ago
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"
1 comments

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

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

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