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.
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.