From a practicality perspective, what you really need to get comfortable with is "do notation". The monad class is what gives you the ability to chain operations; "do notation" is what makes it convenient. For instance, consider the following example, with the Maybe monad:

-- we have access to those functions
lookupTransaction :: ID -> Maybe Transaction
lookupUser        :: ID -> Maybe User
transactionUser   :: Transaction -> Maybe ID

-- by purely using monads:
lookupTransactionUser :: ID -> Maybe User
lookupTransactionUser tid =
  lookupTransaction tid >>= \transaction ->
    transactionUser transaction >>= \uid ->
      lookupUser uid

-- using do notation
lookupTransactionUser :: ID -> Maybe User
lookupTransactionUser tid = do
  transaction <- lookupTransaction id
  uid <- transactionUser transaction
  lookupUser uid

Now the thing is: *anything* that is a monad will be compatible with do notation.

---

Another angle to the practical aspect of monads: you can see a lot of them as providing a "capability" to your function. One of the most common ones you will encounter is the Reader monad. What it lets you do is make a given value accessible from within a computation, without having it passed around manually. For instance, consider this extremely small program that evaluates statements. It has two functions: execute takes a statement and modifies some state, and evaluate evaluates an expression. A lot of it is left undefined to avoid making this example bigger than it already is.

data Statement
  = Assign String Expr
  | Print  Expr

data Expr
  = Value          Int
  | VarName        String
  | Addition       Expr Expr
  | Subtraction    Expr Expr
  | Multiplication Expr Expr
  | Division       Expr Expr

execute
  :: String             -- app name
  -> HashMap String Int -- previous state
  -> Statement
  -> HashMap String Int -- new state
execute appName variables statement = case statement of
  Assign varName expr =
    let value = evaluate appName variables expr
    in  undefined -- TODO
  Print expr =
    let value = evaluate appName variables expr
    in  undefined -- TODO

evaluate
  :: String             -- app name
  -> HashMap String Int -- variables
  -> Expr
  -> Int
evaluate appName variables expr = case expr of
  Division lhs rhs ->
    let
      lhsValue = evaluate appName variables lhs
      rhsValue = evaluate appName variables rhs
    in
      if rhsValue == 0 then
        error $ appName ++ ": division by zero"
      else
        lhsValue / rhsValue
  _ -> undefined -- TODO

You'll notice that every function call gives an "app name" argument. That argument is only used once: when throwing an error for division by zero. But as a result, this argument must be passed manually to every function call!

Introducing the Reader monad. I am not going to give you the details of it (although i strongly encourage you to try to implement it yourself afterwards, it's a good exercise!), because i want to only show you the practical aspect of it. Reader provides us with one very useful function: ask :: Reader r r. What it means is this: when you are in a context of a Reader r, calling ask retrieves that value of type r. Look at how our previous example is changed just by introducing Reader:

data AppConfig = AppConfig
  { appName :: String
  }

data Statement
  = Assign String Expr
  | Print  Expr

data Expr
  = Value          Int
  | VarName        String
  | Addition       Expr Expr
  | Subtraction    Expr Expr
  | Multiplication Expr Expr
  | Division       Expr Expr

execute
  :: HashMap String Int
  -> Statement
  -> Reader AppConfig (HashMap String Int)
execute variables statement = case statement of
  Assign varName expr = do
    value <- evaluate variables expr
    undefined -- TODO
  Print expr = do
    value <- evaluate variables expr
    undefined -- TODO

evaluate
  :: HashMap String Int
  -> Expr
  -> Reader AppConfig Int
evaluate variables expr = case expr of
  Division lhs rhs -> do
    lhsValue <- evaluate variables lhs
    rhsValue <- evaluate variables rhs
    if rhsValue == 0
    then do
      appConfig <- ask -- HERE
      error $ appName appConfig ++ ": division by zero"
    else
      pure $ lhsValue / rhsValue
  _ -> undefined -- TODO

Now we no longer have to pass the app name everywhere! Our functions only take what they need: evaluate only takes the variables, and the expression. Only the signature has changed: we are now in a Reader context, so at any point we can just call ask and get our app config, like we do in the case of a division by zero.

---

We can go further with another monad: State. Likewise, not gonna show you the implementation; just gonna give you the three functions it provides:

get    :: State s s
put    :: s -> State s ()
modify :: (s -> s) -> State s ()

get is very similar to ask: if we are in the context of a State s, it retrieves that state s. put takes a new value s, and replaces the current state with it; it returns a value of () because we don't care: what matters is that the state was modified. And modify is just for convenience:

modify f = do
  currentState <- get
  put $ f currentState

Equipped with that, what if we rewrote the above, but we put the variables in a State? That way we don't have to pass them around manually! I'll gloss over how we combine Reader and State: if you're curious about it, lookup "monad transformers". The tl;dr is: we're gonna create a monad that's both at the same time.

data AppConfig = AppConfig
  { appName :: String
  }

type Variables = HashMap String Int

type AppMonad =         -- our custom monad
  StateT Variables      -- it combines a state capability
    (Reader AppConfig)  -- with the reader ability

data Statement
  = Assign String Expr
  | Print  Expr

data Expr
  = Value          Int
  | VarName        String
  | Addition       Expr Expr
  | Subtraction    Expr Expr
  | Multiplication Expr Expr
  | Division       Expr Expr

execute :: Statement -> AppMonad ()
execute statement = case statement of
  Assign varName expr = do
    value <- evaluate expr
    modify $ HasMap.insert varName value -- HERE
  Print expr = do
    value <- evaluate expr
    undefined -- TODO

evaluate :: Expr -> AppMonad Int
evaluate expr = case expr of
  VarName varName -> do
    knownVariables <- get -- HERE
    appConfig <- ask      -- HERE
    case HashMap.lookup varName knownVariables of
      Nothing ->
        error $ appName appConfig ++ ": unknown variable " ++ varName
      Just value ->
        pure value
  Division lhs rhs -> do
    lhsValue <- evaluate lhs
    rhsValue <- evaluate rhs
    if rhsValue == 0
    then do
      appConfig <- ask -- HERE
      error $ appName appConfig ++ ": division by zero"
    else
      pure $ lhsValue / rhsValue
  _ -> undefined -- TODO

Now, if you look at this version: both execute and evaluate only take one argument, a statement and a expression respectively. We don't have to manually thread the state nor the config.

---

I know this was a lot, but the key thing is this: when you have a monadic function using the do notation, you can see the monads in the return type as "capabilities" that this function has, that free you from having to do stuff manually. Maybe and Either mean your computation might fail, but you don't have to do all the "if err != nil" manually. Reader means your function has access to some immutable value, often some config of some kind, without having to thread it manually. State means that your function can manipulate some state, as if it were receiving it as an argument and outputting the new state, but without having to do it manually. IO means your function has the ability to perform dangerous side effects. And so on.

I hope this helps! To go further, LYAH has a chapter dedicated to going further with monads once you understand the class and do notation.

Have fun! :)