BTW, I think you’ve misinterpreted “don’t know what they’re doing”†. I’m not talking about code, I’m talking about the business domain. (I thought it obvious from context, but clearly not.) And yes, a depressingly large number of working programmers today have zero interest in learning anything except how to write more code. But how can you write code that solves a user’s problem if you refuse to learn what that problem is and how it was arrived at?

And then you blame the users for “not speccing the job right” when they discover your “solution” not only fails to make their lives any better but often makes it even worse. I’ve worked a decade professionally as a user-turned-developer, so please don’t say this attitude isn’t cultural right down to the bone. I’ve seen it, I’ve dealt with it, I’ve walked out because of it. And looking around me that seems pretty much par for the course.

This is why I like a philosophy of reshaping your stock language into something that much better expresses the business concepts and processes you’re dealing with, then writing your solution in that. It forces you to learn the user’s job before you get underway, because you can’t fake understanding: your new “business language” either does the job or it sucks.

Building up that vocabulary is the first test of whether or not you understand what you’re doing; and until it proves you do you’ve no business proceeding or you’re just wasting everyone’s time (including your own), and giving this industry an even worse reputation for shafting the customer by giving them shit than it already possesses.

--

† Ironically for exactly the reasons I’m talking about: you’re unable to see anything that isn’t about coding. But the code is the least significant part of the overall puzzle; and until you understand the puzzle in its entirety you’re not fit to solve any of it.

TL;DR: I may be nuts, but I ain’t what’s broken.