Earlier quoted context omitted.
It's fine to optimize for the paycheck first and foremost. But while you are at your job anyway, might as well make it slightly less of a drudgery while you are at it. (Eg I quite like functional programming. Both because I like the style of thinking, but also because I don't trust myself nor anyone else with code; and eg a heavy emphasis on immutability means that I'm less likely to get woken up in the middle of the…
I have a ton of coworkers who try to make their job more interesting by trying the most interesting tools instead of the best tools for the job. They have less drudgery, but more stress from not hitting deadlines as reliably. Meanwhile I'll embrace the drudgery and do the boring thing, stay less stressed because get it done more quickly and reliably because I chose the right tool, and got promoted really high. Taking…
About FP and immutability specifically:
You don't have to go full on and re-write everything in Haskell. Small scale decisions can already make your life easier without much disruption. Eg if you are using Python, by default stick your information in frozen dataclasses, and only deviate from that with good reason.
Another thing I have a minor passion for is to as much as possible handle corner cases in the main line of the code.
Eg instead of having a big 'if' at the start of your function to handle an empty list and return early, try to make sure that the main logic can deal with empty lists just fine.
After all, the simpler your control flow, the easier it is to get code coverage in tests and production.
(I mention `and production', because in practice, lots of code is battle-hardened instead of sufficiently tested.)