Paid server.
Android client.
Lightly used, in part due to the absence of notifications.
It's been over a year that I've missed notifications. More than 50% missed, comments to my threads especially, and also new messages on watched channels.
Sounds like an issue with your android phone.
Similarly, complex flowcharts aren't necessarily something to be proud of, rather, something to be eyed with suspicion. Is that complexity essential complexity, or accidental complexity?
(Though sometimes it can be infuriatingly difficult to simplify. I've attacked a few such codepaths in my career only to come out going "nope, it's just that terrible/complex.")
On notifications, one of the best things I ever set up was making my name a notification trigger. Lets me know when people are talking about me (or even to me), but aren't using a @- tag. Some people just … don't seem to know how to do it?
¹trivial enough that it leaves me wondering: does Slack's own eng use Slack, with cognitive awareness of the things that they run into?
Slack is not good with that but man what are the people smoking that designed MS Teams? What the actual fuck happens when you try to type, copy, paste or send a message?!
Slack is an oasis of sanity, compared.
DnD on? Nope still get notified. Government sends Amber alert? Yea let’s full send it across the entire state for a crack head vs police incident that occurred 500 miles away at 4AM.
Severe weather alerts have now been moved to voice calls and that number whitelisted in my contacts
Most work apps have a permanent 'Away' status and a message on and the expectation set that I sparingly check throughout the day. It works really well, my mind has never been quieter and more at ease.
If I were to suggest a way to make the original chart cleaner without changing the quantity of explicit nodes and branches, I would start by reducing it into parts that are cyclic and parts that are acyclic, then drawing clear divisions between those parts. Then you could give these encapsulated bits names and thereby make it easier for them to refer to each other (such as in the duplicated flows between local and global preferences) without having to draw a mess of crisscrossing lines.
This will vary on the language in which it is implemented, right?
You generally write `if a and b { foo }` not `if a { if b { foo } }`.
It kind of does though, because it's easier to understand what the system does in general without necessarily wanting/needing all the lower level detail.
That's also one of the reasons we use functions, instead of unrolling everything into a big ball of code, no?
Which is fine for someone working a job that doesn’t need to understand all the stuff behind the curtain, but not fine for anyone who actually wants to understand the overall system.
It's a representation. The actual thing will still have the whole complexity.
What is reduced is how much complexity we take in when looking at what the thing does. When someone wants to get an idea of what the thing does, as opposed to getting into the minutiae of every subcase, such a high level view is a better fit.
People looking at flowcharts usually don't need the entirety. Especially as the flowchart could even be out of date, or miss some of the code-level subleties.
And I don’t see why it matters if it’s only a handful of people, information products can still be created for their needs, if so decided.
Code is not always the same as the process or what the machine actually does... There are hundreds of posible factors from bitflips to a cable getting loose in a socket that could change either.
e.g. There clearly can be a computer configured with enough memory and dense enough memory that at least one bitflip is practically guaranteed in a certain unit time, so the actual process has to include that.
So the code is an abstraction just like the flowchart.
At the end of the day, is it the cover-every-possible-bitflip-and-gamma-ray-bursts process that produces results out of thin air, or is it the machine running the code?
I don't believe this is arguing in good faith.
You seem to be making a logical fallacy to impute that it somehow must exist.
e.g. “ The absence of evidence is not evidence of absence.”
Also why would any other reader, including me, care about beliefs about certain words more than the actual words?
You started with why aren't they "just looking at the full flowchart [to understand the entirety]".
And the parent wrote that because the flowchart is not the entirety, the code is.
Do you think this retort you make above is refuting the parent's point? If anything, it expands it, going further against your original point: that's why they're not just looking at the full flowchart.
And, yes, "code is an abstraction, just like the flowchart", but code is the abstraction the programmer controls and tries to summarize and understand. The flowchart is a higher level abstraction of an abstraction.
e.g. “ Because the code is the entirety of the process” is clearly false regardless of which way you look at it.
But ‘the code is the combined understanding of the entirety of the process’ may or may not be true depending on many many factors.
‘Understanding X’ clearly does not mean, or even imply, that it literally is this or that…
No, but you seem to be about any context not spelled out completely and pedantically.
>e.g. “ Because the code is the entirety of the process” is clearly false regardless of which way you look at it.
A coder works on code (literally editing lines of code, which is what they deliver), and is called to create, understand, and debug code.
Else, sure, code also runs on some server, by some organization, that had meetings to decide the requirements, and there are also end users, and the whole thing runs in some planet, inside a universe, or perhaps a multi-verse, so the code its not the entirety of the process /s
The original diagram does this too - it has an "A && B" node.
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.
Does the complicated flowchart point to deficiencies in the Slack user interface? If the user cannot intuit the flowchart, then how can they (as several sibling comments rightly point out) reliably turn notifications on or off?
Algorithmic transparency should be a thing, no?
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 amalgam of code in each session, and the vendor watches aggregate metrics to make sure the number of users in immediate crisis remains below some threshold -- bringing in a $XXXX/hr on-call team to identify and apply some adequately impactful change if it breaks over. Meanwhile, the users-in-crisis cross their fingers that the next time they open the app, they get a better roll on the feature matrix and encounter a more tolerable subset of issues.
If you want to be able to understand your software and know how to turn things on and off, you need to demand a whole new (old) approach to building and publishing things. We're way off track right now.
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.
It's like a restaurant. You can make sure they new dish tastes like what you intended and isn't going to poison anyone, but until it's on the menu you don't really know if people will want to eat it or if it will be a success for the business.
This does make me wonder whether there's a place for a system where you split your usebase into N shards, and only deploy new versions to one of them; reducing the update rate from a user perspective by a factor of N. Of course, this means you have to maintain compatibility with N versions, but that's still better than N feature flags.
Expecting your customers to do your QA for you is super common these days. But that doesn't make it right.
(What really infuriates me is the general lack of feedback channels that enable users to actually contribute to QA. With open source software, end users can at least open a ticket on the bug tracker. If it's a commercial product, all too often the only point of contact is a disempowered call-centre worker, who can't even log a bug for you.)
It can decrease the chances but isn't a panecea.
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.
Sometimes @channel is important, because everyone in the channel knows to use it sparingly.
Sometimes one person just constantly spams @channel in every message.
So you do need different settings.
So you need the nuance to deal with the nuance of people.
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.
On the other hand, overloading a flowchart with things like "unless" or "including" makes it harder to follow.
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?
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.
(user not DND || message DND override) && ((message in thread && user in thread && user threads_everything) || ((channel notifications everything || (channel notifications unset && global notifications everything)) && ((message not in thread || user in thread) || (message has @channel || (message has @here && user is active)) && @channel messages not muted) || message contains @mention || message contains highlight word || message is on file owned by user))
Me: mutes all notifications at the OS for Slack.
You might enjoy this talk about rules engines where I simplify part of Slack's notification logic: https://youtu.be/mDnntrhk-8g?si=K1_8pU-Ck1fsCUM5
Fun stuff!
I came here to see if anyone was talking about state machines that generate their own flowcharts, or codegen from flowcharts. I'd like to know if there's prior art.
It would be great for user acceptance. I'm minded to have a go myself, possibly with mermaid as an intermediate description. Stupid? Non-stupid?
Next challenge: generate fsm from mermaid flow chart!
> I know this is not 100% bug-for-bug compatible with the original flowchart.
“For every complex problem there is an answer that is clear, simple, and wrong.” (https://quoteinvestigator.com/2016/07/17/solution/?amp=1)
(It’s not my intent to be totally dismissive, the author has good points, but I couldn’t resist the pithy but misquoted quote)
*bzzzt* You probably met him, that one guy
*bzzzt* who sends messages like this
*bzzzt* and each time your phone vibrates for attention
*bzzzt* but you never needed to know that soon anyway.
* waits 20 minutes *
bzzzt How are you?
* waits 3-24h *
bzzzt Can you help me with XYZ?
I answer ASAP
I hate these people. It’s such a drain on my mental well being.
I anecdotally associate "those people" with either:
1. Job roles (e.g. Sales) or personalities that are accustomed to interactively pushing people to do things for them
2. People who don't feel safe assuming that I can/will help.
3. Someone struggling to describe their problem up front, so they aren't sure what to place in my metaphorical inbox
4. There are multiple people they could reach out to for help, and they're trying to determine which person might react soonest. (But they aren't using other strategies like posting their problem in a channel and @-mentioning multiple potential helpers.) Their problem may or may not merit the kind of latency they're looking for.
Is it Mermaid, Graphviz, some other tool/lib, some GUI tool like Visio, Lucid Charts, etc?
I also get reminded that Telegram has one of the simplest notification schemes in existence. Notify last used device -> If still unread after ~30 seconds notify every logged in device. That's it, dead simple, never missed a TG notification.