A good question about communication that caught ny eye.

In my experience, aint no such thing as a "high level". I think what people sometimes ask us is "Can you explain this so it makes sense to me?". Knowing who the "me" is (what they want and why), is the key.

Communication is always tailored. It exists in a context in which the recipient is "held in mind". And it's dialogical, so you can jam it and ask "What would be the important things for you to know?".

It can make you feel put upon, and that it devalues your detailed knowledge. The words "high level" often get someones goat because of the lofty assumption. Everyone sees themself as at the "top" of their information pile. Many years ago I felt that people asking "give me the view from 30,000ft" were just lazy and entitled. I've come to regard crafting succinct help as poetry to enjoy.

If you're the person asking that question it helps to introduce yourself, your role and needs - even if you think the person you are asking "should know" who you are. So I might say "As chief widget wrangler, what should I know about..."

> Everyone sees themself as at the "top" of their information pile. Many years ago I felt that people asking "give me the view from 30,000ft" were just lazy and entitled.

That’s exactly how I feel. I do go on and craft stories and make things nice. But after years of doing that I still wonder if all that “simplicity” does any good to the world. All the ignorance and missed learning opportunities…

It's always worth giving people the benefit of the doubt on the first time. After that....guess there's one exception I still make. I learned that it's called "sealioning". When someone repeatedly, dishonestly professes ignorance as a way of making an obtuse argument. I see a bit of that wilful ignorance here on HN when people say things like "I don't see why... <self evident, commonly known truth>"

In my experience it's a skill that takes time to develop. It's hard at first for sure. There are lots of different models out there that people using for visualizing software and architecture, sometimes they can be helpful.

A piece of guidance that helped me a lot was this: "when looking at boxes and lines, the junior architect looks at the boxes - the experienced architect looks at the lines."