Live data from Hacker News

Slack Is Not Where 'Deep Work' Happens

blog.nuclino.com

91–100 of 227 posts

Re: Slack Is Not Where 'Deep Work' Happens

#91
post #86

I'm not a fan of Slack in particular just because it's a closed-source, proprietary, walled-garden. But that aside, while it is true that "Chat / IM apps are not where 'deep work' happens", that doesn't mean that chat / IM isn't valuable. You just have to recognize it for what it is, and figure out how to tap into the value that it represents. If that means turning it all off at certain times to support "deep work" t…

The problem is, people take offense at others turning it off. How do you deal with the social pressure to be instantly available and interruptable at all times?

The problem is, people take offense at others turning it off. How do you deal with the social pressure to be instantly available and interruptable at all times?

Hand them a copy of Deep Work?

Also, don't just turn it off... announce to the group "Hey guys, I'm going offline to do deep work for the next 3 hours. Only interrupt me if the building is on fire, OK?" or something like that. Set a status or "away message" that says "offline for focused deep work right now. Interrupt only for absolute emergencies." or something similar.

Re: Slack Is Not Where 'Deep Work' Happens

#92
post #87
post #49

Earlier quoted context omitted.

I find it has utility in the fact that it's a searchable record of technical conversations I have had with my colleagues where I can go to recover details I might not remember from a month ago. Then again email also does this just fine, and doesn't cost as much.

Email doesn't do this just fine. If a new employee joins your group, how are they going to search your inbox for records of technical discussions that they never were part of?

Put that stuff in a Wiki. Or pull requests.

Re: Slack Is Not Where 'Deep Work' Happens

#93
post #47

Earlier quoted context omitted.

Ugh. I have an anecdote in which I was brought in by a great niche technical contracting firm, as a developer who was also supposed to repair a client relationship, after a previous developer quit. I learned that the problem on client site was not quite what was expected (they already knew the client's manager didn't want contractors). It turned out that a significant part the problem on the ground was simply that th…

So, how did that contracting situation end? Did the manager correct his behaviour?

Most things were improved, and I suspect the remaining things improved over time. Sometime well after I moved on (after talking with the client's manager about what further development work would make them happy before I left, and delivering that), maybe at the end of the year, I got a surprise big check in the mail from the contracting company. There'd never been any talk of bonuses, and I'd declined the "hazard pay" one of the partners had offered when I first identified one of the problems, since I was just doing my job, but surprise money in the mail was nice. :)

Re: Slack Is Not Where 'Deep Work' Happens

#94

For a bit of context for the following, I've been working remote for years, five years in my previous company and one in the current one. The previous company did not use Slack. We used XMPP for one-on-one IMing (we did have chat rooms but nobody used them), physical desk phones for meetings or high-bandwidth chats, and email for everything else. The current company uses Slack and Zoom for meetings. There's a big dif…

I've found that a good way to lower the hassle on starting a zoom is to create a permanently open meeting with your phone number as the meeting ID. Then it is as simple as pasting/typing a link into an IM conversation and clicking it, and if you aren't at your own machine, it's easy to just type it. My only complaint with zoom is the lack of a prompt before launching video. I, and most of my coworkers, have uninstall…

I had the video issue, but I disabled by selecting this option: Settings ~> Video ~> Turn off my video when joining meeting. I can still manually enable video if it's needed.

Re: Slack Is Not Where 'Deep Work' Happens

#95
post #49

Earlier quoted context omitted.

I find it has utility in the fact that it's a searchable record of technical conversations I have had with my colleagues where I can go to recover details I might not remember from a month ago. Then again email also does this just fine, and doesn't cost as much.

there's a hidden danger of using slack as a record of technical conversations: people start to rely on it, and less formal/rigorous specifications fall by the wayside. but as i'm starting to learn: nobody really documents things anyways.

Nobody really documents things because that's not "agile." Agile is do it now, break it later, fix it in the next sprint.

Re: Slack Is Not Where 'Deep Work' Happens

#96
post #22

Earlier quoted context omitted.

My experience exactly. The most common observation with Slack is how people praise it as the next big thing in productivity. But this is always during the honeymoon phase, after a few months of working with Slack it usually quickly wears off.

I think the worst part of it (as the article mentions) is that it feels like you are doing something productive when you're using Slack, but the majority of time you're actually not. You're generating conversations, notifications, and in general producing tangible output that for me is subconsciously gratifying. That hooks me in to using the service even though consciously I know that I'm not getting real work done.

> it feels like you are doing something productive when you're using Slack, but the majority of time you're actually not

That's been my main complaint about GitHub throughout its meteoric rise. Its public contribution graphs and user profiles littered with hundreds of dead forks certainly encourage this behavior.

And I say this not as a person who has an unreasonable disdain for things like business processes and engineering tools (such as bugtrackers); I tend to favor (good) process more than other people—I've had personal projects where I'm the only contributor and user, and yet if you peek into the bugtracker you'll see hundreds of comments from me explaining exactly what's going on wrt the root cause and any fixes, and all known issues at any given time have an appropriate bug on-file.

But when I use GitHub, it's like every interaction ends up getting sidetracked either due to input from users trying to feel productive by leaving comments that are ultimately value-negative, or some weirdo contributor responding to my bug report as if I'm filing a support request and who then tries to "help" me by explaining how I can work around it (I have no problems working around it—in fact, by the time you're hearing from me, that's old news. But this is a bugtracker! For, you know, tracking bugs!), or the peanut gallery using the bugtracker like it's a phpBB forum dedicated to general chatter and expressions of gratitude related to the project (instead of, you know, tracking bugs!).

The worst is when somebody is showing off a project, I take a look, find something like a simple typo, and let the person know, and then they ask me to file a PR. First, I'm probably not even interested in your project even as a leeching user. Secondly, if you can't be bothered to do anything about this thing in your own project that you already understand that that you probably already have opened in your IDE right now, do you really expect me to clone the repo, poke around until I understand the busted directory structure you're using to organize the code, locate the appropriate source file, commit it, and then use GitHub's needlessly convoluted pull request workflow that involves pushing those changes to a third fork and asking you to review them? Do you understand that all this is happening on top of the assumption that I even have a GitHub account in the first place? Why don't you just Alt-Tab over there and help yourself instead of offloading work onto some random stranger who has no vested interest in your project but who decided to spend a little effort typing out a message that would be of interest to the person currently pimping out their project?

... and then every time I mention this, someone comes around, totally misses the point, and leaves an obnoxious comment that "You don't have to clone the repo! You can make minor fixes like that from the GitHub web UI!"

It's like nobody knows how to distinguish between busy work vs things that are actually necessary to the process and/or indicators of real, forward motion.

Re: Slack Is Not Where 'Deep Work' Happens

#97

For a bit of context for the following, I've been working remote for years, five years in my previous company and one in the current one. The previous company did not use Slack. We used XMPP for one-on-one IMing (we did have chat rooms but nobody used them), physical desk phones for meetings or high-bandwidth chats, and email for everything else. The current company uses Slack and Zoom for meetings. There's a big dif…

I've found that a good way to lower the hassle on starting a zoom is to create a permanently open meeting with your phone number as the meeting ID. Then it is as simple as pasting/typing a link into an IM conversation and clicking it, and if you aren't at your own machine, it's easy to just type it. My only complaint with zoom is the lack of a prompt before launching video. I, and most of my coworkers, have uninstall…

That's a good workaround, but Polycoms are still much better than mobiles/computers (a bit obviously, since they're purpose-built for speaking). I'll definitely try your advice now that we use Zoom, though, thank you!

Re: Slack Is Not Where 'Deep Work' Happens

#98
post #87

Earlier quoted context omitted.

Email doesn't do this just fine. If a new employee joins your group, how are they going to search your inbox for records of technical discussions that they never were part of?

Put that stuff in a Wiki. Or pull requests.

So search multiple places instead of just the one?

Re: Slack Is Not Where 'Deep Work' Happens

#99

For a bit of context for the following, I've been working remote for years, five years in my previous company and one in the current one. The previous company did not use Slack. We used XMPP for one-on-one IMing (we did have chat rooms but nobody used them), physical desk phones for meetings or high-bandwidth chats, and email for everything else. The current company uses Slack and Zoom for meetings. There's a big dif…

What stops you from using Slack for one-on-one conversations? I am remote and I would say at least 80% of my time in Slack is spent in conversations with one, maybe two, people.

Re: Slack Is Not Where 'Deep Work' Happens

#100
post #3

“Group chat is like being in an all-day meeting with random participants and no agenda.” That. So true.

Except for the fact that you don't have to be there.

Yeah, and if someone really does need your input on something they'll pull you in for a few minutes. Or many minutes.

But this isn't a bad thing.

Post reply on HN