It sounds like category theory likely has no direct impact on your life. So you can move on.

But please do not let this bleed into a criticism of category theory as used in mathematics. Category theory from the very beginning was developed to help manage the complexity of modern mathematical fields like algebraic topology. It was then famously used by Grothendieck in algebraic geometry where some of the basic notions (schemes) were defined in terms of category theoretic concepts (functors). It's been applied to many other fields, since, including yes computer science, and mainly for the same purpose: giving precise terminology to common patterns (monads functors etc) and giving us the right concepts to design new functional programming languages. As someone who is an expert on these topics I find some of the popular sentiments about programmers using category theory to be a bit silly, but I'll admit it's overall probably good for my field because it cultivates a lot of interest in students. It probably plays a similar role to pop science/math in other fields: not very deep but fun and can be a gateway to "the real thing".

The popular perception of category theory is a bit bizarre to me though. It is a beautiful theory with many useful results. But you don't see the same excitement or resentment towards fields like order theory or abstract algebra, which are very closely related to, and just as abstract as, category theory and are used in similar ways.

So I come at this from a mathematical background --- graduate student in categorical algebra --- but I've done a couple years of SWE work, so I'm not unsympathetic to this point of view. The way I see it, when you want to reason about things like data processing (which is what a massive chunk of writing software is, moving data from form A to form B), category theory provides what is in some sense the "correct" language/framework in which to think. It's not just an abstraction circle-jerk, it's a genuinely useful perspective, particularly for guiding your mind to spot non-obvious connections between pieces of code.

The problem as I view it is that CT is first and foremost a discipline of maths. It was developed to help mathematicians, is very sophisticated, and very specialised; learning CT for SWE is taking a sledgehammer to a nut. I can't honestly recommend it as a field of study to someone who isn't interested in the problems it was developed to solve. If you don't have a solid grounding in set theory, logic, algebra, topology, etc., it's a very tough field to motivate. The vast majority of CT is of little to no relevance for SWE work. Adjunctions, for example, are absolutely fundamental to all of maths, but in truth are not really relevant for SWEs. As a result, you see people trying to teach concepts like monads without reference to them; this is slightly insane from where I'm standing...

Your question about whether there are things CT does that other branches didn't already do; one of the fundamental utilities of CT in pure mathematics is "making trivial things trivially trivial". That is to say, it makes it very clear which parts of your problem are local to your specific situation, and which are purely "structural" from the categorical constraints. The SWE analogy would be separating business logic from other layers. So at least for mathematicians, it absolutely does have novel utility, and has drawn links between a huge number of disparate studies that were not well-understood previously.

So if you _do_ care about posets and groups and cohomology theories, CT will genuinely open your eyes, and (albeit, this coming from someone with less working experience than yourself) it could give you a deeper, or at least different understanding of the code you're writing. Otherwise, I'm not sure it's worth putting yourself through it, tbqh.

(If you do decide to give it another go, please use a better resource than the linked post; after a quick scan it looks pretty weak)

Category theory has virtually zero application to software engineering. Abstract algebra (knowing what a group, monoid, etc. are) has a bit more practical application. Knowing what a monad is (in the programming sense) has some as well. Neither of the latter two require learning category theory.

If you have a symmetric system, you can use group theory to make predictions about it. Similarly, if you have a compositional system, you can use category theory to make predictions about it. As for whether those predictions are useful, or non-obvious, or worth it, etc, tends to very a lot depending on the application, and the other techniques available- it's not a matter of being smart enough to get it. FWIW, I think category theory is certainly indispensable in denotational programming language semantics.

I can't answer your question in terms of pragmatic applications. Based on skimming this book and similar resources posted on HN, my -- naive, I am sure -- understanding is that category theory unifies other theories and serves as a glue.

One example from the linked book, "Remember that we said that programming types (classes) are somewhat similar to sets, and programming methods are somewhat similar to functions between sets, but they are not exactly identical? A formal connection between the two can be made via category theory."

>Working as a SWE for lots of years, I've worked with people that always feel the need to "add a level of abstraction" or "build a framework" for (and out of) everything.

You might be interested to read Spolsky's essay on 'architecture astronauts': https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

> Every time I try to learn about Category Theory, I get to a certain point and just start wondering "why?"

> I can't tell if I'm not smart enough to get it (I think that's the most likely answer). But it feels like some math people -- who have nothing better to do -- are just trying to create another level of abstraction.

> Are there things that Category Theory does that other branches couldn't already do? I'm curious to hear other takes on this.

No, category theory was not created for the sake of an another level of abstraction. It was created to talk about algebraic topology. I am not sure if you gain anything studying that. Probably you won't but who knows. (But I am thinking more and more that CT advocates are harmful, they trick people to dive into CT which just steals their time, and gives them nothing.)

> I've worked with people that always feel the need to "add a level of abstraction" or "build a framework" for (and out of) everything

This is my experience with the Java folk, and they're certainly not being inspired by category theory.

Indirection isn't abstraction. What I usually come across is someone wanting to make a REST POST, but they wrap it in a networkconnection in a networkclient in a networkworker in networkmanager, which can only be instantiated by a network factory.

CT-thinking (not that I've studied any) is more like: a POST is an arrow from request to response. Can we join such items head-to-tail? Is it ok to substitute createUser.then(createPassword()) for createUserAndPassword? Can we map over the arrow without unpacking it and repacking it, etc.

Have a read of https://www.haskellforall.com/2014/04/scalable-program-archi...

You haven’t taken the time to understand it, therefore it must be useless. Others who practice it must be doing useless things. This seems like a common solipsism among software developers.

The problem with your definition of abstraction is that you’re thinking of indirection.

Abstractions in mathematics create precise definitions with provable laws. When you have a proof of a theorem you can ignore the details underneath and think in terms of the abstraction.

I wouldn’t be so cavalier about dismissing category theory. It’s interesting for many reasons but it’s not here to serve you. You could find ways that it can improve your programs and how you think about them, as others have, or you can get on without it. And that’s fine too!

Abstraction is powerful. It lets you control more with less. As you keep abstracting things get complicated. Category Theory studies abstractions and lets you build extremely abstract systems, which can be leveraged to create reliable and also flexible systems. The downside is of course the learning curve, and because of this it isn't as friendly for business and teams to use. In an ideal tech industry (in my opinion), engineers are encouraged to persue the most complicated engineering, despite the rest of the company having very little idea of how it works. It would require a lot of trust, and also a different work ethic, but I digress.