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