Today's new code is tomorrow's legacy code. It will need updates, security vulnerabilities will be discovered in it, and it will break occasionally or maybe lose data.
Someone will have to maintain it.
People need to have more respect when it comes to new code. It should be treated like unexploded ordnance.
You can write new code with the intent of making it maintainable.
If your new code is clever shit nobody understands you probably shouldn't be writing code.
I use very, very cool language tricks in my unit tests.
Not in the production code.
If I want to ship my software, as opposed to just write it, I need to use tech that's a couple of clicks back from "bleeding edge," and spend a lot of time, "polishing the fenders."
B O R I N G
But I get a kick out of seeing my software out there, ready to be integrated into other people's software (90% of the time, I'm my own best customer, but I write all of my software as if it were being adopted by a Fortune 50 company).
It's sort of hit and miss, but sometimes you get a research project where it's the experimental results which make or break the whole thing - your role is to support the experiment with the software you write.
Example, since this may sound too vague: I'm currently in a project that started off as a research paper and associated Matlab code.
Problem is, you can't ship this to people who just want to see the results and don't have the proper computing power on their work laptops to perform the necessary calculations, so we built a whole web app which does all that at scale.
Other times you do a boring compliance/business application, but such projects are usually timeboxed and with unchanging scope.
Example: 9-months, 11 devs and the result was an app where the user clicked a button once a month which made the backend talk to 15 different APIs that in concert created the last section of a 2k page PDF file because regulations said so.
Boring as hell but it was over soon enough and even got an internal award for "least(zero) complaints".
Shameless plug: We are hiring at Jina AI https://jobs.lever.co/jina-ai
Even if you end up at a "Simple Haskell" place, you'll still have all sorts of opportunities to reinvent the wheel (so that you can run yourself over with it, of course).
Some people will say that this is a downside, because you can't build new things or ship new features as quickly… But I suppose that it comes down to what you want to get out of your career, and what your goals are.
If you are careful and diligent, you can find a way to get paid to solve problems within the domain of your interests. It might take a few years of study on your own time, but I pulled it off; and if I can pull it off, that means that just about anybody can!
Plus, learning new stuff is fun, and I would not have spent the time that I did learning the things that I have learned, if I didn't feel like it was worth it for its own sake.
You get paid to write glue and CRUD apps because that's what actually solves the problems most people and businesses have.
Personally, I've found game engine and graphics programming to fill this void. It's somewhat tricky to learn, but if you're interested I'd check out Handmade Hero to start.
The job market for engine programmers isn't fantastic, especially if you want to work remotely, but there are definitely jobs out there, and very few people capable of filling the roles.
There are many novel projects that work with novel code, (such as UI / features on top of stable diffusion).
And you can drill into the novel code dependencies (such as SD in above example) if you want to write novel code.
Working with teams shipping novel code publicly is probably the fastest way to find work that pays you to do similar.
I disagree. To me, being afraid of new code or refactoring code means you're working with a code base that has a lot of tech debt and also no serious continuous integration infra.