I've felt this way before. Dejected that the my new job wasn't an exciting candy land of save-the-day hacks and movie montage of elegant code spanning the screen. My expectations were too high. I thought we would always do the right thing to kick out software all grown up ready to take on the world.
When the realization set in I got angry. First at the job then at myself. I held it tight knowing someone was to blame. Anger lead to depression which sparked more anger. But depression won, and eventually lead to a calm realization that programming wasn't the magical world I wanted it to be. So it became just a job.
I never wanted it to be just a job. I work with people who don't know a bit from a byte. They could care less what I code as long as it works. For a long time I believed them. I just made it work. Recently I've started to believe again.
I've started to believe in the magic again. I'm learning that within the boundaries of my job I can create little realms of beauty. No one cares how I code so I can code to my own enjoyment. I've stopped caring what other people thought. And I've stopped looking to the job and outside world to give me enjoyment and I've started looking inside myself. To find the joy in my own actions, in the moment.
I would say that if you work on a very large scale system with an explicit way of how things are done and there is extreme rigidity in doing anything differently than the job gets tedious quite fast.
I would venture to say that most developers do not fall into this category and have more autonomy (even if that is just building a CRUD web app). Most code isn't peer reviewed and the emphasis is on getting results. Within those boundaries one can do so much to keep things interesting.
I also find it interesting that as developers we sometimes feel frustrated that the end users don't understand or care about the complexity of the implementation and how much may have gone to just that single push of the button on the screen.
How much do you care about the complexity of your car, or the countless bridges that one may drive through? I can sense the complexity behind it but at the end of the day, I enjoy that is come down to turning on the ignition.
Every profession has these issues. Ask the newly grad civil engineer who's tasked to work on a bridge. What do you think they get to do? They get handed the mother of all books on how a bridge is built and everything important that needs to be considered. Their job becomes one of plug and play as there is only so many ways one can build a safe bridge. I had one of my professors relate this story and he couldn't handle it. He went on to graduate school and become an engineering professor.
For better or worse, we get some say on how that bridge gets built, as long as it stays and functions as a bridge by the end of it.
I find a lot of developers just give up, shifting responsibility from internally to external factors. It's hard to see someone just going through the motions, not evening really trying because the job has become "boring". It becomes a self-fulfilling prophecy as the company starts to recognize this and eventually puts someone more inclined in the same position.
It took me a longer time than I liked to realize that the end user didn't care at all. To them it was magic and they just want it to work. And you're right, most shops don't care how it's coded either. Once I realized that it gave me some freedom to once again enjoy my work. I still get frustrated from time to time, but at least I know why and can shift my thinking when I realize I'm headed down a negative path.
Most users are as you describe, but I made it my mission to educate them on what they were asking for when requesting a software change, and why one change might take two or three days, while another takes a month or more. I'm not didactic about it, just providing good explanations in terms they can understand. This makes them better understand that I'm neither a wizard nor a plumber, but someone who uses the ability to break complex problems down into a collection of small, simple, eminently-solvable pieces, and builds the complex solution out of those simpler solutions, sometimes using a bit of insight, creativity, and mental brilliance to achieve economies of scale.
The bonus, for me, is that occasionally there will be a colleague who gets it, someone who doesn't get that glazed look on his or her face as my words pass in one ear and out the other, and who can become a true partner in the quest to maintain, improve, and extend the software's capabilities. When you find someone like that, it makes the effort seem worth it.
I've done the same with the Account Executives where I work. Some get it more than others, but most only get it part of the time. Still it's better than nothing.
I don't want to burst your bubble, but there are bosses out there who a) will read and criticize your diffs and commit comments, and b) will not be anywhere near as capable as you. These circumstances combine to produce a situation where it is entirely possible to be "too clever", which elicits a polite chewing-out and an assignment to go back and replace elegant code with code that any idiot can maintain.
If you know a trick for maintaining a sense of satori in such conditions, you would oblige me enormously by describing it.
(I'm replying late to this so you may never read it.)
I don't think I'm that great of a programmer. I'm self taught and I have a lot of insecurities about my abilities. Even though I get paid to program. Even though I pickup new languages, on my own, and write working software with them.
So when I write code I write it as simple and direct as possible. I stay away from clever and I stay away from cute or smart. Because I know that the idiot that will be maintaining the code and need to understand that code will be me.
I've been able to build trust with stakeholders, and that lets me be 'too clever.' The problem is when they lose that trust, because of a situation they are going through. Being clever is a risk in many situations.
When the realization set in I got angry. First at the job then at myself. I held it tight knowing someone was to blame. Anger lead to depression which sparked more anger. But depression won, and eventually lead to a calm realization that programming wasn't the magical world I wanted it to be. So it became just a job.
I never wanted it to be just a job. I work with people who don't know a bit from a byte. They could care less what I code as long as it works. For a long time I believed them. I just made it work. Recently I've started to believe again.
I've started to believe in the magic again. I'm learning that within the boundaries of my job I can create little realms of beauty. No one cares how I code so I can code to my own enjoyment. I've stopped caring what other people thought. And I've stopped looking to the job and outside world to give me enjoyment and I've started looking inside myself. To find the joy in my own actions, in the moment.