I'm not, not at all. I'm just pointing out that programmers are people who learn to, and like to, delve into the details. Architecture is fun, but it's a tiny part of the job, ultimately.
The biggest part of a programming job is pinning down the details of your requirements.
Pinning down the details of your requirements is _exactly_ the act of choosing the correct level of abstraction. When picking out what matters for correct behavior, and what doesn't, you are defining an abstraction.
Sure, but abstraction is not in any way the same thing as architecture (which is what you were talking about), and it's not structure (which Bartosz Milewski was talking about).
And besides, Category Theory is mostly concerned with finding similarities between different mathematical objects, when you look at them abstractly and ignore some details. It helps you find that numbers with adding are homomorphic to functions with composition. But programming is about telling a computer how to actually add 156 with 1571 by adding bit to bit, and how to compute the composition of two functions by computing the result of the first and putting it in a register so the second one can take it as input, which CT doesn't concern itself and no category theorist cares about in the slightest.
> programming is about telling a computer how to actually add 156 with 1571 by adding bit to bit
programming can also be about producing generic solutions that commit to some minimal set of assumptions so that solutions work across a variety of contexts, e.g. regardless of whether your data is floats or ints.
sometimes good engineering is about finding decisions you can avoid making or thinking about. Sometimes you have to decide how to add the numbers bit by bit, but for that particular example, it's even better to not care about how the numbers are added up (which is a detail of the CPU or a bignum library or whatever).
The biggest part of a programming job is pinning down the details of your requirements.