Live data from Hacker News

Everyone is wrong about that Slack flowchart

sophiebits.com

31–40 of 87 posts

Re: Everyone is wrong about that Slack flowchart

#31

Flowcharts 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.

That flowchart is absolutely what happens when a bunch of programmers got told to "draw the complete system" in one diagram - which is absolutely not how it should've been represented.

Re: Everyone is wrong about that Slack flowchart

#32
post #8

I just turn off notifications completely. Horribly implemented notification systems have completely turned me away. 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

Same, my phone was gradually turning into another point of control over me, rather than the other way around and it being a tool to help me. Only a handful of people are default allowed through DnD, all of the nonsense government alerts are off, almost all app notifications are off save for absolutely the most important ones. If an app somehow breaks through after all of that, it's an instant uninstall, I just don't…

[dead]

Re: Everyone is wrong about that Slack flowchart

#33

Earlier 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.

Agreed. Speaking as a user, I much preferred when the industry in general had a slower release cadence. I want to update once every year at most, and usually I want to update less frequently than that. Continuous delivery is a thorn in my side.

Re: Everyone is wrong about that Slack flowchart

#34
guys I simplified it to a single node in a flowchart, this is even simpler right?

(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))

Re: Everyone is wrong about that Slack flowchart

#36
post #21

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.

I wish I could do that but rarely I do get something that needs my attention immediately because I don multiple hats including Infrastructure,SRE,DevOps,SysOps,programmer etc.

Re: Everyone is wrong about that Slack flowchart

#37
post #14
post #9

I don't know if I'd classify the cleaner diagram as "cheating" per se, but it does trade one kind of complexity for another kind. Removing nodes by adding a concept of implicit branches via "unless" clauses within a node doesn't necessarily make the system any easier to understand at a glance. Sometimes systems have good reason to be complex, and sometimes we have good reasons to hide much of that complexity, but let…

I agree with you; it is hand-wavey and strays into "spherical cows in a vacuum" territory. Practical for discussions, not so great for implementations, where details matter greatly. I would presume the original diagram was meant to align on the specifics; the revised version from the author leaves much to interpretation.

> I expect it is also easier to verify the correctness of and find bugs in my diagram if someone were to want to.

This will vary on the language in which it is implemented, right?

Re: Everyone is wrong about that Slack flowchart

#38
post #28

Earlier quoted context omitted.

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…

Until you have the feature in production you do not know if it works.
Post reply on HN