Something as simple as a pre-commit hook that checks files that were changed in your commit and rejects the commit if the rules aren't followed is a very cheap and effective way to enforce a coding style.
For a python project for example, you could set pre-commit to check formatting, linting and typing, which means that when your code reaches the remote repository, before any CI is even started or any PR is openned (before you even push really), you know your code follows the rules that have been set for the project. Thus everyone knows you don't need to spend time in the code review looking for these mistakes and instead focus on the actual features.
pre-commit does not even need to be pushed to remote to work, so if your company has no plan to enforce it but it still helps you, you can still use it, unlike a CI.
As for this:
> And if, god forbid, I miss one, just get over it. It can be fixed later. It's not nearly as important as having correct functionality in our app, and I'm pretty busy!
It's true that one mistake is easy to fix later, but it's just as easy to fix now. If you postpone it once you will postpone it again when it's not highlighted in a PR diff, it's just a recipe for never fixing it. Every language has automatic linters/formaters that check (and even fix) your code according to rules you define, turning the work of finding these mistakes into a simple `lint ./src/` command. It's takes a small amount of time to setup but saves you a lot of time down the line.
I don't think piracy is what is costing you. Data hoarding is.
Even if you wanted to keep a library of all watched movies or series from the past year you'd sit at much lower than 30TB. Do you really need to keep all this data ? How many times in your life will you rewatch all those movies and would it not be faster to find a new download then with the slight risk that it won't be available anymore ? You can probably safely remove/redownload the most popular shows and only keep the more niche ones that may become hard to find, or purge your movie library every few months for stuff that you never rewatch (you can probably even automate that). With decent internet and preferences for popular movies you could even argue that you'd just have to keep around the torrents and re-download your movies on the fly, trading a few minutes of waiting for a much cheaper setup.
There's also ways to optimize the uptime of your server which is essentially a NAS for movies. You could have the big machine off most of the time and use a Raspberry Pi to send Wake On Lan packets when you need it. It's may take an extra minute before it's usable but you would lower your bills significantly.
That $1200 upfront and $55/month sound like at least double what it should be. For a server that may double as a backup for your own files the upfront investment can be seen as worth it. And with the many streaming platforms relying more and more on exclusives, region-locked content that require VPNs that may not even work, time-limited content and increasing pricings your reduced electricity bill may not be far off from what legally viewing the content might cost you.
For a python project for example, you could set pre-commit to check formatting, linting and typing, which means that when your code reaches the remote repository, before any CI is even started or any PR is openned (before you even push really), you know your code follows the rules that have been set for the project. Thus everyone knows you don't need to spend time in the code review looking for these mistakes and instead focus on the actual features.
pre-commit does not even need to be pushed to remote to work, so if your company has no plan to enforce it but it still helps you, you can still use it, unlike a CI.
As for this: > And if, god forbid, I miss one, just get over it. It can be fixed later. It's not nearly as important as having correct functionality in our app, and I'm pretty busy!
It's true that one mistake is easy to fix later, but it's just as easy to fix now. If you postpone it once you will postpone it again when it's not highlighted in a PR diff, it's just a recipe for never fixing it. Every language has automatic linters/formaters that check (and even fix) your code according to rules you define, turning the work of finding these mistakes into a simple `lint ./src/` command. It's takes a small amount of time to setup but saves you a lot of time down the line.