If you're pretty junior, or you work with a lot of loudmouths, you might need to turn the volume up higher to make sure you're listened to. If you're senior, or talking to a group of people more junior than you, you can get away with being a lot softer with your words. (And you often should, to avoid intimidating the juniors). And its not really about volume. Its about your word choice.

Low volume: "Hm, that sounds ok but I'm worried about performance."

High volume: "This will be unworkable because of performance problems. We need preliminary benchmarks, or a plan for solving those problems before we can move ahead."

Very true! And if they see senior engineers asking questions, they will hopefully feel more comfortable doing the same.

(For reference: I've been paying my bills with code for a good 20 years now.)

I've learned 80% of what I know about Javascript, Typescript and React from one dude on my team who was freshly out of university. The dude was (and still is) a damn genius at that stuff.

If he doesn't burn out by overreaching, he'll be a legend by 2025 =)

We literally took away his work laptop and disabled his office key access so he wouldn't work during his summer holidays :D

I have decades of experience, but there’s often stuff I can learn.

Here’s an example: I have developed an SDK, with heavy documentation, but I have found that written docs aren’t actually very useful, as no one reads stuff anymore.

So a new engineer on my project showed me Postman. Before, I’ve used far humbler REST explorers. In turn, I showed him Charles Proxy.

I’ve actually gone way beyond what he needed with it, because it’s a great tool.

It is not a 100% replacement for my docs, but it will help a lot.

I can develop an architecture that is way beyond anything he can do, but it’s worthless, if he can’t write stuff that uses it.

A line from another article posted to HN today I remembered is:

"An API without a reference implementation and command-line client is called a gray box."

I totally agree with that. If your API/SDK has an easy way for me to copy/paste some code or command line examples to "play" with it, I'm about 1000% more likely to take it seriously.

“Whaaaaaaaaaat you never heard of that, its so popular, everyone’s into this”

I just wait patiently and stare, maybe an occasional “ah, mmm”

and then eventually say “so can you tell me about it”

and really the answer is no, most people can’t articulate themselves and provide filler instead

it’s usually in relation to anything someone is passionate about, or an assumption they have that supports their passion. such as a social norm or ideal, not just engineering

We were having a regular status call and since the meeting finished early there was a general chit-chat happening.

That is when we started talking about "iphone" and our boss innocently asked "what is iphone" (it had been on the market for a year since its first launch)

We started looking at each other in disbelief. But we knew this about her. She used to openly ask in a meeting without shame on things she did not know. But once she understood something she use to process that info very well.

The team really adored her because she was so good in other managerial things (like defending team, good rapport with individuals, planning, etc).

Back story was that all her time was spent with her 2-3 kids leaving no time for other things.

In the cases where I've been welcoming new individuals into teams it has always been made clear to them by me that there are no stupid questions, everything can be challenged if the argument for it can be made and that I don't know everything and wont/can't come up with all the ideas (ie they could very likely come up with a good idea to a hard problem).

In my experience this has really made it a pleasant experience to introduce new developers (fresh from uni or new to the code base/domain) to the product and team.

Just for context, in the country I reside in there isn't this emphasis on titles in the software space, and as such I am not a formal senior dev at my company. I believe I would have that title if living in a country where such distinction were normal.

Not always the case, but when you see people pushing heavy, runtime-script languages full of ambiguity to modernize an old simple compiled code base, it's hard to do the wait and see and show 2 years later to the juniors: "see your lombok spring thing is now absolutely unmaintanable when all it does is 3 multiplications"

It s often a balance since nobody likes change, junior like senior, and often both sides have their crap.

And often the interactions themselves are the teachers. My mind was blown when a particularly bright child asked me what's the difference between a dream and reality. The best I could come up with is that this 'reality' has a larger continuity and is the one that people in this large continuation agree to call 'real'. I don't know what I could have said if he mentioned a recurring dream with a continuing state. I did say that boils down to a label assignment in case it that should ever come up.

This makes reality a social phenomenon, beyond just physics. For example, institutions are a reality because many people believe in them; the police don't go away when criminals stop believing in the law.

If you get enough people to believe in your dream, it can become real, self-sustaining. Neil Gaiman wrote a nice short story, taking the idea literally - A Dream of a Thousand Cats.

To be more verbose, by "institution" I mean stable, recurring patterns of behaviour (much like https://en.wikipedia.org/wiki/Institution), which isn't that far off of the continuity point made by the parent.

Definitely! This is something I do a lot and love to do. I’m excited when i realise “oh, rather than reading and reading in this topic - I can ask (a person who happens to be junior) if they’re not too busy”.

Everyone learns off everyone the whole time.

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.

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

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

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.

My graduate level algorithms class used average or probabilistic cost, but never the term amortized.

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.

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

So my advice would be don't be too quick to judge people based on assumptions you make about them.