didn't read all that stuff, busy getting stuff done.
I agree with this. When I end up on a new project and I'm not the lead, and there is a lead who is pedantic regarding how they want their URLs crafted (or wants to implement a complicated query pattern, or introduce an extra layer of objects to satisfy an abstract notion of purity), I'll just go with the flow. Accidental complexity, pattern seeking and cargo-culting are personality traits of many programmers, and I've come to the conclusion that its best to accept this, and get on with the job of actually delivering value.
The problem becomes evident when you return to the results so the flow a year later to change something, and wish you were more mindful when getting things done.
Cargo cults are not good. Finding and adhering to regular patters that logically underlie what you do saves time and mental effort, while also preventing certain classes of errors. (No, these are not GoF design patterns.)
I’m certainly not advocating spaghetti code, balls of mud, or a thoughtless lack of architecture. What I’m specifically referring to is wilful anti-pragmatism that betrays a sort of insecurity...it’s hard to define but easier to recognize.
Finding the balance between pointless over-engineering and rigidity on one hand, and good software design on the other, consistently, is what seems to distinguish great programmers I’ve worked with, from those who are “just” very good.
But, like I said, it often isn’t worth the trouble fighting about these things, even when we see them, and getting on with the job is more important than ensnaring oneself in religious debates on projects.
me: already groaning at the thought of fixing stuff after that one who didn't "read all that stuff," the "left", and thankfully the right was too busy pontificating to do anything so there's no fixing to be done.
left: it gets stuff done because it's smarter
right: it's bad for you, it's actually getting less done
middle: didn't read all that stuff, busy getting stuff done.