> 5. Engineers are not turned off by jargon—in fact, they like it.
I think the point is right, but the reasoning is off. Jargon (at least in engineering) isn't a secret language for the benefit of confusing outsiders, but more words that have more specific meaning than more common words. Eg, "Use our API to run your container images" tells me a lot more than "Use our product to run your software". Software could've been compiled binaries, virtual machine images, raw code, excel macros, whatever. This ties into other points about how engineers evaluate products.
Also important to mention that engineers don't like jargon for jargon sake. If you use the right words wrong people will sniff you out.
We had a vendor who was trying to sell us some cryptography solution. They were loosely talking about quantum cryptography in their presentation. Some of our security minded engineers stopped them talking and questioned what they are exactly selling. Is it quantum encryption where the secrets are encoded in the quantum state of the transmitted photons? Or is it quantum-resistant cryptography where the crypto primitives are selected such that they should be resistant to attacks employing quantum computers? Turns out they could not answer. Seemingly they were just using the word because it sounded cool.
So talking jargon without having the technical depth can seriously backfire. In our case it made the whole meeting have an adversarial tone going forward and I haven't heard about that vendor since.
Right, their reasoning in 5 and 6 sounded like the point is to just appear like an engineer. It may be enough for the ad guy, but I don't think it's strictly what the engineer wants. IMO, it relates to the previously made point that engineers want clear and accurate technical communication.
I think there are 2 mechanisms for jargon, and he misses them both;
1) Easy filtering caused by precise communication. A non-jargon term is missing nuance. The audience can't tell if they should be interested (probably not). This is your API vs Software.
2) courting the customer by speaking their language. If a marketeer indicates some level of knowledge, the engineer is more willing to spend time: The chance to gain something usefull is higher. If a marketeer sells an API, I might ask if he also has a library, because I know he understands the question.
> courting the customer by speaking their language
Ugh, that's like trying to use urban slang in your ads to appeal to youths - probably not going to go down very well unless you're very, very on point.
Most of the reasoning seems off, probably because the writing is based on those subset of engineers who eventually bought the product after being approached. For one reason or the other. : )
Probably the "doesn't like advertising" is spot on, but that is so for all human beings, except marketing lifeforms (some would argue that there is little or no overlaping between the two).
There is a form called whitepaper that is a kind of neutrally worded technical spec with a hint of advertising. I haven't seen many, but the ones that I saw I liked!
A good example, especially if you are interested in any facet of video imaging, is [0] and here is why: 1) it provides standards references, 2) it provides usable first approximations you can execute right away to verify them, 3) its examples are well-selected. Since my company supports about the most conservative industry on Earth, we have to convince layers of bureaucrats we know what we are doing and the concepts therein helped us do it. We will not necessarily buy the company's products, but they certainly gave us some ability to attach numbers to what was a bit hand-wavy. In return the company is now 'of interest'.
Containers is a good example of how things can go wrong as well, especially when you aren't familiar with them, and you are looking into related technologies, like kubernetes, and suddenly you fine out you have 10 layers of terminology to understand before you can even get started.
There is a joke about functional programming: in order to understand functional programming you must first understand functional programming, and once you understand functional programming you lose the ability to explain functional programming.
I think the point is right, but the reasoning is off. Jargon (at least in engineering) isn't a secret language for the benefit of confusing outsiders, but more words that have more specific meaning than more common words. Eg, "Use our API to run your container images" tells me a lot more than "Use our product to run your software". Software could've been compiled binaries, virtual machine images, raw code, excel macros, whatever. This ties into other points about how engineers evaluate products.