In hindsight, I guess it's sort of forgivable given his age. The topic probably wasn't even invented yet so he couldn't have learned about it in school.
Not everyone learns the same terms for the same concepts. Maybe you should be a little more accepting that not everyone had the same education you did.
"That operation is O(n log n)"
"Sure, but that operation doesn't happen on every loop, the entire algorithm is still O(n)".
However, language for concepts evolves with time, and younger programmers shouldn't assume that older programmers don't know a concept because they learned it by a different name. (Though they might not know the concept).
I remember seeing production code slow to a crawl once because of that one. It wasn’t long after I’d left university, where I’d studied CS but the lectures on complexity theory had seemed quite theoretical at the time. Suddenly, here was a vivid example of how it could cause a problem in practice, in a situation as everyday as putting some text in a UI. The solution — using a string builder — then led me to several other principles about choosing an efficient internal representation for data and it being OK not to convert that data into its “true” form until you’re ready to use it. I suppose I should thank whoever made the original mistake, because despite causing a frustrating afternoon with a profiler, it also created several lightbulb moments early in my career.
"All science is either physics or stamp collecting." -- Ernest Rutherford.
I suspect there are many people who understand the Big-O, Omega, Theta, and Little-O implications (the physics) but might not have heard the term "constant time amortized" (the stamp collecting).
(Not that knowing accepted names is bad, it's much much easier to communicate when everyone shares a set of terms that they agree on the meaning of...)
My graduate level algorithms class used average or probabilistic cost, but never the term amortized.
A constant time operation has bounded runtime for every input, but an amortized constant time operation can allow for much longer runtimes so long as they happen sufficiently rarely. Concretely, doing an amortized constant time operation N times should be O(N).
Why not use actual statistics jargon at that point?
Sometimes we need to realize that the reactions of people inside of the software community are almost purely due to their own personal (usually social) insecurities and are not worth addressing.
We have an entire thread giving credibility to someone who absolutely idiotically dismissed another person for not knowing the meaning of a single word.
The person who was temporarily ignorant of the meaning of that word is not the one I am thinking needs to be ignored here.
Insertion is O(1) (constant time), most of the time.
But once in a while the collection will need to increase the size of the underlying array, which causes the entire table to be reorganized. That specific insertion will then be O(N) (where N is the size of table). The good news is that this reorganization happens only once every N insertions.
So amortized insertion is O(1), even if in the worst case it can be O(N). Depending on your use case you can hand wave the worst case away with "amortized it's constant time", or you can choose a tree instead, for a more predictable O(log N), or you could use some other mitigating tactic, like initializing your hash table with enough storage _for all use cases_ so you can guarantee O(1).
I suggest that you consider whether it’s possible that other people know the same concept under a different name and don’t write them off as quickly if they don’t know your favorite term.
I am surprised at how blithely you assume the terminology you learned at your particular college is universal, and how parochially you seem to look down on people just because they don't share that particular terminology.
So my advice would be don't be too quick to judge people based on assumptions you make about them.