[huntleydavis]

From years of schooling and artificially constructed engineering problems we've gotten used to, for some addicted to, the idea of end solutions fitting neatly into a clean edged box. We've grown up on complex physics problem with a clean integer solution, homes with clean lines and polished finishes, and engineering that's constantly pushing for smaller and faster solutions. So, naturally we want our code bases to reflect our experiences : concise, clever, code that feels like a clean integer solution. And while maybe it should be a common aspiration to write code that's 'clean, the reality of the natural world is that solutions to some of the most complex problems are not 'clean'. Furthermore, rarely is the true end goal of the code you're writing to be the 'final state' of logic. The code that we write is almost always for ever evolving and expanding use-cases; we are creating scaffolding rarely a 'finished' product. Furthermore, most of us are writing code in ever evolving languages so even 'finished' state code will ultimately be paved over with something more concise and efficient as the language evolves. The point being : there's a happy medium ( I haven't mastered it ) of reconciling with the realities of complex evolving solutions and our internal desire for clean elegance in our codebases.