Honestly, this is a waste of time and is not going to help as much as the author thinks it is. There is no secret from category theory that will make one's design 10x better. Not everything is even applicable.
>I hope that category theory will allow me to formalize my intuitive understanding of abstraction, put words to it, and use those words (or, better, words others have written) to explain my thinking.
Note how this goal doesn't include anything about improving the author's software engineering ability. The goal is to be able to use category theory to describe existing concepts. Why not us just describe it in ways that 99% of software engineers already understand? Why not learn good software design directly instead of through a subset of category theory which you have to translate?
author here, the way I see it is that nothing about my software per se will change. I do indeed like to write things in a "plain" fashion instead of littering my code with high-level constructs that only a few people understand.
However, it is "generative" knowledge. Having a good intuition for monads is what allows me to break down a fair amount of the mundane tasks I have to do (say, breaking down and migrating infrastructure configuration) in steps that work and stand the test of time. That's the thing about say, monad. An applied monad just looks utterly trivial, because, really, they are. If they weren't they wouldn't be worth using.
It also allows me to mine the literature or reuse things I've worked out in the past, for example exploiting monoidal structure for optimizing computation by leveraging associativity, for example.
Also, this is very much what works for me. I love to think in "structure" and patterns, and category theory diagrams and the way concepts are formulated brings me "joy", if that makes sense. It resonates with my cognition in the way say, common lisp, does, and that makes it quite fun and enjoyable.
>It also allows me to mine the literature or reuse things I've worked out in the past, for example exploiting monoidal structure for optimizing computation by leveraging associativity, for example.
This is an algebraic concept and it is possible to learn this idea directly in a software engineering context than a mathematical one.
This is a bit unfair. The author never claimed it would make them a 10x engineer.
Learning almost anything is useful in some capacity. Is everything you learn equally important? Maybe, maybe not, but you never know in advance how things might end up useful.
Of all the things one can study, math seems to be a pretty safe bet in terms of ROI.
From reading the article he justified his motivation of learning category theory to help him learn how to express himself better. I feel he is looking for some knowledge he is missing from category theory.
I am not against learning category theory because you find it interesting, but one should be honest that it isn't going to benefit ones software engineering ability at least compared to studying good design directly.
>math seems to be a pretty safe bet in terms of ROI.
Ask most people how much math they have used of which they learned it university or high school. There are niches of math that are useful to niches. Study the wrong niche of math when you are in the wrong niche that doesn't use it, it will be a poor investment.
I feel that learning about concepts from category theory is... studying good design. I wouldn't know how to measure my software engineering ability anyway, but I do think I do write better software with that knowledge.
Understanding and learning to identify more and more monads was a big threshold for me. I never write "monad" in my code, because that's not I apply this knowledge. It's knowing how to write say, an interrupt handler, so that it will compose cleanly with 3 more interrupt handlers, or in such a way that I can easily simulate my embedded system with 5 lines of javascript.
>I hope that category theory will allow me to formalize my intuitive understanding of abstraction, put words to it, and use those words (or, better, words others have written) to explain my thinking.
Note how this goal doesn't include anything about improving the author's software engineering ability. The goal is to be able to use category theory to describe existing concepts. Why not us just describe it in ways that 99% of software engineers already understand? Why not learn good software design directly instead of through a subset of category theory which you have to translate?