Before you try to understand what they are, try to understand why they are important and why each type of monad you come across is important, starting with the Maybe monad, which I think is one of the most obvious.

Someone smarter than me feel free to correct me, but my experience has been that every monad I've learned seeks to take a particular imperative or procedural programming idiom, which itself may pop up in several different styles, and "standardizes" how that programming problem is handled by putting it in a special typeclass. This "standardization" is a huge source of power since how the problem is handled becomes predictable, less likely to contain bugs and generally leads to a more composable code.

Take the Maybe monad for example. I'm sure that as you've programming you've found yourself constantly checking for an undefined or null argument/parameter value at the beginning of a function. Sometimes people just return false, null or undefined. Other people return errors. Some throw exceptions. The Maybe monad gives you a typeclass that allows some data to be Just the value you want or nothing. Since you have a standard way of having something be undefined and it's encoded in the datatype itself, you never really have to handle undefined values in other functions. Why? Because these other functions that work with the Maybe monad don't really operate on the value directly. Instead they operate on the value via the Maybe monad's fmap function.

Check out this post for a good explanation of some monads:

http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...

This too:

http://adit.io/posts/2013-06-10-three-useful-monads.html

From now on, whenever you see a new monad, ask yourself what generalizable programming problem or idiom it is trying to encapsulate and why it's important to solve that programming problem. With the case of the Maybe monad I mentioned above, you can read up on a lot of the literature out there explaining why the invention of null was a terrible. C.A.R. Hoare calls it his billion dollar mistake.

If you don't understand the problem being solved, understanding the abstraction presented by a particular monad is going to be a lot harder.

A monad is just a monoid in the category of endofunctors, what's the problem?

I've forseen this answer.

Personally I like this tutorial by douglas crockford

http://www.yuiblog.com/blog/2012/12/13/yuiconf-2012-talk-dou...

Douglas Crockford gives an incorrect definition of a monad and confuses them with functors. If you learned about monads from Crockford, you didn't learn about them.

Brian Beckman's explanation might help shed some light on the concept: http://www.youtube.com/watch?v=ZhuHCtR3xq8

http://blog.plover.com/prog/burritos.html helped me.

That was brilliant, there's also a cartoon: http://chrisdone.com/posts/monads-are-burritos

I like how this question appears here and on another resources at least once a month on average.

I'd also really like to see a good intro. The answers so far have not helped me.

I'm excited you're starting a journey. Make sure to pack ibuprofen.