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…
Slack Is Not Where 'Deep Work' Happens
171–180 of 227 posts
Re: Slack Is Not Where 'Deep Work' Happens
#172Reminds 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
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
#173Earlier 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…
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
#174Deep 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…
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
#175Earlier 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.
Re: Slack Is Not Where 'Deep Work' Happens
#176Earlier 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…
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
#177Earlier 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.
Re: Slack Is Not Where 'Deep Work' Happens
#178Earlier 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?
Re: Slack Is Not Where 'Deep Work' Happens
#179Earlier 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.
Re: Slack Is Not Where 'Deep Work' Happens
#180Earlier 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.
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.