Any job where you are sort of putting yourself out there in the form of your work can be quite demoralizing, especially with the wrong people in charge. Programmers can be just as touchy about their work as artists--I've seen it personally. Some of this may have to do with cultural diffs. Some cultures seem (at least to me, with limited exposure) to be more or less amenable to "being nice" about criticism.
Or like one of my first papers, when sending it to a very good journal, having one reviewer say "this is all wrong" and the other saying "this is a well known result in the field, nothing new" and the editor just saying "reject".
Somehow, this industry thrives in reinventing the wheel in slightly different ways - once a process is implemented mathematically (in code), it has to be reimplemented again, in slightly different terms (another programming language). We bikeshed in that it's cognitively easier to manually reimplement the function, instead of mathematically determining how to "rephrase" the math in the other terms. When you want 2 wheels, making a slightly different wheel is mentally easier than copying the existing wheel - in terms of coding.
Code review is absolutely nothing compared to what it takes to put yourself out there as a musician or a scientist and have it shot down. Absolutely not even close.
Although I find it weird to call myself a professional, I don't really feel the same way because I usually enjoy the process of doing it and figuring it out for myself. I suspect that I might feel differently if my compensation were directly tied to coming up with new things though.
There is plenty of work to be done that's essentially translating an idea from one situation to another. The satisfaction is from solving the user's problem.
[1] Top architectural offices do mostly competition work. It's not uncommon that one architectural competition has hundreds of participants and only one winner.
Unfortunately, I think this says more about the programmers today and the culture they expect, rather than your resilience.
(that's not meant to imply that you're not resilient, by the way).
The politics are interesting, but predictable and usually die out by junior year. Everyone gets hard critiques and even best friends know they should be pushing each other to be amazing and not let bullshit slide, that's the point of being there.
I agree with the points here but would like to add one thing. "The Creative Process". In learning how to create successful art work, you discover and become entrenched in this.
You learn how to take an idea and move it through phases of conception, sketching, planning, material/media choice and collection, prototyping, iteration, critique/feedback, execution, refinement, polish, installation, transporting, storage, transaction, and sometimes defense of concept.
All of these processes are part of making art. To developers, some of this may sound familiar!
An appreciation of process and an understanding that every action and choice is part of that process can attribute to success in development. Artists who enjoy the creative process are likely to succeed in other disciplines which require extensive processes.
The understanding with most art is that it takes several rounds of critique for a piece to even be complete, much less for an artist to reach their overall potential. And it's considered an honor to receive criticism from someone whose work you admire.
Similarly, self-management is completely necessary if you're completing something long-term, like a novel. Scrappiness, too -- it's very often the case that you have to skip around the gatekeepers to reach an audience for the first time.
I'd also add that there's a certain strange cognitive advantage. A lot of art is built on taking concepts from one situation and applying them somewhere foreign -- translating the feeling of loss into a series of musical notes, or applying the principles of the punk rock movement to dance.
I know it sounds like bullshit to a lot of hackers. But that trick, of abstracting away the details of problems so that their solutions can be used in isomorphic situations, is very handy in computer science.
He said, he didn't think this would go hand in hand, but after he saw some algorithm stuff from a friend he was surprised how easy it was, so he switched from composing to coding algos.
I have no idea why the relationship is so strong, but it is!
Good pattern recognition skills (as in the general meaning of the word 'patterns', not necessarily design patterns), may be part of the reason, since patterns occur in both code and math.
I'd say artists are a bit less conscientious, in general, than CS graduates, which makes them less well-suited to managing technical complexity and avoiding future problems. I wonder if your idea that artists are good at detecting technical debt might be something specific to you, rather than a generic trait of artists?
The 2+ years of art history is somewhat less helpful...
1. We've been trained to critique, and communicate issues constructively. This is absolutely essential to working quickly, the sooner you realize there is an existential problem with what you're doing, the sooner you can work through them. I've become an absolute user story master because of what I learned at art school.
2. Self management, I prefer to work alone because I get the best work done when I can juggle and understand all the variables of the task. This forces me to be adept at a lot of different things but also means that as a developer you can pretty much leave me alone unless I really suck at something.
3. Asking why all the time, critiquing is one thing but the worst experiences I've had are when other developers say things like "It's always been like this". For example, I came into a shop where their build process had an SCSS linter that would error if anyone tried to use a color that wasn't a variable. This ended up creating the habit of a single stylesheet with around 200 slight adjustments of colors. Critical thinking is whats important for building systems with low technical debt, and I think artists are able to realize something is turning into technical debt much quicker than their engineer counterparts.
The tradeoff is that I have a huge communication gap with traditional computer scientists, I really have to work and study algorithms on my spare time and I still struggle heavily with mathematical notations.