3 ms·

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

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 a mercenary attitude towards work works just fine for me, and keeps me overall happier. Per your example, I like FP and immutability for the same reasons (won't get paged as much), and I'm always reading to stay up on my game, but it's still just work. If you worked with me, you'd probably think I live and breath this stuff as a passion because I put so much time in to stay so much on top of the tools available. But I hate programming. Hell, you might even say my hate of it drives mastery in the same way your passion drives your mastery. To me, it's just a tool by which to automate things I do care about (and retire younger than I could in other roles).

eru 6y ago
I think we mostly agree. 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.)

eru 6y ago

I think we mostly agree. 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.)