We see this in our programming languages. Ruby on Rails, one of the most popular comets to cross the Web, is a thin veneer over a database. Specify a global variable and Rails creates a column for you because it knows it's all about building a table in a database.
Oh, and the big, big innovation that's coming 20 years into the game is the realization that we don't always need to fill up every column of the table. That's NoSQL for you. It may try to pretend to be something other than a table, but it's really a more enlightened table that accepts holes.
Developer hard truth No. 3: Users have minds of their own
You might think that the event listener you created for your program and labeled "save" has something to do with storing a copy of the program's state to disk. In reality, users will see it as a magic button that will fix all of the mistakes in their ruined document, or a chance to add to their 401(k), something to click to open up the heavens and lead to life eternal.
In other words, we might like to think we've created the perfect machine, but the users beat us every time. For every bulletproof design we create to eliminate the chance of failure, they come up with one combination of clicks to send the machine crashing without storing anything on disk. For every elegant design, they find a way to swipe or click everything into oblivion.
There are moments when users can be charming, but for the most part, they are quirky and unpredictable -- and can be very demanding. Programmers can try to guess how and where these peculiarities will arise when users are confronted with the end result of code, but they'll probably fail. Most users aren't programmers, and asking a programmer to think like the average user is like asking a cat to think like a dog.
This goes beyond simple cases of user stupidity. No matter how clever your invention or elegant your code, it still has to catch on. Predicting that users will not balk at a 140-character limit for expressing ire and desires is no easy business.
Developer hard truth No. 4: Most of what you code will never be used
Somehow it feels good to know that your new software can speak XML, CSV, and Aramaic. Excuse me; our implementation team would like to know if this can decode Mayan hieroglyphics because we might need that by the end of 2012. If it doesn't have that feature, we'll be OK, but it will be so much easier to get the purchase order signed if you could provide that. Thanks.
The users, of course, could care less. They want one button and even that one button can confuse them. The wonderful code you wrote to support the other N-1 buttons might get executed when the QA team comes through, but beyond that, there is no guarantee the sprints and all-nighters will have been anything more than busywork and bureaucracy.
Programmers don't even get the same boost as artists, who can always count on selling a few copies of their work to their parents and relatives. Our parents won't come through and run the extra code on the feature that just had to be implemented because someone in a brainstorm thought it would be a game changer.