As a counter-point, another important reason for developer unhappiness is to put in lots of work and have nothing to show for it. Case in point, a company I worked for had so much internal politics we never got around to releasing anything worthwhile and it was the most demoralizing experience I ever had, leading to a burnout.
There should be healthy balance of releasing fast and cleaner codebase. That balance changes based on the team size (1 vs 10 vs 100) and developer experience (the more experienced you are, more effortless it is to write clean code)
.
I have an experience very much related to this, which is to develop for a platform I cannot use.
A couple clients in recent years have hired me to develop the backend system(s) for clients that were meant to be built for Android and IOS.
Somewhere down the line, after I'd already been well invested, these projects dropped their intention to develop for Android and thus I was stuck working on the backed for an application I had no reasonable means to use everyday. Sure, I have an iphone for development, but my day-to-day phone is an Android.
Over time it gets harder to remain interested in a project I can't personally use. It's not that I can't fill my day with interesting work, since my portion isn't specific to the client platform, it's just that I can't show it off when I'm not working on it.
Because this has happened a couple times already, I've started ensuring there will at least be a web-client available before I sign onto the project.
As a software consultant, I am rarely the target user on any of the software I develop. Occasionally, this means integrating with platforms or systems I do not personally like. I derive satisfaction from from crafting a high-quality experience for the user that solves their problems. At the end of the day, whether I use the system or not, I can take pride in a job well done.
I've found that sometimes, the difference between a negative and positive situation is just the outlook.
While this is true, sometimes you work on a very large project, the end goal of which you will never see and don't really understand. The abstractness of the work you are doing can be challenging for people who like to be excited about the end product.
For instance, a while ago, I was working on a large industrial project.
Between me and the customer were a layer of business analysts who figured out what the system did, and a layer of systems engineers who worked out the specifics of the system in terms of components with interfaces, and logic flow charts for what those components did in different situations.
For one assignment, I needed to make a value returned by a webservice change when a GPIO was toggled to indicate a button had been pressed. I didn't know what the button did, or what the result meant, and communication with the systems engineers far away was through JIRA tickets. I didn't even ask because the management didn't like off topic comments on the tickets. I think it was a custom feature for an oil tanker, but who knows what I made...
While that way of working was very productive, and produced reliable software built to validated designs - with lovely code because we could really focus on it - it was really hard for me personally to feel any passion there.
I doubt that. You may have delivered flawless code to a specification, but who knows if most of it even mattered, the tings that did actually just did a half-arsed job, and everything just marginally lived up to the expectations?
I work on fairly large systems where we have 50 teams (or more, I don't even know) and it's hugely inefficient. Asking the right question at the right occasion can save millions, although it's more likely that they are asked to late when it's just embarrassing at best.
There should be healthy balance of releasing fast and cleaner codebase. That balance changes based on the team size (1 vs 10 vs 100) and developer experience (the more experienced you are, more effortless it is to write clean code) .