I found this blog post low on insight and thoughtfulness. I've worked with engineers in the past who had an inflated esteem not just of their own abilities but

I found this blog post low on insight and thoughtfulness. I've worked with engineers in the past who had an inflated esteem not just of their own abilities but of the nature of the business domain they were ostensibly building solutions inside. I have found that in many cases, there's a level of naievete commingled with arrogance that comes from never having worked with an intrinsically complex enough problem to understand the true cost of abstraction, which is always nonzero. Now, it is the case that there are many cases where the cost of abstraction is low enough to not be ROI negative. But there are many cases otherwise. Other commentators here have done a great job of detailing that space -- that incidental and actual repetition vary, that abstractions should exist to reduce optionality and ease of reasoning rather than simply reducing code, and those are all correct. But at a very basic level, all of those observations reflect the most critical missing factor from this post, which is context. No software is created or operated in a vacuum. Every piece of software is created by humans to solve problems for themselves or other humans. So every piece of downstream of the working process of those humans. Given that these working processes are subject to change and evolution, changes in requirements aren't edge cases but table stakes. This means that often the cost of an abstraction is not just whether it's the wrong abstraction at a point of time, but also whether it's an abstraction that is likely to erode over time given a particular working process. With that said, a lot of this post seems like an exposition of this central point: ``` If I were to see a confusing piece of code littered with conditional logic, I wouldn’t see it and think “oh, there’s an incorrect abstraction”, I would just think, “oh, there’s a piece of crappy code”. It’s neither an abstraction nor wrong, it’s just bad code. ``` I've seen this dismissal from many engineers over my career, and in every case, without fail, it reflected an inability to deeply read and understand the code, its history, and likely its future. To all the engineers out there reading this: thinking like this will prevent you from maturing from a junior engineer to a mid level engineer, never mind a mid level engineer to a senior engineer or engineering leader. You've been forewarned.