Not all programmers try to be heroes and cowboys throughout their whole careers. I am myself a programmer (25+ years doing it), and have known programmers my entire life. The distribution of certain personality traits is not better or worse in any given population.
Besides our 'lazy' and 'childish' ways, we also have to contend with business constraints and everything needs to be shipped for yesterday.
So although I do agree programmers should be more aware of the domain knowledge and be more 'client' oriented, it's also true that business stakeholders need to take the time and understand the impacts of their 'ship fast always' mentality. Too many times there is no counterweight to business decisions that lead to overwhelming technical debt, which is a great deservice to customers in long term business sense.
I said “far too many”. Although judging by the amount of crap software around, it’s certainly a lot.
“it's also true that business stakeholders need to take the time and understand the impacts of their 'ship fast always' mentality”
You’ll note where my original post points out programmers are not the only culprits at work. Learning is a two-way process. But developers are ostensibly the experts in turning requirements into solutions and what is needed to do that; so if users have utterly unrealistic expectations of what is/isn’t achievable then whose fault is that?
Often what users want is feedback: they want to know when they’ll be getting their solution, and be confident it does what they need. Both of these are engagement problems. That points to logistical shortcomings in the development cycle, particularly the siloing of parties and processes, which I know is a blight in which everyone is at fault.
But a lot of programmers would far rather wrangle code than wrangle users, even though user-wrangling is by far the more important of the two. So what does that say about these “solutions providers” and their ability to deliver?
Me, I’ve only been coding 20 years; professionally the last 10. My first programming job, I was one of two devs attached to the IT team out on the shop floor, working directly with users developing them quick-turnaround solutions to their immediate problems. In the 3 years I was there, I never once saw a developer from their 20+ Enterprise Applications department walk out of their glass cage onto the shop floor and spend some time talking to users about how they were getting on with their software and any problems they might be having.
Sure our code was small and simple, and theirs large and complex. But that’s all the more reason for them to engage closely and constantly with users, in order to avoid large and costly errors downstream that embarrass and frustrate everyone.
As I say, the problem is not in the code but in the people and their processes. Yet, no prizes for guessing where most programmers will try to solve it.
"Sure our code was small and simple, and theirs large and complex"
Having a complex piece of code, maybe with a lot of 'historical cruft' and legacy 3rd party modules? Business politics? Maybe a new manager wants his programming team to work on 'Shiny X' because that will make him/her look better with upper management?
Trust me, 95% of programmers (and most people for that matter) would rather feel like they are doing a valuable service and adding value to a product or service, than simply and lazily going through the motions of 'coding'.
Until you've walked a mile in some 'Enterprise application developer', or any one else I think it will be difficult for you to evaluate the global picture.
Although I understand you frustration and completely agree with the symptoms you mention, the cause is far more complex and difficult to grasp unfortunately.
Not all programmers try to be heroes and cowboys throughout their whole careers. I am myself a programmer (25+ years doing it), and have known programmers my entire life. The distribution of certain personality traits is not better or worse in any given population.
Besides our 'lazy' and 'childish' ways, we also have to contend with business constraints and everything needs to be shipped for yesterday.
So although I do agree programmers should be more aware of the domain knowledge and be more 'client' oriented, it's also true that business stakeholders need to take the time and understand the impacts of their 'ship fast always' mentality. Too many times there is no counterweight to business decisions that lead to overwhelming technical debt, which is a great deservice to customers in long term business sense.
It's never black or white.