I've come to the same conclusion and wrote a series of posts on it a few months back:

http://zackarymorris.tumblr.com/post/10973087527/the-state-o...

I'm thinking that if you chop a program up into many small pieces, each part is simple enough that it can easily be solved by the compiler with something like genetic programming (or better yet, methods in languages like Prolog that already work for small problems).

So much of what we work on now is a waste of time (I'd say well over 90%), things like syntax errors, makefiles, DLL hell, code repo weirdness, managing web servers, concurrent programming, just on an on and on, that I gave up on working on real problems over a decade ago (the kind we learn in school in lisp/Matlab/Mathematica etc).

I would really like to write an entire program sometime as a big tree, that would be convertable back and forth to something simple like JSON. Then the compiler would go through and convert my simple statements like "when this sprite touches this sprite, give them opposite speeds) into the underlying code so I don't have to waste my time with it. I know we think that we work on more complex stuff than that, but I think if most programmers audit their time, they'll find that very little of it goes into the mathematics of solving problems (10%). I realize the logic may not be solved anytime soon, but maybe the minutia can be. If we don't obsess on finding the perfect algorithms, but allow ourselves a floor of say O( n^2 ), I think our productivity could go up substantially.

Maybe it's time for a bunch of geeks like us to be willing to unlearn what we have learned, basically scrap everything, and try working backwards from what the solution will look like (what people will be using in a few decades).