> I like software and computer science, but "software engineering" barely counts as either. I expected to be utilizing a million data structures or figuring out proofs of correctness or designing the next amazing distributed system, but it feels like 2/3+ of software engineering is "add field to JSON" or "write a for loop to convert something to a different shape" or "change color of button" or "change width of page layout and then modify selenium tests", and the only data structures that ever get used are hashmaps and arrays. I spent so much time learning the minutia of CSP and TLA+ and set theory and I feel like I have basically nothing to show for it, and now I can't really even change to a career where I would get to use them.
So, around 6-7 years ago I was on a development team and was getting tired of a bunch of things - the frontend treadmill (react/redux, do it this way, no that way, then a few months later there's a new "right way"), how we kept getting new product owners and the "vision" was lost so we were just reacting to customers (and kept remaking the same pages but differently), and a slightly more personal one (no one liked my idea for one of those pages, then a few months later our designer came up with the exact same thing, no one remembered mine, and the page has been unchanged since). Our company was also drifting heavily into silos during that time, some people were frontend-only, some backend-only, where I like the whole stack and didn't want to limit myself.
So after all that I did something that surprised and confused my manager: Asked to get moved to the maintenance team instead of new development. They were intrigued because apparently that team is where new hires often ended up, and they almost never had someone experienced on it - which surprised me because I figured that job would be harder than new development. So far I've been on this team longer than any others and have yet to get tired of it. I know some of it is how good a manager we have, but the work is also very directly about fixing things. It's much more self-directed, no product owner initiated rewrites on a whim, large projects still happen when something is really bad, but because it's considered legacy there's no treadmill-chasing. And the random fixes can end up anywhere in the stack, so I get to keep using everything I'd learned from linux through the database and server to frontend, instead of sticking to a silo.
So even "5) Just live with it." does have sub-options.
I've debated doing that exact move as well, simply because I do enjoy making "incorrectly" designed code "correct", by either moving to a simpler model or utilizing a more tried-and-true way of doing things, and since no one wants to be in "maintenance" it might afford me some more freedom.
At a previous job, I would occasionally spend time on the weekend rewriting and simplifying code because there wasn't really a "maintenance" team and I knew the only way that it would ever get better was if I fixed myself on my own time. I've since drawn a line in the sand that I do not work for companies on weekends but I did sort of enjoy that process.
So, around 6-7 years ago I was on a development team and was getting tired of a bunch of things - the frontend treadmill (react/redux, do it this way, no that way, then a few months later there's a new "right way"), how we kept getting new product owners and the "vision" was lost so we were just reacting to customers (and kept remaking the same pages but differently), and a slightly more personal one (no one liked my idea for one of those pages, then a few months later our designer came up with the exact same thing, no one remembered mine, and the page has been unchanged since). Our company was also drifting heavily into silos during that time, some people were frontend-only, some backend-only, where I like the whole stack and didn't want to limit myself.
So after all that I did something that surprised and confused my manager: Asked to get moved to the maintenance team instead of new development. They were intrigued because apparently that team is where new hires often ended up, and they almost never had someone experienced on it - which surprised me because I figured that job would be harder than new development. So far I've been on this team longer than any others and have yet to get tired of it. I know some of it is how good a manager we have, but the work is also very directly about fixing things. It's much more self-directed, no product owner initiated rewrites on a whim, large projects still happen when something is really bad, but because it's considered legacy there's no treadmill-chasing. And the random fixes can end up anywhere in the stack, so I get to keep using everything I'd learned from linux through the database and server to frontend, instead of sticking to a silo.
So even "5) Just live with it." does have sub-options.