It’s called “self documenting code” and the way you self document code it is by taking all your comments and make them into functions, named after your would-be comment.

I’m not a fan either.

Everything must be done to taste. I think code can be made "self-documenting" without going overboard and doing silly things.

This can be done in a good way and in bad ways. With most code you will be calling builtin procedures/functions. You also don't look under the hood for those usually. But for the code of your coworker it seems to irritate you. This could mean many things. Just to name a few: (1) The names are not giving a good idea what those functions do. (2) The level of abstraction is not the same inside the calling function, so that you feel the need to check the implementation detail of those small functions. (3) You don't trust the implementation of those smaller functions. (4) The separated out functions could be not worth separating out and being given names, because what the code in them does is clear enough without them being separated out. (n) or some other reason.

The issue does not have to be that those things are split out into separate small functions. The issue might be something else.

Sometimes it's easier to define some vocabulary and then use it. Like defining push and pop on a stack vs stack[++ix] = blah and blah = stack[ix--].

And avoids needing to think about it being prefix or postfix after you don't that one time.

But at other times it's insufferable, when the abstraction is leaky and unintuitive.