Everything you've just said is gibberish to a master.
It's like making a straight-faced argument that setting the speed limit to 1 mph on a motorway might make perfect sense, and the traffic engineer is actually at fault for not making it clear that this is nonsense.
I get that you don't see the ridiculousness of 50 microseconds vs 5 milliseconds, but that's the point.
You don't see it, and you start making random arguments untethered from reality.
The fact that you are blind to it, unlike being blind to 1 mph vs 65 mph is the entire point.
You may have driven thousands of hours. You have don't have thousands of hours of network performance tuning expertise.
Both of us wouldn't be able to even begin to understand the complaints Ayrton Senna might make about how the steering is too "crunchy" at the extremes or that the brake strength imbalance is shifting the car about.
There's levels of expertise, and if two people are too far apart, meaningful communication between them becomes impossible.
Ok? But you are required to motivate a decision that is based on terms, conditions, probabilities, consequences that can only be encoded at knowledge-level A. When projected down to knowledge-level C, it sounds like "otherwise bad things might happen".
The jargon is not what matters. The logic of the decision is not meaningful or believable without knowledge of the "physics of the system" at level A.
Most people understand nuclear bombs in layman terms, and they understand them intuitively from watching videos and pictures. Without videos and pictures, no one would care.
Law firms are run by lawyers. The chief of surgery is a surgeon. Architecture firms are run by architects at the top.
Why is it that in IT it is expected that all management of IT is “non technical” to the point of not understanding what they’re hearing from direct reports!?
Would it be normal in your mind for a chemical plant foreman in charge of the process to not know what atoms are!?
Have you ever spent any significant time in an environment where most people are not (children of) college graduates? Because this is absurd. The average person who has just finished a year of high school physics probably can’t tell you those.
Do they work for a high frequency trading firm? Do they make a CRUD app which has few users and (as much as I hate that) "they can wait even 5 seconds".
If the person does not give context then they dont explain well..
On a side note: for me the problem seems to be not the speed, but the choke point - just 2 servers (with no redudancy?). What one or both go down?
You've disproved this yourself earlier in this comment. You made an analogy to explain a concept to a non-expert.
It is entirely on you to make yourself understood to non-experts. It is both possible and extremely important.
That is rather a condescending take: calling yourself a master and calling their words gibberish is hardly thoughtful dialogue. Other parts of your comment are equally bad “ untethered from reality” should not be written. Someone is trying to engage with you and you are dismissing them by using very charged words. Even worse you are demonstrating poor communications skills - that point being questioned elsewhere in the thread. I hope you can learn to listen to others politely even when you disagree, and please try to follow https://news.ycombinator.com/newsguidelines.html :
Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. Comments should get more thoughtful and substantive, not less, as a topic gets more divisive. When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." Please don't fulminate. Please don't sneer.> It's not a lack of skill on the part of the expert, it's the lack of skill on the part of everybody else
This is a very poor frame of reference. It's not other people's fault they cannot understand the value you provide, it's your fault.
The thing that tends to bother engineers is that articulating your value (I.e. sales and marketing) is generally orthogonal to your key competencies.
I can, and have, explained 'deeply technical things' in 'business terms'. And people understood. Then made a bad/poor/wrong choice anyway, because... "well... all those things you're saying might happen, they might not. Or... it may not happen for months or years, and we already committed to date X for project Y".
I can tell people the cost of punting on 'deeply technical thing' will be enormous, like... "this will require doubling the dept headcount and stopping all new progress for 6-12 months". Then offer alternatives. Then get summarily ignored, and watch things crash months later, and the dept is then stuck for months scrambling to understand all the problems they could have avoided. The decision maker who decided for extremely short term gain? They're gone (sometimes of their own choosing, sometimes not).
The "risks" can seem wildly out of touch with reality, but many times if you're making poor choices you do hit the "worst case scenario" wall. Colleague has been contracting inside a shop on and off for a few years. He indicated "if we don't do X, we will not be able to do any new feature development for at least 18 months". And... closing in on 4 years later, they've not shipped any substantial new features (some bug fixes, but that's about it).
I've seen this happen once up close, and have seen inside other companies and got the war stories from others.
Does this happen every single time? Of course not. But even if you can confidently and correctly and pleasingly describe deep tech things to business folks in their own language, showing the pros/cons/costs/risks... that doesn't mean they will take your side. Saving face, hitting deadlines at all costs, and other factors weight on decisions, and you can't control that. You can control where and how you work though.
Both the storage vendor tech and I vehemently argued for solving this immediately but were told to “do it later”.
I pointed out that “later” would be when it is full and has 10K production users using it 24/7. Hence any reformatting would be a six-month project requiring additional kit for the scratch space needed.
I was wrong. It took 12 months.
The position is that intentionally being a bad communicator guarantees poor results most of the time.
Same way that not driving drunk does not guarantee you won’t get in a wreck.
Yes, maybe I desperately need to frobulize the macrowublitz to avoid pracknation, but I’ll wait for someone who can explain why it’s a high priority to achieve my goals.
> I'm surprised you've spent your career doing this and you still haven't figured out how to get people to listen to you.
This is the point of the article, which you appear to have missed.
There's a point where it becomes essentially impossible to articulate the differences to the lay person. Or for that matter, someone actually quite skilled, but not a "master".
It's not a lack of skill on the part of the expert, it's the lack of skill on the part of everybody else.