As someone who used to use Haskell a lot, I will tell you that learning category theory isn't really going to improve your practical ability to architect Haskell code.

If you're simply curious about the mathematical structures that Haskell's standard typeclasses are named after, then by all means learn category theory.

But if you're trying to improve your ability to use those typeclasses to write real-world software, I recommend "Haskell From First Principles" and/or "Effective Haskell". And get your hands dirty writing actual programs - practice makes perfect.

This is not strictly (purely?) category theory, but two fun little projects that will teach you a lot (or reinforce what you already know) are writing your own parser combinator library (https://www.cs.nott.ac.uk/~pszgmh/pearl.pdf) and Lens library (https://en.m.wikibooks.org/wiki/Haskell/Lenses_and_functiona...).

these kind of books are "philosophical" books. In the sense that the usage can be written/explained in other ways. For instance, monads are just a way to see that if you compose two ducks you still have ducks that behave in the same manner, but that's almost the same thing as having a class and define the composition arrow as a method.

The only difference is that with CAT you have theorems asserting what's true and what's not, with classes I don't think there's much literature. A similar reasoning can be applied to neural networks as there are very different POV: someone will look at them as ODE systems, other as a pure discrete dynamical system or as an optimization problem or whatnot.

I've used it to optimize SQL. The principles I used in SQL can be used in other places as well.

I think functors are easier to understand and more fundamental to category theory and programming than monads.

The idea of sharing structural properties/invariants between abstractions is something that is in my mind often, and reading the book intro resonates with me.

Domain Driven Design is essentially applied category theory:

You develop a language that models your domain, translate that into a diagram, and translate that diagram into code.

(Okay, actually topos theory since you’re going between type theories and diagrams — but you use the diagrams to move between type theories and define “equivalent structure”.)

We use it for data integration https://www.categoricaldata.net