Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everyone is wrong about that Slack flowchart

sophiebits.com

Post reply on HN
Print view View original

51–60 of 87 posts

Re: Everyone is wrong about that Slack flowchart

#51

Post by ivewonyoung »

anitil wrote: post #43
ivewonyoung wrote: post #36

Earlier quoted context omitted.

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.

I have a second channel for urgent things, which is a phone call. I've told everyone that I'm available whenever, but they need to pick up the phone and call me. Surprisingly that little bit of friction seems to downgrade issues from 'urgent' to 'we can fix it tomorrow'

The issue is that sometimes something comes up that I can choose to quickly address and get folks going again. Adding that friction causes waste of time.

Re: Everyone is wrong about that Slack flowchart

#52

Post by switch007 »

redrove wrote: post #50
Terr_ wrote: post #46

A separate gripe: Still no support for "batching up" a trickle of notifications from a particular DM/channel, which is especially frustrating on the phone-app. *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.

bzzzt Hello * 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.

You can mute people now. Thank god

Re: Everyone is wrong about that Slack flowchart

#53

Post by ajb »

gmueckl wrote: post #44
wbl wrote: post #38

Earlier quoted context omitted.

Until you have the feature in production you do not know if it works.

Engineering is about making certain that stuff works before it enters production. If we claim to do software engineering, then that's just a simple part of doing our job. Everything else is just tinkering and hacking (the bad kind).

From an engineering point of view, yes. But not from the business point of view.

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.

Re: Everyone is wrong about that Slack flowchart

#54

Post by IshKebab »

kibwen wrote: 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 think it's ok to combine simple booleans into one box for the same reason we do that in code.

You generally write `if a and b { foo }` not `if a { if b { foo } }`.

Re: Everyone is wrong about that Slack flowchart

#55

Post by alextingle »

wbl wrote: post #38
gmueckl wrote: post #28

Earlier quoted context omitted.

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.

That whole approach is so disrespectful of users. If you are a serious business, then hire sufficient QA people, and empower them to do their job.

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

Re: Everyone is wrong about that Slack flowchart

#56

Post by Self-Perfection »

Terr_ wrote: post #46

A separate gripe: Still no support for "batching up" a trickle of notifications from a particular DM/channel, which is especially frustrating on the phone-app. *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.

Telegram does batching for group notifications.

Re: Everyone is wrong about that Slack flowchart

#58

Post by coldtea »

kibwen wrote: 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…

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

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?

Re: Everyone is wrong about that Slack flowchart

#59

Post by psd1 »

luke_galea wrote: post #40

I think the slack flowchart is a great example of where declarative programming really shines. 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 will invest that time later. In anticipation, thanks.

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?

Re: Everyone is wrong about that Slack flowchart

#60

Post by nimblegorilla »

IshKebab wrote: post #54
kibwen wrote: 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 think it's ok to combine simple booleans into one box for the same reason we do that in code. You generally write `if a and b { foo }` not `if a { if b { foo } }`.

From my perspective simple boolean means a single known value stored in one variable. I suspect the underlying code performs a number of calculations for each one of the flow chart "booleans". Of course, maybe that points to a design flaw and there should be a single policy instance that aggregates all of the variables into one place.
Post reply on HN