Great examples of explaining an algorithm (or even just a process)

I am unsure what kind of algorithm you are thinking about and what exactly would audience for your document be, but I like how 3blue1brown articles are written

https://www.3blue1brown.com/lessons/matrix-multiplication

Also, I like this recent article, it has fewer illustrations - and has code in their place:
https://tunglevo.com/note/an-optimization-thats-impossible-in-rust/

Crafting Interpreters is a book that's also about design and writing code, but it does explain several algorithms in context.

For a more standalone example, try Pratt Parsers: Expression Parsing Made Easy by the same author.

In my experience a lot of people perceive information better with visual images. If you want to describe abstract things, it is better to make them more concrete and describe through simplified models and analogies. But be aware that abstraction and details should not be hidden, but rather clearly distinguished from simplified models.

If you want to describe the sequence of steps of the algorithm, nothing works better than the sequence diagram.

If you want to show the change of state, then the flow chart will do the job. Also you might find useful activity diagram which is quite similar but more focused on blending algorithm with business processes.

And also there is BPMN to describe business processes and RACI matrix to describe roles.

I know, it is not exactly what you asked for, but over 15 years of engineering work I find this tools the most useful. By the way, thank you for the post! I hope to find some inspiration from other comments too :)

I love this explanation of Raft's distributed consensus protocol by Ben Johnson: https://thesecretlivesofdata.com/raft/

The source code for the animations is available here: https://github.com/benbjohnson/thesecretlivesofdata

Honorable mention

Bartosz Ciechanowski's blog does an incredible job making complex topics accessible while still getting into the details. The focus is mostly physics and machines. https://ciechanow.ski/archives/

Most posts have interactive diagrams to demonstrate key concepts. Highlights:

• https://ciechanow.ski/alpha-compositing/ -- maybe the most directly related to software
• https://ciechanow.ski/mechanical-watch/ -- really impressive and useful diagrams

One more honorable mention

The Illustrated TLS 1.3 Connection by Michael Driscoll: https://tls13.xargs.org

I can't provide a link, but maybe you can find something about how a hashing algorithm works in principle? Or maybe the Diffie-Hellman key exchange?

I still remember when my big brother explained these to me decades ago. It blew my mind that you can create a unique ID with a fixed length from any sequence of characters, regardless of how long it is, and how simple it is. (At least in principle.)

Thank you for starting such an inciting discussion.

I don't know if this is the type of thing you're looking for, however, I have an example.

I like to learn by doing, and when I think of an algorithm, I like to learn by making. For whatever your target audience is, have them consider a problem they have in life, and how they might solve it.

Let's start with a hypothetical one.

Let's say, I want to come up with a way to figure out how "judgemental" a particular document was. I could start by, getting a list of words that I (or people) consider "judgemental." I could then say, "computer, please read this document, and tell me, out of all the words in that document, how many of them are judgemental?"

And the computer could give me a score, "100 of these words, out of 500 of these words, are judgemental."

1/5 of the words, so I could say, the document is about 20% judgemental.

So what does this look like in pseudo-code?

Store a list of words that are considered judgemental as "judgemental";
Read a document;
For every word that is on the list, keep track of the count of words;
Divide the number of words found on the list / the number of words in the document in total;
Report that number to me;

(forgive me for the horrible markdown, I am not versed in it).

And continue to abstract and refine, over and over, until you end up with something like this: and then show them the "algorithm" that is behind the "blackbox" so to speak.

It's been a while since I've been in coding, so I am rusty on syntax and formatting, but I'd say, most people take naturally to pseudo-code if they don't allow the format or computers or math to scare them.

I have attached a visual of how I would explain it to someone as well- sort of like a chalk-talk or whiteboard talk.

Do you know what O(n), O(log n) or O(n*n) mean? If not these 2 lectures may be too formal for you, but they are well structured and explained.

If you have the co-ordinates of points or places, how do you find the closest pair? You could just find the distance between each pair of points and remember the closest and if you had say 10 places that would be fine. You would compare 45 distances.

Point 1 to each of 2..10 = 9  
Point 2 to each of 3..10 = 8 
    - ignore 1 since 1 -> 2 was already done
Point 3 to each of 4..10 = 7  
...

I'm sure you see the pattern. What if you want to compare over 19,495 places like the cities, towns and villages in the U.S? That would be slightly over a whopping 190,000,00 comparisons.

These lectures show (and prove) how you can calculate that with about 200,000 comparisons.

1 The high level overview and details of the algorithm
2 The proof

If you found them worthwhile, hit me up.
Tim Roughgarden is a great teacher and I have plenty of links to share.