So refreshing to see this kind of wisdom in a concise blog post! My take: In beginners, over-emphasis on DRY is a mistake made because they don't yet understa

So refreshing to see this kind of wisdom in a concise blog post! My take: In beginners, over-emphasis on DRY is a mistake made because they don't yet understand why DRY is considered a best practice. In more senior developers, over-emphasis on DRY comes from a few psychological desires... 1) to mitigate the uneasy feeling of not knowing what direction the product will take, and 2) the warm feeling that comes from finding a refactor that makes the code more DRY. What is overlooked is the cognitive overhead required to un-DRY pieces of code when requirements change. Often the result is a DRY but convoluted series of refactors that obscure the intention of the code and (often) obscure system design intention that would otherwise have been quite clear. Sadly, many otherwise talented software engineers have the kind of minds that prefer micro-level problem solving and are challenged at big-picture reasoning. There is often actual discomfort when too much big-picture reasoning or synthesis is involved. I view this as more of an emotional than a cognitive limitation, and something that is amplified by the conformist culture found in most large organizations (and which many small ones believe it is best to emulate). Conformity with best practices is valued above real problem solving. Worse still, there are often elaborate discussions of PRs relating to minutia associated with DRYing up code for which it wasn't necessary in the first place. Sure, as a system matures there are opportunities to remove cruft and DRY code where it is obviously helpful, but it is silly to waste too much time on it until the true requirements of the system are well understood.