|
|
|
|
|
by ThePadawan
1380 days ago
|
|
> 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. |
|
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.