I usually explain that programming is creative problem solving. You have a problem - you want a feature in a product (and I usually pick a well known product, Amazon.com, MS Word, etc), and it's not there. It's never been done before, and you are the first, so this is like any art project - you have a vision, but you need to figure out a path.
I also focus on the fact that there's more than one way to solve the problem, a bunch of really bad ways, and probably more than one good way. In the long run there might be a best way, but that best way won't be obvious for a long time (extensibility, re-usability, etc), so at the time of development, there's a lot of important judgment calls.
Finally, the end product may be loved or hated by the recipient. Just like some people love Picasso and some can't make heads or tails of modern art - some people may love a feature, and some may hate it. You do the best you can for the most people, and figure you can't please everyone.
- unknown territory
- no one answer
- subject to interpretation
Shows that this work is a lot more like art, and a lot less like repetitive boring work.
I talk this over with artists quite frequently (and they seem to have an instinctive belief that computer work is uncreative. Usually I also can manage to relate it to the artist's favorite form of art. At some level, most artists are also technicians - painting, dancing, making music and probably any other art - all involve a series of repetitive activities that bring you to the point of execution of something new, different and creative. Put this way, the artists generally have problems denying that seemingly repetitive activities can lead to works of inspiration and beauty.
At that point, they are usually willing to admit that just because my "art" involves a set of bizarre looking syntax statements and bland-looking UML diagrams, it doesn't mean that it isn't creative in that those lines of code and models of the system eventually make something quite different than the sum of its parts.