I can’t work with notifications enabled. Every hour I work, I make a 15 min pause or so and then I check Slack and answer if needed.
Not just Slack, I don’t have any notifications enabled. I always pull. The only exception is phone calls.
Everyone is wrong about that Slack flowchart
21–30 of 87 posts
Re: Everyone is wrong about that Slack flowchart
#22Earlier quoted context omitted.
"Feature flag" development culture is in direct conflict with user's having intuitive, consistent experiences that they can model in their head. If the vendor needs a database report to see what features the user may encounter in any given session, because it's an n-dimensional matrix that changes based on uncountably many factors, there is no mental modeling to be done. The user just experiences some idiosyncratic a…
Feature flag development culture is the only practical way to do continuous delivery. The old approach is still used in markets where it makes sense - database systems, for example, often have only a handful of releases per year. But there's a lot of markets where it's just not feasible to make customers wait 3-6 months between when you finish developing a feature and when it's available for use.
> Feature flag development culture is the only practical way to do continuous delivery.
1. That's not true. Even with continuous delivery, you can still just have a sane and mostly stable roadmap that you're betting on, and gradually migrate all your users along it in a cohesive way with thoughtful transitions when any radical changes are needed. Feature flag stuff is a specific approach to product design that took over a lot of engineering teams in the last 15 years. It relies on continuous delivery, for the most part, but continuous delivery is itself completely ambivalent to it.
2. Continuous delivery is rarely necessary in the first place, and almost never in the interest of users. It gained ubiquity as it became first became practical and coincided with product designer's naive enthusiasm for feature flags, but mostly works against user satisfaction by making it hard for users rely on their tools being in a specific condition at any time.
Re: Everyone is wrong about that Slack flowchart
#23I look at the first flowchart and think to myself, were all the product managers, business analysts, and UX designers drunk when all of that was getting implemented?
Re: Everyone is wrong about that Slack flowchart
#24I didn't see a previous discussion on the flowchart, so I'm not entirely sure why folks were wrong about it.
I do like the updated version. Fun to explore why.
First, it is much much more linear. Effectively top down.
Directions are consistent in outcome. Left is always "don't" and right is "do."
There is no back tracking.
Re: Everyone is wrong about that Slack flowchart
#25Maybe the real source of complexity in that flowchart is there are just too many ways to suppress notifications. You have muting, do not disturb, do not disturb overrides, @message preferences per channel and global, DM preferences, and so on. I love dials and knobs and sliders in my software, but at some point when they are all for the same feature, there is no longer any way for the user to intuit how they interact…
And despite all that, you still can't me @all...
Re: Everyone is wrong about that Slack flowchart
#26Flowcharts tend to suck when trying to describe anything remotely complicated. I doubt anyone is seriously using the original flowchart to get any work done, the actual code must be more readable, and would be guaranteed to be correct.
On the other hand, overloading a flowchart with things like "unless" or "including" makes it harder to follow.
Re: Everyone is wrong about that Slack flowchart
#27Earlier quoted context omitted.
Feature flag development culture is the only practical way to do continuous delivery. The old approach is still used in markets where it makes sense - database systems, for example, often have only a handful of releases per year. But there's a lot of markets where it's just not feasible to make customers wait 3-6 months between when you finish developing a feature and when it's available for use.
Maybe Continuous Delivery is the problem. What are these markets where customers want such frequent changes? As a user, I don't really want my software changing daily, weekly or even monthly. I don't want features to come and go depending on which arm of an A/B test I am in. I don't want to be part of the developer's "experiment" and metrics-gathering.
No individual customer wants frequent changes. They want changes they care about ASAP and changes they don't care about never. But unless I'm maintaining per-customer versions (which can make sense for high value enterprise customers!), promising user X that I won't make any changes until January necessarily means telling user Y that I refuse to resolve their showstopping bug report until January.
Re: Everyone is wrong about that Slack flowchart
#28Earlier quoted context omitted.
Feature flag development culture is the only practical way to do continuous delivery. The old approach is still used in markets where it makes sense - database systems, for example, often have only a handful of releases per year. But there's a lot of markets where it's just not feasible to make customers wait 3-6 months between when you finish developing a feature and when it's available for use.
Maybe Continuous Delivery is the problem. What are these markets where customers want such frequent changes? As a user, I don't really want my software changing daily, weekly or even monthly. I don't want features to come and go depending on which arm of an A/B test I am in. I don't want to be part of the developer's "experiment" and metrics-gathering.
The actual need for continously delivery is mostly related to running public-facing services at large scale that need the ability to adjust to external events quickly, e.g. when defending against a new form of abuse requires an immediate software change.
Al other software could get away with deliberate release cycles rather than an urge to YOLO things into production. I just think that there is a fallacy in business leadership that ultra short turnaround times on features actually matter for a business.
Re: Everyone is wrong about that Slack flowchart
#29The most important thing to me about the original diagram is that it is underspecified-- you can't determine its meaning just by reading it and also having a basic knowledge of Slack. To understand it you need a close and detailed knowledge of Slack UI and behavior that I don't believe has been officially documented. In fact, I'm left with questions about this diagram I can't answer even after experimenting with Slack.
In other words, there is important tacit knowledge required to interpret the logic.
I wonder if there is an updated version of this available anywhere?
Re: Everyone is wrong about that Slack flowchart
#30I think slack notifications are complicated, but getting them shows you things you should see, while eliminating garbage distractions.
That said, I still get silly @here and @channel stuff sometime even turned off per-channel, and miss some thread notifications.
So I wish you could color-code channels/messages/threads to know whether you will be notified and let you tweak things if not.
I think a lot of complexity can be visualized and that helps us fragile fallible humans.