The `do` block I showed is more like this:

    fn my_big_subroutine(ma: Option<isize>, mb: Option<isize>) -> Option<bool> {
        match (ma) {
            (Some(a)) => 
              match (mb) {
                (Some(b)) => Some(a > b),
                _ => None
              }
            (_) => None,
        }
    }

Which in this case is equivalent in this example, however I'm trying to stress the sequencing. Imagine `mb` had some very expensive computation in it, then it will remain an unevaluated thunk if we shortcircuit on `ma`.

> it’s clearer to me what the intent is. I’m not sure why the other syntax is so hard for me but it feels hard to understand for some reason.

We can write `myBigSubroutine` with case matching:

    case ma of
      Nothing -> Nothing
      Just a ->
        case mb of
          Nothing -> Nothing
          Just b -> Just (a > b)

In fact, the `do` notation version desugars to something equivalent to this snippet.

The motivation for using the `Monad` instance (and thus `do` notation), is that it allows us to be polymorphic over the effect described by `>>=` (and thus `do`).

This lets us have a customized version of sequencing computations specialized to whatever "effect" we need, not just casing on optional values.

This `do` syntax desugars to binds like:

    ma >>= \a -> mb >>= \b -> return (a > b)

We can then inline the definition of `>>=` and `return` to get:

    case ma of
      Nothing -> Nothing
      Just a ->
        case mb of
          Nothing -> Nothing
          Just b -> Just (a > b)

Imagine that `mb` is actually a really expensive computation that we don't want to perform unless `ma` returns a value. Sequencing our case statements in this way allows us to do that. `mb` will remain an unevaluated thunk until `ma` evaluates to a `Just a` value.