Live data from Hacker News

Slack Is Not Where 'Deep Work' Happens

blog.nuclino.com

171–180 of 227 posts

Re: Slack Is Not Where 'Deep Work' Happens

#171

Earlier quoted context omitted.

Put that stuff in a Wiki. Or pull requests.

By "that stuff", do you mean "technical communications you have had with colleagues", such as what Slack or email might otherwise be used for? That is what the GP was referring to. It's hard to imagine using a wiki for that, but if that's how you do things I guess it's fine. As long as it doesn't rely on people copying their email discussions to wikis manually. Not sure how you'd be alerted by an important wiki updat…

Let's use a concrete example. A new engineer joins your company and needs to set up a dev environment. This environment has changed many times over the years. Do you point them to Slack, Email, a Wiki, or a shared Google doc? In any sane company, it is one of the latter.

Re: Slack Is Not Where 'Deep Work' Happens

#172
post #17

Reminds me of this Knuth quote, "Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things." Source: https://www-cs-faculty.stanford.edu/~knuth/email.html

First job I got out of school was with a large DoD contractor. You have very likely heard of them. I was in the enhanced engineering department, up there with the rest of the smarties, not really knowing what they saw in me.

There was one guy, Bill, who was an 'engineer emeritus' and an old Cold Warrior. The guy, no joke, was a genius. He was the only person in The West that knew about ablative nose-cone chemistry for ICBMs and the like. He's tell us junior engineers great stories. There was the one period of time where he'd get briefcases filled with empty steel bottles and was asked to analyze what was in them. No telling where they were from or if any of the stuff was radioactive or anything.

He taught me a great lesson in engineering management. He technically had an email address, but it just auto responded that he never checked it, call him [0] or walk on over for a chat. I remember thinking: "What a proud, old, stupid man. How regressive!". How dare he say these things! You have to respond to emails.

Well, just that little bit of friction was enough to stop all the nonsense in his product group. Just the act of having to dial in the numbers and wait, just the act of having to get up out of the seat and then go actually talk to Bill, it was enough to have most people sit and think about what they were going to ask him. Most of the time, they really didn't need to say anything at him. If it was actually important, then yes, you'd get up and talk to him or give him the files he needed or whatever.

When it came to our DoD work, friction ended up being a good thing actually. It made you think just a half-step more about what you were doing, if it really was anything.

[0] The phone number was for the bar down the street, where Bill spent many of his days. Honest to God. You'd call, a barback would answer, and then he'd yell at Bill to amble over and take the phone.

Re: Slack Is Not Where 'Deep Work' Happens

#173

Earlier quoted context omitted.

I agree Slack can be used effectively, but I don’t think its design encourages it. It encourages massive distraction — more active user time — by its default client and organization level settings. Nor do I think this is as simple as “you can simply exit the program.” If the company or team has certain expectations on communication that won’t work if you do it without consulting with your team. A lot of people are no…

Whether or not Slack encourages workflows (and I can see how it would), I think in order to be an effective human in the modern era _requires_ thinking critically about technology choices and how to use them. Cal Newport's new book Digital Minimalism was a great read about this - be intentional about your tech choices, and be intentional about when and how you use them. Otherwise it's super easy to just get sucked in…

I completely agree, but I don't think that means we should ignore or withhold criticism when a company like Slack has immense power over how other companies operate. We should be scrutinizing the decisions they make because it does affect us.

Many of these decisions you refer to are not made by the individual employee, but by the team lead, PM, or the executives, who are not always very connected to how those decisions affect developer happiness. So getting control of your personal digital life often has no bearing once you enter the workplace with an entirely different set of expectations.

Slack being a public company worries me even more, because there is now an even greater drive for them to make ever-increasing revenue/profits, which usually means keeping people on Slack and active within the client and increasing daily active user / engagement metrics. In many ways there isn't great alignment between a company being productive and Slack's financials; Slack is incentivized to boost revenue even more now, likely at the expense of end-user productivity.

Re: Slack Is Not Where 'Deep Work' Happens

#174

Deep work? We live in a world of open offices, daily standups, max-four-hour JIRA tickets and pair/mob programming. The people in charge don't believe that "deep work" even means anything.

This is true, but most if not all of these tasks don't require Deep Work. Cal Newport is an academic. It takes a lot of thought and a distraction free environment to write papers about CS Theory. Most people in these environments usually know how to write software. Most of the software written isn't too complicated and doesn't require Deep Work. The design of these systems requires more thought, but the implementatio…

> Most of the software written isn't too complicated and doesn't require Deep Work

There's a self-fulfilling prophecy for you. We assume a priori that developing software doesn't require much thought, so we'll skimp on environmental factors that contribute to actual thought and see what programming we can get out of it. And lo and behold, if you ignore the usability problems, security problems, out-of-control memory problems and the necessity of an army of testers to make up for the fact that nobody actually understands the code, the resulting software kind-of sort-of meets the requirements so we were right, software CAN be reliably produced with zero concentration in an all-interruptions, all-the-time environment!

Re: Slack Is Not Where 'Deep Work' Happens

#175

Earlier quoted context omitted.

I agree Slack can be used effectively, but I don’t think its design encourages it. It encourages massive distraction — more active user time — by its default client and organization level settings. Nor do I think this is as simple as “you can simply exit the program.” If the company or team has certain expectations on communication that won’t work if you do it without consulting with your team. A lot of people are no…

If your company wants you to sit on Slack all day and not do "deep work" the that's on then, and if it's a waste of your time then it will be their wasted money. So the companies are just as invested in this as employees are.

You also need to make sure you're doing the right "deep work". Sometimes, the problem was already solved by someone else, and there Slack can mean the difference between discovering that in a few minutes vs. a few days.

Re: Slack Is Not Where 'Deep Work' Happens

#176
post #62

Earlier quoted context omitted.

Agreed. Its not just about the tool but how you use it. For us it actually helps to get less distracted. There are very few things that require a sub 3 hour reaction. So we just put a question in Slack even if it's for the person sitting right next to you. Eventually the person will answer when they have some time. Much better than constantly having someone tipping one your shoulder or calling you Just because you ha…

> If a person can't work because of a pending question, it usually means they don't have their work organised sufficiently. This is an overly harsh assumption. There are plenty of compelling real-world examples of organized, effective people being blocked by some small but urgent thing that's not their fault and requires a few minutes of attention from someone else. If a dev just started on my project but the DB cred…

True, I'm a bit harsh on this, but I also used the word usually instead of always on purpose. Yes, sometimes someone can really get blocked and not able to work, no problem to ask for help in this case. On the other hand I have seen it enough times that people (especially juniors and bosses) continuously ask question without having bothered to think about it prior. Forcing them to deal with a problem by themselves for a bit and not distract others has resolved many of them.

The key thing is being clear what communication and team culture you want to establish. I'm not just a grumpy guy that ignores messages or avoid helping others. It is something that has been discussed and agreed upon in the company and is expected to be respected by anyone no matter where the person is in the hierarchy.

Re: Slack Is Not Where 'Deep Work' Happens

#177
post #151
post #118

Earlier quoted context omitted.

Slack can be a terrible tool if you let it, but it can be wonderful, too, if you tune your notifications, and use DnD when you need it. Also, schedule DnD for non-work hours so you are never bothered outside of work hours, unless there is a true emergency (and if you work at a place with a lot of emergencies, then you have a shitty workplace). It's a tool. Use the tool, don't let the tool use you.

Slack is hostile to users and panders to management. It's a sound business strategy. I can't trust the platform, I'll always be second class. What about scheduled DnD for days off? Ability to /ignore annoying bots? Two basic features which should've been added long ago.

Those features plus the ability to ignore @here from only certain users would make a huge difference.

Re: Slack Is Not Where 'Deep Work' Happens

#178
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?

Email lists and newsgroups have been around for a very long time, and are often archived. My organization still runs a listerv for this very purpose.

Re: Slack Is Not Where 'Deep Work' Happens

#179

Earlier quoted context omitted.

I agree Slack can be used effectively, but I don’t think its design encourages it. It encourages massive distraction — more active user time — by its default client and organization level settings. Nor do I think this is as simple as “you can simply exit the program.” If the company or team has certain expectations on communication that won’t work if you do it without consulting with your team. A lot of people are no…

If your company wants you to sit on Slack all day and not do "deep work" the that's on then, and if it's a waste of your time then it will be their wasted money. So the companies are just as invested in this as employees are.

It not an even trade. 'The company' is merely wasting (often someone else's) money. You on the other hand are wasting your own life-time.

Re: Slack Is Not Where 'Deep Work' Happens

#180
post #43

Earlier quoted context omitted.

> Slack is asynchronous. You are describing a proprietary, expensive, intrusive, demanding rewrite of SMTP.

I very much like Zulip, it's open source and much closer to email, even culturally. It encourages long-form replies and messages with subjects, so it requires at least a tiny amount of thought before you start talking to someone. I think it's a great cross between Slack and email.

Just looked at it.

What keeps Zulip threads from exploding in practice? Either on the UI or usage side?

E.g. How to I keep from going from "One channel with a hundred unread messages" to "One channel with twenty unread threads"?

Also, what features exist when a thread diverges from the original topic?

E.g. We were talking about the "afternoon lunch" at the "annual meeting", and then someone mentioned their favorite restaurants in the area, and now people are replying to both?

Organization seems more like a usage problem than a technology problem. Or at least one that I can't see manual categorization solving.

Post reply on HN