We deal in the abstract; it's in the job description. Think about the word "code" for a while.
Runaway abstraction is an occupational hazard. You can find lists of software design principles, and coding principles, laws, rules, etc., that are all aimed at giving programmers heuristics for writing "better code." As an occupational programmer, it is really really easy to start to believe in these heuristics.
But hey, sometimes a scripting language is the right tool for the job.
Sometimes there is no clear line between code and data.
Sometimes a hack is the right answer.
Sometimes an abstraction layer is a mistake, and sometimes it's a critical improvement.
In doing code reviews, especially for external teams / contractors, I'm in a curious position where I may choose to impose my heuristics on other people's code.
Each defect I log is a minor crisis of conscience, where I pass judgement, create work, and reject another professional's opinion. So I must weigh that cost against my belief that I am driving them to "better code."
The decisions are necessary and I make them quickly, most of the time. It's an interesting journey.