At the same time, the general definition didn't pop up out of nowhere. I can't speak specifically for the history of monads, but very often these ideas start as

At the same time, the general definition didn't pop up out of nowhere. I can't speak specifically for the history of monads, but very often these ideas start as specific ideas with very practical intuition, and are then carefully generalized. If you tried to learn linear algebra by starting with the general definition of linear transformations on vectors in an abstract space, you'd get nowhere. You need a reference point in order to effectively generalize. For example, I first came to understand functors/applicatives/monads as contexts, so the idea of a list being a monad was actually kind of weird to me. The other problem with monads (in Haskell) is that it's sometimes far from obvious what a particular monad actually does. If I see code like this: thing1 >>= frobify It tells me basically nothing about what the computer will actually do, unless I have some familiarity with the types involved. You see similar issues with things like context managers in Python, and with languages that support operator overloading for user-defined types. The difference is that we all have some generally correct intuition about what "+" means, so when we see that operator is overloaded on a custom type, we can at least have an idea about what it might do. But a programmer who lacks concrete intuition about what monads do will not be able to perform the same reasoning when they see ">>=" or "join".