The more I do stats in the workplace setting (esp. PCA on the one hand, and time series models on the other) the more I think that statistics are just a way for you to zoom in on areas of interest in your data.
The closer I could get category theory in the workplace, the happier I would be. Or have been. My 2 cents on the matter is that when you work with data, rather than with sets that are placeholders for containing data, the more your questions or answers would be concrete and eventually have very straightforward solutions, or at least straightforward deliverables. In terms of the programming view I would say that this means that any abstract solution would have a counterpart concrete version or versions. The reason for abstraction should be to decrease the time involved with solving something.
Abstractions are meant to reason about things that you want to be broad enough to include suppositions. The whole of mathematics is studying which statements follow from which axiom statements. Once you settle on the data, it becomes less of a mathematics exercise and instead is a coding exercise to find the peculiarities of the concrete example, and then the need for abstraction becomes less.
Abstraction gives me a lot of joy; but, you could instead do mathematics by enumerating all combinations of symbols and checking whether some are valid proofs of theorems. Programming will always have some context, often the context means peculiar data and hence you can solve the problem without any abstractions at all. However, the larger the data, the more difficult, and eventually concrete approaches become unfeasible. Again, one can think about this as enumerating solutions. If you had all the time in the world, you could just enumerate all programs, especially more concrete ones, and just pick the one with the right output for the input domain.
If you build a wooden table, you can get by with a small, ordinary toolbox. If you want to build a skyscraper, I think you could get by with a small toolbox, but it may take you an interminable amount of time. And moreover, without the abstraction of a large crane-like device of sorts, the design of building a skyscraper with a ordinary workman's toolbox becomes much more difficult, if not impossible. The design of a crane to me is an example of the right depth of abstraction.
I am not sure whether my analogy is clear, but my point is simply that abstraction is increasing the plausible data space and concretisation is selecting from possibilities. Another way to think about it: {{car, bike, plane},{spoon, knife, fork}, ...} abstract to, but specialise from {{vehicles}, {cutlery}, ...}.
You want some kind of balance in this thought process that fits the code base you are building or maintaining, or the problems or questions that you are solving.