I suppose I understand the perspective of these engineers, though I don’t think their fear is of abstraction. It is a fear of improper abstraction, which is often the product of trying to create an abstraction before you even understand the problem; you know sit around and talk aimlessly for a couple of hours driven development. Good abstractions start very simple and evolve overtime to become useful mental models for a particular problem.
I’ve been wanting for awhile now to write a post about programmatic abstractions that would be very much along these lines. I think this is a really important insight that separates great abstractions that hold up over time from lousy ones that are fashionable for a season until people start to understand their limitations. Good abstractions start simply—often close to the minimal solution possible—and evolve over time in a way that is always informed by specific use cases encountered in the wild. Abstractions that start out as monolithic, seamless, end-all-be-all solutions tend to break down very quickly when exposed to anything but the textbook use cases their creators anticipated, whereas more humble efforts, judiciously managed, tend to grow more organically into true general purpose tools with real staying power.