Bored of job applications. So, let’s try to reconstruct my reasoning here.

Right away I could see that naïvely iterating through all combinations of jetstreams would take O(n!) running time. It even takes Ω(n!) running time, so that’s an obviously bad idea. So, I’m going to have to build the solution iteratively, using some sort of loop invariance to make the reasoning easier.

I’ve been playing around with functional programming, so I’m going to avoid mutating data structures. I’ve also been impressed by Clojure’s pragmatism, so I’m not going to go out of my way to do things in a completely functional way. Also, my programming environment is Emacs with an interactive Python. I prefer Python 3 for a variety of reasons, especially the numeric tower.

First choice was whether to iterate from the start or from the end. Logically, they are equivalent, but forward is easier on my head.

So, I sort the jetstreams by their starts, ascending. That way, I can iterate through the jetstreams only once to add them to potential paths, and for each jetstream not worry about whether to add another jetstream in front, because I already calculated that possibility.

Now, how to represent the paths. A path makes an ordered list of 0 or more jetstreams. I would prefer to use a LISP CONS of jetstreams, because it’s inherently immutable, but that’s not idiomatic in Python. I was just working on a multithreaded project where I accidentally created a race condition because Python lists are mutable, so this time I’m making sure that I’m creating new lists every time. And I might as well add a couple object-oriented fields and methods to make my life easier. Then I just dump these paths into some sort of container.

Come to think of it, I could do both the paths and the streams with priority queues, paths sorted by start position and streams sorted by open position.

My 2 basic data structures defined and found to be working, now I need the algorithm. In Scheme-y code,
```scheme
(define (calcpath paths streams)
    (if (empty? streams) (best paths)
        (calcpath (add (car streams) paths) (cdr streams))))
(calcpath '(empty-path) (sorted jetstreams))
```
Function signature defined, time to start coding a solution. Right away, I switch from recursion to for-loops because recursion is not efficient in Python. So, maintaining the loop invariance will be my job. The challenge is that streams in paths can overlap, so I can’t just discard a path after adding a stream to it. I have to keep both. And I have to keep paths where it’s not valid to add a particular stream to the path. An earlier version of `minimumpath()` went:
```python
def minimumpath(paths, position):
    return min((i for i in paths where i.isvalid(position)),key=lambda x: x.pathcost(position))
```
Then it occurs to me that I could prune the combinations immensely by keeping only the optimal path to add a stream, out of the possible paths, because the streams are sorted. I filter the paths into 2 sets in the beginning of the loop, and then simplify `minimumpath()`. Invariants maintained: `paths` has only paths of jetstreams where that’s the optimal path to add that jetstream, and each iteration is considering only a jetstream where every previous jetstream has already been added to an optimal path.

Then it’s just detail work. `finalminimum()` needs to return both the optimal path and the last distance, because the most efficient Path might not have the furthest jetstream. Immutable tuples are quick and easy. And there’s the issue of printing the solution and reading the file. Along the way, I discover that paths were returning much lower distances than they were supposed to, because a previous version of the Path constructor had:
```python
            self.cost = predecessor.cost + jetstream.cost
```
Quick fix, done, everything’s working, time to save, finally. Emacs allows me to be horribly lazy about saving. I would not be this lazy about saving in normal work.