> "...we are dealing with incomplete information while the device that runs your program does not care you have incomplete information and wants to screw you the first time you do something not right in the slightest."

Suppose you're becoming pretty comfortable with your skills in a foreign language and you've become pretty decent at speaking it. Occasionally you'll make a mistake---you'll pronounce a word incorrectly, misplace a verb, etc---and chances are the person you're speaking with will be able to figure out what you meant to say.

Unfortunately, computers don't work that way. If you're writing a function and your syntax is incorrect, the browser won't understand what you're trying to do.

>Unfortunately, computers don't work that way. If you're writing a function and your syntax is incorrect, the browser won't understand what you're trying to do.

Or worse, you and the computer have different understandings about what you're trying to do and it goes along quietly incorrectly for a while until that little mistake causes a problem somewhere else entirely because that one misunderstanding caused a cascade of misunderstandings that kept building up until it finally blew out everywhere all over your program and the quest to find where the problem started begins, well before the task of fixing the problem can start.

> But the problem is that they can't work really well with other developers (at a typical corp) who don't appreciate the problem the same way.

The key is to not work at a typical corp! :)

“I think the reason programming is difficult is that really we are dealing with incomplete information”

Dealing with uncertainty and incompleteness is a core part of the job.

The problem is that far too many programmers are gloryhounds and cowboys who think all that is beneath them; cramping their style when they’re trying to be the coding heroes.

This is compounded by many programmers being lazy incurious bums who have zero interest in doing anything that isn’t writing code. They don’t want to learn the user’s problem domain, so they don’t. Instead they demand users describe exactly how the software should work down to the very last detail; but if users could do that for themselves then they wouldn’t need programmers to write it for them!

Starting from ignorance, instead of writing software that encapsulates the users’ expert requirements, they write clever code that solves their own problems: entertaining themselves, and getting paid.

Writing code is not hard. Any monkey can do that. The challenge is knowing what code to write; and that’s made needlessly hard by programmers who can’t be arsed to understand their users, what they do and why they do it, learning their needs and problems in order to synthesize more effective solutions.

Instead of raising themselves up to users’ level of knowledge, they drag the problem down to their level of ignorance and whale on it with their crappy tools to give the illusion of “productivity”. Instead of being problem solvers, they’re problem multipliers.

Slap on several more layers of equally useless management, marketeers, beancounters, etc, and factor in that while deadweight accummulates expertise walks, and it’s no surprise most software projects are rolling Katamari disasters that makes everyone miserable until finally put out their misery; only for the whole process to start over again, with zero lessons learned.

--

TL;DR: Programming is hard because programmers make it hard. Because they don’t want to do the job right. Because they’re children.

> Programming is hard because programmers make it hard

This has been the MBA's wish/dream/hope for about a half-century now: “if only programming were easy and programmers didn’t take so long,” they think, “I could be making millions off of this business.” Since they want this to be true, they reason, it must be true. They then insist, in spite of mountains of evidence to the contrary, that programming is easy, and the entire industry of programmers - every single one, including the ones who were educated recently, including the ones from foreign countries - are conspiring against them to make it seem like it’s harder than it really is.

Also, MBAs assume then can hire anyone and then they complain the performance suffers.

The truth is, development is a high skill profession. It should take decades to master if we were really realistic about it.

So many generalizations in this paragraph.

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.

Where did I say “all”?

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.

I think there lies the misunderstanding:

"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.

If you're right (and I'm not sure that you are) then this seems to be a systemic, or at least cultural, problem. It's certainly not inherent to software; you're talking about individuals' attitudes. So how do we change that and inculcate values like being user-aware in people coming into the field? How do we get the other components of the business to support this?[0]

[0]:At my current job I'm completely insulated from users and I would really prefer not to be, but that's "the way it is".

Well, users who have perfect knowledge of their domain, of what they do and why, can't get arsed to learn to code and do it themselves when any monkey can do that.

It is almost like people have different domains of expertise because getting those skills takes time an effort, and specialists will always run circles around generalists in any non-trivial domain.