Similarly, you could look at what an Artist does with a painting.
I think looking at coding as an art has a few fundamental problems however. It may be extremely appealing to aim for beautiful and elegant code, but it doesn't satisfy the goal of coding. Code has a need of being practical, of working. It is a balance between function and form. I think going to far in either direction will not pay off in most cases. Too much time is either wasted writing a piece seen as acceptable, or re-factoring the code at later stages.
As someone who works as a software engineer and paints for fun, I've used the analogy once or twice.
But it only holds a little.
It holds in the sense that most of the time you start with an empty canvas. You use the tools you have at hand or the tools you wish to learn more about. You tend to plan ahead enough to prevent structural mistakes, to make sure your work comes out the way you envisioned it. It holds in the sense that only 'a fellow artist' can begin to understand the details of what you did and how that fits or doesn't fit in the work at large. It holds in the sense that you shouldn't ever start out with the details when performing either activity.
When you code something you do it to specification, which could be analogous to one being contracted for a particular piece of art.
The coding and art analogy doesn't hold when I consider the emotions that shape my art and drive me to create it that way, and the different result that it has on different people when they pay attention to it. It doesn't hold when I look at how one does flesh out detail. I myself start out with a general sense of the space that an entity will not be occupying. I describe that space in more and more detail until it approaches the space that it will be occupying. Then I can start placing marks that describe the details of that entity, in increasing detail. Programming has no analogy to that as far as I'm aware. It also rarely holds when you consider particular methods such as the 'test' part of test driven development.
This is probably something that only applies to me though, because everybody who programmes or paints has their own way of working.
I think this is exactly why many of us find the architecture, or "civil engineering", metaphor so appealing. Architecture is neither pure art nor pure science. It's a delicate balance of form and function, beauty and practicality.
In fact, I think the article only manages to make the architecture metaphor appear more fitting. Even when you're building a bridge, you never really "put in the last rivet and make the last weld." Read about any historic bridge and you'll quickly learn that the life of a bridge can be as dynamic as any novel. London bridge was redesigned and rebuilt (refactored?) on several occasions since Roman times. The Brooklyn Bridge was conceived by a man, continued by his son, and completed by his daughter-in-law.
I think looking at coding as an art has a few fundamental problems however. It may be extremely appealing to aim for beautiful and elegant code, but it doesn't satisfy the goal of coding. Code has a need of being practical, of working. It is a balance between function and form. I think going to far in either direction will not pay off in most cases. Too much time is either wasted writing a piece seen as acceptable, or re-factoring the code at later stages.