When I encounter some of my own past work when I thought I was being "clever", sometimes that's how I feel about my own past work. It's a always a reminder to me that I should avoid trying to be too clever.
Since then I’ve realized that our brains are like lenses; learning to code re-wires your brain to read code, which is different than other types of data, similar to the way that reading a book is a different interface than examining a room; just as we may choose to read certain authors or subjects, or may not think of the same things when examining a room, we may choose to see code in styles or certain languages, or may consider value in clarity of code or in its function.
I value clarity, but upon considering the room again, the first dimension is function, next clarity. This doesn’t subdue clarity to a trivial role, but clarity is a third order to maintainability, which is second order to executability.
Over time, those lenses may not be as agile as before, though we expect them to be. Text is blurred, and we may struggle to hold the glasses at a distance to read a certain part of the code clearly. It no longer makes sense, and that which employs us sees other value.
You need that higher-level clarity in code so that you can still work with abstractions and not have to dive into every function at a code-level, but when working inside a function or a deeply technical area, it's reasonable to expect a developer to spend some time reading the code and coming up with a mental execution model, which is purest when it comes directly from the code in the form that works, and makes sense to the people who actively need to maintain it.
hell, you could just rapidly type random stuff and it looks like it comes out as proper code.