3 ms·

> Being contacted several times per day seems totally reasonable for, I think, the vast majority of jobs in existence. Sure. I do not agree that developers bel

by NhanH 6y ago

> Being contacted several times per day seems totally reasonable for, I think, the vast majority of jobs in existence. Sure. I do not agree that developers belong to the same group with the vast majority of jobs with regards to interruption and synchronous communication though (async slack is fine, if the developer got to decide when to see and reply to the @mention). Being blocked for 3 days is definitely bad (although we do not solve it with Slack), but I do not agree that someone being blocked for an hour is worth the interruption of another developer. I just took on an engineering manager role lately, which gave me more time observing others. And one thing I have noticed is that a couple of junior developers pinging each other every 30 mins to ask a question that they might or might not be able to solve with some more effort just ruin everyone's productivity. It seems like we end up agreeing with each other on both your a) and b) point. So I will just make my point more explicit: too many team culture expects synchronous Slack usage. And I do not know how much Slack encourage that, but it is definitely more synchronous than email, which Slack is supposed to replace

JohnBooty 6y ago
So I will just make my point more explicit: too many team culture expects synchronous Slack usage. And I do not know how much Slack encourage that, but it is definitely more synchronous than email, which Slack is supposed to replace Slack certainly makes gratuitous "drop what you're doing and think about my problem" messaging easier than email. But email makes it easier than sending it by snail mail or carrier pigeon. To say that Slack encourages that kind of thoughtless communication... I can't agree. Those @mentions are not the default. You have to either consciously think, "yeah -- this is worth interrupting my coworker" or fail to consider your coworkers' feelings at all. If developers are being lazy and using their peers as substitutes for Google, that needs fixing at the root level. It's possible they honestly aren't considering their coworkers' feelings. It's worth discussing. I have guided junior devs in the opposite direction before - they have sat there spinning their wheels for too long before getting help. Never had one that erred in the opposite direction! I generally tell them that if they are spending much more than a half hour stuck, to please ask me for help. I've never worked with deadlines so lenient that I can have engineers losing large chunks of days, or entire days. Now, if they were needing help more than a few times per week, I would know there is an issue there. Maybe they just haven't worked with Framework XYZ before and need time to get their bearings. Maybe some pairing is in order, or they could take a class. Maybe they were a bad hire. Maybe they are inconsiderate. Maybe the thing they're doing is just too advanced for where they're at, experience-wise. Maybe they need me to suggest that they could batch up their questions and we can some time together going over them a each morning at a regular time. Whatever the reason, I would like to stay on top of it. This conversation has made me think, though, that a Slack plugin that limits team members to a finite amount of @mentions per ___ days might be a fun experiment, though. :-)

by NhanH 6y ago

JohnBooty 6y ago

So I will just make my point more explicit: too many team culture expects synchronous Slack usage. And I do not know how much Slack encourage that, but it is definitely more synchronous than email, which Slack is supposed to replace Slack certainly makes gratuitous "drop what you're doing and think about my problem" messaging easier than email. But email makes it easier than sending it by snail mail or carrier pigeon. To say that Slack encourages that kind of thoughtless communication... I can't agree. Those @mentions are not the default. You have to either consciously think, "yeah -- this is worth interrupting my coworker" or fail to consider your coworkers' feelings at all. If developers are being lazy and using their peers as substitutes for Google, that needs fixing at the root level. It's possible they honestly aren't considering their coworkers' feelings. It's worth discussing. I have guided junior devs in the opposite direction before - they have sat there spinning their wheels for too long before getting help. Never had one that erred in the opposite direction! I generally tell them that if they are spending much more than a half hour stuck, to please ask me for help. I've never worked with deadlines so lenient that I can have engineers losing large chunks of days, or entire days. Now, if they were needing help more than a few times per week, I would know there is an issue there. Maybe they just haven't worked with Framework XYZ before and need time to get their bearings. Maybe some pairing is in order, or they could take a class. Maybe they were a bad hire. Maybe they are inconsiderate. Maybe the thing they're doing is just too advanced for where they're at, experience-wise. Maybe they need me to suggest that they could batch up their questions and we can some time together going over them a each morning at a regular time. Whatever the reason, I would like to stay on top of it. This conversation has made me think, though, that a Slack plugin that limits team members to a finite amount of @mentions per ___ days might be a fun experiment, though. :-)