The key thing here is to avoid making the same comparison more than once. And there is one sort that really meets that criteria in a way that is doable for a human sorting their movie collection.

[Merge sort](https://en.wikipedia.org/wiki/Merge_sort).

With the merge sort, you recursively break down the size of the set to 2 (or 1). And then you sort each of those. Now, you take two sets of 2 (the actual algorithm takes it down to sets of 1, but we're doing this by hand and so can avoid that level of exactness), and then compare the first element of each, of those.  If you have <kbd><kbd>3</kbd><kbd>6</kbd></kbd> and <kbd><kbd>2</kbd><kbd>4</kbd></kbd> - you have already compared <kbd>3</kbd> and <kbd>6</kbd>, you aren't going to compare them again. The resulting set then becomes <kbd><kbd>2</kbd><kbd>3</kbd><kbd>4</kbd><kbd>6</kbd></kbd> and then you continue on merging with the next set of four.

From the wikipedia page:

<img src="https://upload.wikimedia.org/wikipedia/commons/thumb/e/e6/Merge_sort_algorithm_diagram.svg/618px-Merge_sort_algorithm_diagram.svg.png"></kbd>

The key here is that with each comparison, you are not *reevaluating* the previous comparisons. Thus, if you decide that you like the Yellow Submarine more than the Hard Days Night once, you are not going to re-evaluate that and they aren't going to end up too far from each other in the end.

The problem with many other sorts is that you are either constantly asking "do I like this more than Santa Claus Conquers the Martians" each time with a selection / insert / bubble sort. And other sorts become far too complicated to be able to reason about.

---

A way to test this that would make for some very interesting blog posts is to implement the different sorts yourself and override `>` or `compareTo` in your chosen language.  In that method, add a slight bit of randomness to it, say, +/- 10% of the value. or +/- 1% of the value.

Then, sort the numbers 1 .. 100 100x and see how far out of whack each sorting method results in.