Magicians of Code

In general, software developers are expected to be magicians - miracle workers, at the least. I say this with the expectation of being shot down with a spray of non-technical folks' spleen. But with a revelatory zeal I will explain myself further.
I will always contend that developing software, as a profession, is artistic, in that developers create their solutions to real-world problems using techniques learned and passed on by masters, tried experimentally in many projects, improved on, and occasionally discarded as no longer effective. This is not science, in its strictest sense, fundamentally because there is no absolute, no truth sought. This is art.
However, like the great art of old, and unlike amateur art, developers' creativity is usually hampered by their patrons - the exigencies of the business environment, such as time & resources. This should come as no surprise.
Therefore, a developer is expected to create beauty out of something that is generally not sufficient, and is often ugly. They are expected to do it devoid of inspiration or the vagaries of muses. They are given a fixed canvas, limited assistants, and often even only a small palette, and are expected to create a masterpiece every time.
Heaven forbid that someone should point out that art just doesn't work like that!
Then there's the argument that usually comes from frustrated project managers with no background or experience in the arts, that a bridge can be built precisely with known materials, planned to the micron, etc. How often have I told such a project manager to go build a bridge & get over it?
Software developers don't build bridges. Bridges don't solve business problems.

I used to have one such project manager - an inherently stupid & lazy man, but that's just my opinion. I tried to explain to him that what we did wasn't work with steel girders, but it was like rearranging the atoms to invent a new kind of steel each time. He didn't get it. After this, I put a sign on my cubicle which read "Alchemical wizardry applied within". He never asked for an explanation.

And still, each time a project fails - either in being late, over budget, or not fulfilling all of its requirements - it must be the fault of the developer who must be inherently ineffective (or incompetent) if they can't deliver the promised project. Obviously. Writing software is so beneath project managers that they could not stoop to do it. Well, there are those who once wrote a pascal program, and that was a snap. It added two numbers & got the right answer. That could be done in less than a day ...
There is no answer. There is no question. There is only life & its experiences. And there is death.
A project begins. We use what we have learned; we learn more; we help others to learn from us. A project ends. Whether we have led a good project or not is not judged by our success, but by the weight of our souls against a feather on the scales of fate.