Hacker News Reader

Comment by liquidise | Hacker News Reader

I don't mean to hijack the focus from email specifically, but i find slack suffers from the same, if not worse, issue. Without exception, the most productive days i have had since my team adopted slack are the days when i forget to open it in the mornings, and achieve hours of uninterrupted work.

All of these conversations, be it open-office/email/slack/etc are a rehashing of something we all know: fewer distractions leads to increased productivity. The trick is to balance that with collaboration and help channels, so the product and collective productivity of a team is improved, not just an individual's.

View on HN

I work remotely from the rest of my team, and only started a few months ago. Often, I have quick questions or clarifications that I can't ask about in person, and need to ask over Slack. Sometimes I don't get responses for hours (meetings, busy, etc), which blocks me on my tasks for the rest of the day. I would be immensely less productive without reasonable latency back-and-forth.

I get needing time without distractions - but when your work is used / others are dependent on it, how do you tradeoff that support?

So I think it is necessary to differentiate between "deep work" jobs (See Cal Newport's blog/books...) and "interrupt driven" jobs. Engineering design generally is a "deep work" job. Long periods of uninterrupted concentration are key to productivity.

Other jobs, like receptionist and office managers, for instance, are interrupt-driven. Receptionists add value by responding quickly and handling a continuous stream requests.

Now let's talk about engineering managers. Being an engineering manager is IMHO, an interrupt-driven job. The job of an engineering manager is to tell you where to find answers to your questions, or on a good day, actually answer the question. The friction comes when an engineering manager does not understand that the interrupt-driven nature of his/her job is not reciprocal. A good manager will handle interrupts quickly, but only very judiciously use the power to interrupt.

Another source of confusion is dev/ops. Anything operational will tend to be interrupt driven. An engineering manager that has been running a high-functioning dev/ops team that is a team of crack fire-fighters might be a very disruptive force in a design engineering team if that manager expects a constant volley of chat messages among the team.

It's perhaps more accurate to say there are 'deep work' tasks, and there are 'interrupt driven' tasks, and any job is a combination of both, in various ratios. Often you can't even tell ahead of time whether a given job is going to be mostly one or the other.

Maybe what we need is a system where instant messages are allowed, but it imposes a cost of some kind to the person initiating it, so that it won't be used frivolously. Like the proof-of-work antispam captchas, except it should take ~30 seconds and be just once per conversation (defined as ending when 5 minutes go by without message; first replies are free).

We could also add a social cost by displaying how often each user has used this feature in the past 24 hours, next to their username.

This is a great point. It's really important to recognize the nature of different tasks and to build different habits around them.

As a startup founder, by far my two biggest tasks are customer acquisition and development. The former is interrupt-driven while the latter is emphatically deep work.

Right now, I try to address this by blocking off 4 hours a day for deep work and the rest of the time is available for sales and general operations. It's working okay but the big problem is that I have an added stress of worrying what important customer messages I might be missing during my deep work time.

How about just a phone call (or two, to break through “do not disturb”), or tapping on their shoulder to get their attention? That's what we do when we really need someone right now rather than when they come back up for air in the next hour or two.

That, plus simply being mindful of the meaning of “deep work” and people working in roles that need that kind of concentration.

I don't need an app for this.

If you set Slack to do-not-disturb, people sending a direct message to you will be warned that you won't be notified and might not see it -- but will be given an option to "punch through" the do-not-disturb setting for important, interruption-worthy messages. That seems to largely achieve what you describe.

> It's perhaps more accurate to say there are 'deep work' tasks, and there are 'interrupt driven' tasks, and any job is a combination of both, in various ratios. Often you can't even tell ahead of time whether a given job is going to be mostly one or the other.

A reasonable model.

> Maybe what we need is...

I think Cal Newport belongs to the "intermittent hermit" school of thought...

I think you've hit on something. I like my days to be deep work driven as that's where I feel productivity and satisfaction. But, as my role has expanded I actually need to be interrupt driven. When you're stuck in a cross over period, trying to do deep work while holding the team back due to delays in responses, it gets frustrating.

Thank you for helping me understand this dynamic.

This doesn't seem to be the answer for a scrum team. Often you have questions for other engineers, on your team. A product owner is also not interrupt driven and is hopefully digesting stories or talking to stakeholders.

If engineering/qa/architecture is the question, xp may help.

Everyone, please stop starting your statements with "so."

If your bosses aren't planning to lay everyone off in a month, there has got to be something slightly-lower priority to be working on. Unless you're on the critical path, spending half a day blocked on your primary task and focusing on a secondary priority is no big deal (or, at least, shouldn't be). If you are on the critical path, scoop up that phone and start dialing.

Since you're new there, you might not have the assignments and/or enough responsibility to know what else needs to be done. But that should happen soon, and there is no reason not to proactively talk to your boss about secondary goals to focus on when you're blocked waiting on communication.

I think it's just good management to convey the bigger picture to everyone. Between the steady stream of tickets assigned to me and other existing responsibility I haven't had to ask my boss "what do I work on now?" in... like... 3 or 4 years.

Sorry, meant to imply I was blocked on that specific task, which is often the highest priority one, rather than on all tasks. Unfortunately, the highest priority ones are often the most difficult and trickiest, requiring occasional questions when I run into things other have had experience in. Is the loss in time spent on high priority items worth fewer quick distractions to the rest of the team?

Oh, OK. I get where you're coming from now.

Is the loss in time spent on high priority items worth fewer quick distractions to the rest of the team?

It all depends on the tasks and your particular work environment. It's going to vary from place to place, so I don't have anything specific to tell you other than this kind of prioritization is the kind of conversation you should be comfortable having with your lead. Or at a status meeting or standup, if your process makes that the better place to ask.

I work at an agency where there is a steady stream of tickets. We are very concious of the cost of task switching. In the case where you are blocked on a task and it is left unfinished in favor of a new task of lower priority, when you finally get an answer on the first task you often have to dro the second task abruptly. So you have two unfinished tasks and all the mind balls you were juggling are dropped on the floor.

However we are also an almost entirely engineering team so there is no resource for getting unblocked that isn't bugging another developer who then drops his mind balls.

It is just the reality of it though, we have tickets and tasks to complete and we can work toward being more efficient, making sure we aren't going to get blocked befor getting started on a ticket and such. It's all a balancing act and it's important to be aware of it, but I no longer get my knickers in a knot over it.

Doesn't Slack have a similar system to IRC, where you can specifically send a notification to someone by prefixing with their handle?

I've worked remotely for many years and this was never a problem. Need some company? Just read and follow a few channels. Want to get work done? Ignore client and code. If someone needs me, a notification + sound will pop up. Works fine with IRC, really.

That sounds a bit strange because there's always something else you could be doing while waiting for that answer? Either working on another issue, or trying to improve something without being asked to, or even just learning something that could (or not) be helpful sometime in the future. Worst case scenario: read some HN :-)

But really: doesn't working remotely mean that, when blocked, you can just leave the computer and do some life stuff, then come back a few hours later and continue from there?

Sure, I can always do something else instead, but that context switching is costly for me as well, when a minute-long conversation, though briefly distracting for a colleague, would have been able to keep me working at the task at hand.

How is context switching costly for you, but only briefly distracting for your colleague?

To me it's the difference between a few line exchange that is briefly distracting vs switching to working on a completely different task, getting up to speed on it just in time to have to switch back and refamiliarize myself with where I left off. Order of minutes vs hours.

In my experience the questions tend to cluster towards a small group of individuals; so from their perspective, you're the 5th interruption in line for the day and they've barely been able to start their own work.

That's one reason why I like the idea of taking forced breaks; they give you a scheduled time to handle brief interruptions, and if you're fairly regular people can tune in to your schedule(e.g. if you're always "working" the first 50 mins of an hour and "resting" the last 10 mins, it's easy to know whether you'd be able to quickly answer a question). Of course, the forced breaks are another form of an interruption from flow; it's still a trade-off.

Sorry for the late reply, but "briefly distracting" tells me it's clear you don't understand "the zone".

>>But really: doesn't working remotely mean that, when blocked, you can just leave the computer and do some life stuff, then come back a few hours later and continue from there?

Technically yes. In practice though, this only blurs the boundaries between work and leisure, as you find yourself working in evenings and weekends to make up for those down-times during the week when your team members were unreachable.

Excuse me, but if not getting in touch with your colleagues blocks you for the whole day then you probably have the bigger problems than just not getting your questions answered on time:

1. Maybe documentation is scarce, be it code comments or business requirements specs, user stories, epics, etc.

2. Maybe your tasks are ill defined, and you accepted your assignments without asking enough questions upfront...

3. Maybe you don't get enough workload (if you had many tasks to choose from it would be harder to get blocked on all of them)

4. maybe you lack some technical knowledge or other competencies needed to make the decisions yourself instead of asking others.

That is rubbish. Many reasonably complex projects require a reasonable amount of communication. This list sounds like you have only worked on 1 man toy projects.

Communication, yes. But synchronous, blocking communication?

You have an organizational problem there.

Again, I disagree.

Any reasonably complex codebase I have worked in has at least parts that only a few people understood. Even if n=3, you could still very easily be blocked when trying to find someone in the know...

Right, so an organizational and architectural problem. It's even got a specific term: Bus factor.

https://en.wikipedia.org/wiki/Bus_factor

You have a problem. Disagreeing with me won't fix it. It's a common problem, but also a fixable one.

You're right that these are problems, but how long does it take to solve them?

1) Do you know of a way to document a significantly-sized application in such a way that it is not massively more efficient to ask a colleague for help than to go source-diving? Say we are talking about a rails app that has been maintained for 5 years and with a reasonably complete test suite.

2) Does a fresh-from-uni or perhaps 2-years-out-of-uni junior developer teach themselves how to ask just enough questions up-front that they don't need to ask more to unblock themselves?

4) How does one gain this technical knowledge if you are on a project and need to apply it but don't yet have it yourself?

Well put, thank you.

Re 2: Often tasks are even meant to be exploratory, where those questions can't be asked upon receiving the task, but only once enough investigation has been done and implementation questions are run into. Rather than a quick back and forth that keeps me progressing, I have to context-switch to something else, and spend time re-familiarizing myself with what I had done the day(s) before again.

    Do you know of a way to document a significantly-sized application in such a 
    way that it is not massively more efficient to ask a colleague for help than 
    to go source-diving? Say we are talking about a rails app that has been 
    maintained for 5 years and with a reasonably complete test suite.

Yes. You can draw architectural diagrams. You can create a wiki where people document problems and solutions. You can have broader design reviews where people talk about the ways in which they solved various problems and what considerations they took into account when coming up with those solutions. I agree with the other posters in this thread: if you're truly blocked (i.e. literally unable to work) because someone can't respond to your question, there is something deeply wrong with your codebase, or in the way in which your team communicates. Personally, I would expect anyone who's been on the team for more than few months to be largely self-sufficient when it comes to actually coding. Of course, there will be questions when there are multiple possible approaches to solve a given problem, and I would expect someone to raise a flag and ask about the relevant considerations. But in the absence of a reply, you should be able to pick an approach and push forward with it.

    Does a fresh-from-uni or perhaps 2-years-out-of-uni junior developer teach 
    themselves how to ask just enough questions up-front that they don't need to 
    ask more to unblock themselves?

Honestly, at some point, you have to learn your team's codebase. You say that it's massively more efficient for you to ask questions of colleagues than it is to go source diving. That, to me, indicates that you don't actually know your codebase very well. Again, this is a sign of a problem on the team. Either the source is so tangled that no one can hope to understand all of it, or people are becoming siloed - specializing in particular areas of the codebase in ways that leaves them unable to fix problems in other areas. It's all right to be better at one part of the code than another. For example, I'm better at some of the middle-tier/business-logic code than I am at UI work. But, in a pinch, I can jump in and help with UI if it's necessary.

    How does one gain this technical knowledge if you are on a project and need 
    to apply it but don't yet have it yourself?

I'll be honest. It's rough. You have to learn, and you have to realize that outside of university there aren't going to be TAs and professors to point you in the right direction. You will make mistakes. But that's the only way forward. Keep trying. Keep writing code. If you do something and it doesn't work, have a meeting in which you go over what you did, why it didn't work, and what you could have done better.

1, 4. Yes, documentation is absolutely scarce - given that culture, such back and forth is often required. Some configurations or details of a complex (and often legacy) system are opaque, and used infrequently enough that teamwide training on it isn't appropriate.

2. Yes, often my tasks are exploratory rather than implementation of a particular feature. Often the goal is to explore and then discuss my findings. When I can't just go up to someone's desk in person and ask them when they are free to discuss, Slack is a good resource to set up a meeting.

3. I definitely am not blocked on all, but the context switching hurts my productivity as well - to me, a quick response would have large benefits for me and a minimal distraction for my colleague.

Questions should be on slack.... answers should be on the wiki...

Then check the wiki before you ask a question. Query driven documentation.

I just write together what I need to know and combine into a single email or phone call.

Do you ever find that this approach leads to a subset of your questions being answered? I've found that asking n questions in a row frequently leads to only the nth question being answered (which I presume is often due to content being pushed "below the fold" on mobile devices).

Yes of course, because people are often busy or too lazy to think the answer through.

But that doesn't matter, I can work with the subset.

Sometimes the questions resolve themselves, sometimes I just write another email, it really depends.

You can't pick up the phone?

I wish I could put slack in a "burst-mode" Where it would only show new messages every N minutes. Ideally, I would have the self-discipline to only check it that often. In reality, if I was going to find a way to develop that self-discipline, I would have done so at some point in the past 10 years of searching. Code is much easier than applied psychology.

Suggestions welcome.

It is Cmd+Q for me. Tongue in cheek here, but you have the power. You have permission from me, bitexploder to close Slack and work for focused periods of 1-2 hours. Seriously though, it may be a little uncomfortable. If it seems to cause friction with colleagues just explain it. Ensure you block out time to be responsive, respond, and help others out. Slack should be a "help if I can" avenue not demand of your attention. I call it digest mode. Open once every hour or two when I am thinking hard. Email the same. Some mornings I let everyone know I am heads down and will come up for air and help out with things in the afternoon.

Our addiction to instant and easy answers can be very problematic. It is the only way. Some of the time when I feel the urge for distractions or chat or email I just sit with one or two apps open (Editor and music) and I sit there until the boredom wins and the task becomes more appealing. Once that hurdle is overcome things are great.

> Our addiction to instant and easy answers can be very problematic.

Bingo. The rub between not wanting to reinvent the wheel and being forced to think through it on your own is a very real tension. However, I really like what you say here. The notion of instant information and instant gratification has made us primarily information consumers. There's a very real benefit, in my opinion, to thinking through the situation without the external information inputs.

Both are good, but my sense (from anecdotal evidence, primarily) is that we're losing the thinking/reasoning our way through things in favor of "collaboration" which we cheapen as "information sharing."

I have spent some long weekends in the woods trying to be very still. Not meditatong really, just being bored and thinking. I think it helps me be okay being stuck for a while. Cal Newport discusses this in his book. Getting comfortable with boredom and short Internet embargos (among other things)

When I am hacking on Go or Python I will often launch pydoc or godoc and not visit the Internet at large for hours. Some times I end up implemeting something un-idiomatic or sub optimal. I think it is alright. You get a feel for when something should go to a Parking Lot that you can clear out in a bit. It may seem counterintuitive but it does not mess up Flow. Just whack a comment or placeholder and move on. I often find my brain was working on it in the background anyhow.

It is a sort of freedom. A rare sort these days.

This solution works less well when there are actual emergencies.

You can, however, configure slack to not notify you unless you are @'d specifically. This + minimizing slack is pretty effective. Most of our office works with this set up (so some people need to be pinged directly to get immediate responses)

People might need to know, but I think that the word spreads fast. For non-urgent stuff, talk in the channel. For urgent things, @ someone, or DM them.

The only thing you need then is the self control to not look at Slack every 30 seconds.

Slack is one of those sneaky things that can subvert culture or quasi-define it if a stronger force does not exert itself. We make it a policy that emergencies happen via telephone. We want people to be able to ignore Slack for a while and not be worried about something important popping up.

It can be hard when that is not an option because then someone has to let Slack occupy some amount of their brain space, just in case.

That would work for others, but my problem isn't external, it is internal. I would just re-open slack.

Why quit the app vs set your status to busy/DND?

I am lazy and I like for it to be 100% out of my mind. No seeing it on cmd+tab, etc. No temptation to stop by Slack as I change apps.

spotlight and a fast machine make it a few keystrokes to come back.

But given those issues, it seems the only reasonable approach is to practice the needed discipline to not do so. It can be difficult and uncomfortable, but possible for most people.

I think we agree in spirit. My argument is more about something like decision fatigue. There is simply a mental cost to even glancing at a distracting thing that you have struggled with. When you are first building a discipline you lack, even the smallest factors like that can overwhelm you, especially if your bucket of decision making power is all used up later in the day.

I have been on this agenda of simplifying my computing over the last couple of years and it has really made a difference. I don't need a special app for TODOs. I don't need yet another status bar agent pestering me to update itself. I don't need an IM client begging for my attention. We are builders and problem solvers, and we are paid to think really hard. Our computers and phones are devices that have a default mode that guides us toward content consumption and a bunch of "least bad" technologies.

If you implement a setup where your email reader is decoupled from the program that fetches emails, this is trivial to do.

Personally, I use mutt + mbsync. I have bound key 0 to call mbsync from mutt. I try to check email only twice per day [1].

I'm in the process of switching to gnus + mbsync. This has the additional advantage of gnus being close to a news reader, which is optimized for an inbox-zero way of reading.

Since my email often carries stressful news, I love having my inbox "paused". I pull emails. They are not pushed to me. Way saner.

[1] http://pmarchive.com/guide_to_personal_productivity.html

Could you maybe write a devtools extension which puts the page into offline mode for n minutes every n+1 minutes?

Could not agree more. Ive disabled Slack notifications on my phone entirely (and much prefer email over Slack; Slack creates an unnecessary sense of urgency).

Unless the shop is burning down, nothing needs my attention immediately. If it does, call my cell. Some things deserve purposeful friction.

I find Slack less distracting than email, simply because I spend far more time thinking about how to phrase my replies over email, while Slack is more conversational. That said, I've started limiting how often I check either, and have found that it helps with my workplace stress levels, as well as productivity.

In the old days, we had intranets, knowledge bases, wikis and we tried manfully but unsuccessfully to somehow get people to document the good shit so others could use it for reference material.

Seems we've now given up on that and the new working model is just to blurt out questions in some push system, bugging everyone in the process, and then hope that someone blurts back an answer.

I wish that I could install a version of Quora on my company's local network which would preserve that Q & A knowledge and make it more searchable.

Tangent: It has been 7 years since their founding. How does Quora make money?

Its surprising no-one's working on that, given Yammer is basically a SaaS Facebook.

Or maybe they are, but they can't be found. I've noticed this before, but you can't google for something like "SaaS version of Quora" because all you'll get is results - in Quora - about SaaS. Same for "in-house Quora". So maybe someone does offer a Quora-like product for the enterprise, but they're consigned to invisibility.

Askbot exists[1] -- its look-and-feel is more akin to StackOverflow than Quora, but it's pretty widely deployed[2][3]

[1]: https://askbot.com/ [2]: https://ask.fedoraproject.org/ [3]: https://ask.libreoffice.org/

The blurting has no bounds. I recently had someone tell me over slack that the company is contemplating a spin-off, blurting out a few lines describing the strategy, and asked if I could get back to them on possible system implementations / integrations / ideas. There were blurts along the lines of, 'and if we can't find a saas offering to integrate with, we might have to build our own, but maybe we should make it generic because there could be a market for it.....'. I was basically thinking, 'how about you fucking idiots carefully document a well considered, serious proposal, and then ask my advice. Or invite me to a brain-storming session, in person, so we have an actual discussion.'

'Blurt' seems like a good name for a chat system...

I mean, one of these unified communication/Facebook-clone thing-a-majiggers is called Yammer...

https://www.merriam-webster.com/dictionary/yammer

yeah but in slack you 'pin' that blurt to the channel and can accumulate useful blurts

Except searchability of pinned stuff is terrible and often the only way to see the entire message requires clicking on it which "scrolls" up that point in history, incurring the CPU, memory, and network load of getting everything in-between. This is horrifying when you're remote working from a country with somewhat dodgy Internet connectivity. IRC takes almost no bandwidth and an IRC client takes minimal system resources, Slack by comparison is a hog.

Documentation in a Wiki is way preferable.

What's your role in the team? How are you using slack?

If you're a team lead, or someone with significant business or technical knowledge, helping other people on slack might increase their productivity, and the productivity of the team. That may be more important than your own productivity, or it may even be your responsibility. In this case, not being available is unfair to your team.

I use the slack app which displays a notification icon in the task bar. When I get personal messages (which usually require immediate attention) the icon shows a red dot (I also get a notification). If people chat in public rooms the icon shows a blue dot (and I don't get a notification). I don't check slack, I just glance at color of the dot. Interrupts are pretty rare, and I'm always available if someone needs me. I'm not, however, a central member of the team, so people don't often come to me for technical or business advice. If I were, however, I wouldn't shut down their line of communication because "screw you, I need to work".

I think Slack feels good if you're the one managing the team. But if you're the one actually slogging away at building the thing, it's incredibly frustrating and makes it impossible to get into flow.

I thoroughly recommend Cal Newport's book "Deep Work" if you want to understand the drivers of this effect, and help make constructive arguments in favour of a less connected workplace.

(replied to the top thread, but it's applicable to everyone in this sub-threaD)

I completely agree. My experience was it started out well, and then the number of channels proliferates within an organization and before you know it you have 15 conversations going on in 15 different channels because creating channels is cheap and then you have direct person to person messages on top of that. It exponentiates pretty quickly. There seems to a real time expectation to Slack . Conversely I check email once an hour maybe.

> Without exception, the most productive days i have had since my team adopted slack are the days when i forget to open it in the mornings, and achieve hours of uninterrupted work.

"Productive" in what sense? In my experience that's a good way to spend hours writing some gnarly logic that will feel very satisfying to write... but not actually be what the user wanted.

You don't need continuous feedback every minute (or even every day). If you know what you're doing and get in a thrall, 'closed door' days can be amazing.

If I knew what I was doing I wouldn't be working for a company at all. I have the programming expertise but I don't have the business expertise. And I find the more granular back-and-forth I can have with someone who does, the better the end result.

It depends on what your role is. I'm a marketing analyst, and 80% of the communication I have is people checking up on their favorite project. I used to be the last cube at the end of a dead-end office, and my new cube is basically right be the door in a hallway-ish office. I'm half as productive because of all the people dropping in to ask me questions.

I think all the communication options we have make people anxious if we aren't communicating. It's like cell phones. People lose their minds if their phone breaks and people can't contact them immediately, but people survived for tens of thousands of years without that ability.

Well for tens of thousands of years people lived in close-knit communities where they could communicate with all their friends every day by talking to them. To recover that while being able to live in a city and choose our friends and gain all the advantages that come with that, we need other means of communication.

My phone's in for repair at the moment, so I'm very conscious of how much difference it makes to my life. Waiting is a lot more boring without it. I've had some good times that I wouldn't have been able to without modern communications (last-minute parties that I'd've missed if I hadn't been so easy to contact). And fundamentally I like talking to my friends (interestingly this is something that has changed as I've got older - when I was 20 or so I was much more content spending days at a time on my own).

I would certainly advise pruning any communication sources that don't bring you joy, KonMari-style. But don't throw the baby out with the bathwater.

I don't think moving to cities is the issue here. I think the ease in contacting far-flung friends is a bigger issue. People don't seek new friends when they can stay in contact with everyone they've ever met.

It's not just an issue for cities. One of my best friends is a high school teacher, and she said that kids told her they felt less lonely after a cell phone ban came in to effect. Before the ban kids would text their friends who weren't there if they didn't know anybody. After the ban they started making new friends at lunch, since they wouldn't choose a convenient spot and stare at their phone the entire time.

It's not like the city is a new construct.

I'm willing to trust people to be able to make their own choices. Some people find it easier to make friends than others; some of us can't always rely on strangers to even tolerate us, for various reasons. I'm a lot happier with communications technology than without it, and I wouldn't rob people of the ability to make a choice even if many of them choose wrong.

And I'm a consultant, give a silo of work to do and needing only occasional updates (couple times a week).

Have you tried playing around with the notification settings, or simply turning notifications off? I find Slack to be distracting in certain channels, or groups that you may join, but there are many ways to manage it to optimize for productivity.

The problem is that it creates a certain expectation of instant response if you are directly contacted.

I think it's the same for slack as it is for email: simply turn off notifications.

I'm finding the Pomodoro timer in Gnome really helpful on this front fwiw. YMMV

I try to use it when convenient such as sharing URLs or files, but we have an open office setup at my job, so it's easier to just talk to one another.

good points. and to expand on that I'd say a good percentage of HN posts/comments are a case of "newbs/young rediscovering/reinventing what us older folks figured out long ago, ad nauseum."

The older I get I have to sigh and skip over more and more of what's on HN.

I ban Slack through my hosts file at work. If someone wants to interrupt me, they have to get off their ass and come do so in person.

Why bother installing it then?

Parent probably means the web version (if there is one - I don't use Slack), judging from the mention of the hosts file. I've had to do things like that, due to my personal lack of self control.

Exactly. I also ban FB, Reddit, and much of the other bullshit at work (and on work laptop). HN is not banned (yet), since SNR is not zero here.

> FB, Reddit, and much of the other bullshit

If they're bullshit, how come you lack the discipline to abstain from checking them?

> HN is not banned (yet), since SNR is not zero here.

I might be misjudging, but you make it sound as if you're pretentious about the content you consume when actually you're placing external constraints trying to prevent yourself from consuming bullshit. In that case, more discipline would be the healthier solution.

Reply on news.ycombinator.com