One of my problems is that I like to write code. Specifically novel code. But the places I work at really want me to just do regular CRUD work and glue work (use other people's code and avoid novel code). How do I find companies that write their own cool new code? Maybe coding teams get broken down into such small teams that there is only room for CRUD and glue and novel code gets too risky when trying to deliver use value at every sprint.
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.
Depends who's writing the new code. My new code generally doesn't need people to maintain it and those that do end up having to modify it are happier that I replaced the garbage that was there before me.
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.
While maybe my view is a bit myopic here, I think the harsh reality of the world is that it's very difficult to find an opportunity where all you do is write brand new code outside of a small/early stage startup. The numbers just don't make sense to constantly reinvent the wheel, even though many developers love and prefer that. In truth the best developers I've ever worked with and managed have a good intuition about when the re-use vs re-build and I support them in that. Developers who try to push too hard one way or the other often end up taking way longer than they should have to get a task done. As with darn near everything else in life - it's all about balance. That's my 2 cents anyways.
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).
I recommend the pharma industry or any other science-heavy field.
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".
Worth looking into any COSS (commercial open source) companies that you find interesting.
That’s where you write the code that then others glue together - plus you can inspect the codebase beforehand!
Learn a statically-typed FP lang and get a job doing that.
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).
Another upside is that if you use a less-common language, there is _not_ a library or package for everything just yet... so sometimes, that creates the opportunity to work on open source at your day job!
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.
It depends on the company's product. At a very large company you might find the odd team that's building some interesting new, internal framework or infrastructure. If you want to stay away from CRUD your best bet though might be a company where the CRUD isn't the core of what provides user value. Examples that come to mind immediately (since that's where I work right now) are data offerings. Lots of interesting new and existing data stores these days and unless you end up on the, likely very small GUI team, it's all hardcore coding. I would expect similar from some ML products.
I also started my career in web development, and also found it became very mechanical after a while.
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.
If you like to write novel code it may be that you really enjoy puzzles. One way to scratch that itch in existing systems is seeing if it can retain it's use cases with less code. See if you can make your net lines of code negative for all your bug and feature commits.
Find a place where you are allowed to own the code, as in code in any language. Ask the coders what language they use. If they all use the same language it's a bad sign. If the work ad mentions a specific code stack it's a bad sign.
>> gets too risky when trying to deliver use value at every sprint.
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.
