61–70 of 112 posts
Probably because as part of spinning back up I have to summarize for myself where I think I was, and the summary frequently contains the hint I missed. It’s not quite rubber ducking without the duck, and with more time to help others.
Email is the best method of communication for anything complex. It's asynchronous, long-form, has a historical record, allows threading, you can seamlessly include anyone in the world in the conversation, have shared mailboxes and mailing lists, attach files. But people are afraid of e-mail. Will anyone ever read my e-mail? When will I get a response? What if I mess up my message? It is unknown, immutable, does not p…
In previous teams I've worked hard to make sure slack isn't the place for decisions to be made that are any greater than where to go for lunch. Same with bigger questions as well. Slack is great for small insignificant chatter but developers need long uninterrupted periods of quiet to work. That doesn't go well with an IM system that people expect to get big questions answered or key decisions made with. If the team…
But they want to read a long e-mail thread?
Email is the best method of communication for anything complex. It's asynchronous, long-form, has a historical record, allows threading, you can seamlessly include anyone in the world in the conversation, have shared mailboxes and mailing lists, attach files. But people are afraid of e-mail. Will anyone ever read my e-mail? When will I get a response? What if I mess up my message? It is unknown, immutable, does not p…
I disagree. Email is a terrible medium for collaborative editing/creation of a document (whether source code or human language).
IMO slack is a poor medium for in depth questions and answers. It’s a chat application made for short text. A better tool would be something like an internal stackoverflow…which would have more durability and findability.
Agree 100%, slack is the wrong tool for the job in this case. Your proposal is a cool idea, and there are even self-hostable FOSS clones available. See: https://meta.stackexchange.com/questions/2267/are-there-any-...
Earlier quoted context omitted.
> automatically wiped of messages older than two weeks How do you determine historical truth in a potential conflict scenario, where a manager says "why didn't anybody tell me we'd be running a test at the customer site?" and the engineer says "but I announced it two weeks ago and you even thumbs-upped the post!"?
The same way as 'I've told you that when we ate lunch last week, remember?'. The point is to make sure Slack is treated the same way as a conversation, not as a documentation and project history
Earlier quoted context omitted.
Were their answers wrong, or were the questions completely unnecessary? How do you know it's "not for everyone's benefit"? I don't announce to the world when I consult the documentation. Are you measuring the reach of these answers or is it just a gut feeling? I really fail to see how this is a negative thing. If anything, it's the people not doing it that caused the whole project to fail.
As I recall, largely unnecessary. I can't divine someone's intent, but I can surmise based on having worked with them for multiple years. Measuring reach? certainly not. It was just setup as a confluence plugin by the corpit team and left as a free-for-all with no direction. > I really fail to see how this is a negative thing It discouraged engagement. You can argue until you're blue in the face if it should have or…
A thread isn't that much different from an email chain, reading any of those that have gone off the rails is deplorable. Instead, encourage more concise proposals and rebuttals
Anything too in the finer details can be taken care of elsewhere, then the findings reported back
I wish my team met less often in a structured way. I don't really benefit from giving status updates or hearing theirs.
I'm not some lone wrecking ball, I just have responsibilities for services I designed before joining this team. We also don't really have much overlap. Maybe paired off on something
I feel that our more involved conference call time would be better spent on specific implementation problems or similar - with a smaller audience
Within the team, we use daily stand-ups. Start out with the normal “I did X, working on Y” stuff, try to get that done in 10 minutes (for a team of 6 + manager + occasional BA or tech fellow dropping in). The rest of the 30 min block is open to whatever the team needs - stuff that if left to Slack would end up being a multi-day game of telephone.
Outside the team, Slack is ok for starting conversations, but generally anything important or hard needs a live meeting, even if it’s only for a few minutes. We have a few channels that are exceptions, where the team that “owns” the channel is better than average at making well reasoned responses. But, that’s the exception and those teams are always a pleasure to work with. And this is in a reasonably well functioning mid-sized company. I hate to think what it’s like at a large company.