I don't like, however, my work as a programmer. The tasks are just too mundane. I spend multiple days on a RESTful CRUD controller, just because there are so many (IMO useless and even obfuscating) layers of abstraction. The only challenging aspect is the lack of conventions and documentation.
And the market is severely hit driven, so you could be working 6 months to 2+ years on a project only to see it land like a thud in the marketplace, possibly due to nothing more than a couple reviewers that clearly barely played your game before writing a scathing review, or you just picked a bad week and get completely overshadowed by other games.
I worked on 7 games for three different companies, and all of those games failed to find and retain an audience, for various reasons. You spend 4 years of your life working on projects that may as well not have existed, except for your own personal development, and the industry starts to look less appealing.
I'm working on software I have much less passion for right now, outside of the game industry, but at least it gets used on a daily basis by thousands of people (not always, I've worked on projects that have gotten binned because clients have backed out or contracts never got signed, or the lead developer quit and the manager decided to outsource the project, in this industry as well). And at least I'm getting paid quite a bit more than I would in the game industry.
There's always been some push-back against over-abstraction, from Rails' "FU Java" spirit to the whole Go ecosystem. It's just that these jobs are much harder to find than the typical Java EE hellscape.
The fact that you are spending multiple days, rather than hours, building a controller hints to me that you haven't really mastered that work. Perhaps the task might feel less mundane if you developed a tool/framework to simplify the task itself.
Let me elaborate on what it took me to implement a CRUD controller.
I had to implement a repository interface, a respository a context, a service interface, and a controller. Then I had to understand how to write the swagger documentation. Then there is a convention of wrapping every result and exception in some kind of wrapper, which is not documented so I had to figure this out from looking at other controllers.
Then I saw a execution path for another CRUD controller which could throw an error which was not in this wrapper, so I had to discuss this with someone from the team. Sure enough, he is in another country, and takes a while to respond. I was lucky it was still morning, or he would have gone home already (there's a 4 hour time difference). Sure enough, this was a bug in the other controller.
Then, there is a logging and a monitoring service I had to understand and implement. Undocumented, of course. The controller I used as a reference was inconsistent in monitoring, so I had to discuss this. Then, the requirements for the controller are not clear. The RESTful way of responding to a GET request for a nonexisting resource would be a 404, but the wrapper does not allow this. The reference controller returns 200 OK, but with a null value. So I had to check if this is indeed what's intended.
Then I had to figure out how the unit testing framework works and I had to write tests for each method. OK, good practice, but it feels a bit weird, since the unit tests should not use the database while the entire purpose of the CRUD controller is to use the database. So much of the logic I'm supposed to test is mocked. So, I had to learn how the mocking framework works. Then I wanted to write unit tests for the repository, but entity framework crashes when I use an in-memory database. The other developers had a look, but didn't understand this either. The other repository implementations are not tested anyway, so I skipped this.
Additionally, visual studio crashed, corrupted my git repository, and I ended up deleting and cloning the whole repo again. Then, I had to configure the project again before it would build, which involves opening the project in an older version of visual studio, then opening the same project in the latest version (some errors magically disappear), and adjusting the IIS settings (which are a mystery to me).
I also had a long meeting to attend, and the person who's supposed to get me started didn't have time to help me. In the end, I'm still not quite happy with the actual logic in the controller (it has inconsistencies similar to the controller I used as a reference), but I refuse to spend more time on it.
About the documentation, maybe you’re the one to take initiative and spin up a wiki? Maybe you’re the person that consolidates logging into a reusable internal library?
Related to the topic, maybe this is not what you should be doing. There is good work out there, but as cliche as it sounds, you have to show passion for them to find you.
But it does also sound like there are some problematic inefficiencies in the way your company's software stack is set up. Common tasks like logging, caching and error handling should be abstracted away to a separate layer so that you get it for free whenever you implement a new service or endpoint. Don't know if this is old news to you, but check out e.g. [1].
This part about abstracting away rote work and optimizing a stack to be less maintenance-heavy is a learnable skill. The problematic part is that your working environment needs to have it in its culture. It needs to be okay for staff to spend a week here and there tuning a process that's used again and again. This is a big force multiplier which needs to be appreciated by management.
I'm in an online banking company with an 18-year history and all the cruft that entails, and we're in aggregate spending multiple full-time positions continually upgrading our infrastructure and practices. Releases used to be one-week affairs that were performed twice a year. Now they're done in half an hour, most of which is verification and monitoring. Etc, etc.
[1]: https://msdn.microsoft.com/en-us/library/dn223671(v=pandp.30...
Well, don't forget the challenge of coming up with new, creative answers to why isn't it done yet and why aren't you working faster and what do you mean "reading the documentation", just program, that's what you're paid to do!