[tjpaudio]

The article is written for people interested in the very specific topic of the technical workings ACH transfers. It seems absurd to me that you would try to write this article to an audience that hasn't even heard of ACH. I think the only thing you are missing is that you are not the target reader.

[munk-a]

Elitism is no reason to avoid having a definition of jargon. HN has discussions on a wide variety of technical topics most of which aren't directly useful in our day job - or at least on the topic of information we'd seek out independently... But we have this list in part because intellectual curiosity is a good thing and maybe, within the way that whatever an ACH is deals with a dead person, there might be some interesting logic that you could apply to your own field.

If someone submitted "How I managed to emulate Super Mario in C without using more than 30 Kb of memory" I'd be super interested and look to see what sorts of crazy pointer tricks or unioned structs were in use - even though I don't currently work with games or C in my daily.

[tjpaudio]

It's not elitism. ACH is a term that should be familiar to anyone even remotely informed on the topic. It's ok to read articles on things you are unfamiliar with but it is also on you as the reader to educate yourself when you read on topics that you are unfamiliar with.

If every detail was explained in layman's terms, reading would be terribly boring and nuanced technical writing would be dead.

[munk-a]

But... I've worked with technical writers and PhDs, technical writers (the good ones) can really easily pull analogies out of thin air to help elevate a reader's understanding, I think (maybe due to star trek) that a lot of technical PhDs are quite good at forming comprehensible analogies as well. Usually CS papers are ~40% comprehensible to the vast majority of non-CS people, this differs from more liberal artsy fields where other field pieces are taken as a given and the assumptions compound to the point where education ends up being about familiarizing yourself with all that jargon.

There are some terribly complex CS concepts (try and explain how a hash function produces essentially random output - or how private and public keys are actually computed in a manner to make private keys non-trivially derivable from public keys) and some terribly ingrained jargon (Oh, how's that SSL cert was it SHA signed?) but the effect on your topic of how these jargony terms work is usually easy to express, you don't need to know the history of POSIX to comprehend that CS people have a tool that checks if a string sorta looks like an expect format that we use everywhere, and you don't need to explain positive lookahead zero width assertions to convey that point.

Having a single clause stating "ACH (the preferred US method for bank-to-bank transfers)" would instantly clear all this up... it's also insanely relevant because the topic of the article is about what happens when bank-to-bank transfers have a recipient who is dead.

[pessimizer]

When I run into something I don't understand in the title of an article, I just look it up on a search engine. When it's the first hit, I read the capsule description, then return to the article. Alternatively, I often decide that I'm probably not interested in reading an article when I don't understand the terms used in the headline.

[KC8ZKF]

Fully expanding an acronym the first time it is used is part of standard written English (SWE).

[pessimizer]

Expanding that acronym wouldn't help. I hate to get into this silly discussion, but we're all having it on the internet. It's easier to find out what ACH is by using the internet than to post a question on the internet asking what ACH is.

[KC8ZKF]

Regardless, it is still a standard courtesy.