Think that's tough? Try learning formal methods and how to design software to be correct by construction. Haskell would be an easy sell. But regardless of langu

Think that's tough? Try learning formal methods and how to design software to be correct by construction. Haskell would be an easy sell. But regardless of language few seem capable of catching errors in logic -- the kind that lead to race-conditions, starvation, dog-piling, cache misses, consistency errors, etc. The kinds of errors whose frequency and impact we are ill suited to estimate. "Bah, that could only happen for 1 in 100k requests." Now your system is serving 3M requests a second. It's very likely you'll be seeing that error. Don't be discouraged though. You might read about a new distributed lock in an important open source cloud orchestration framework that the public is building service infrastructure on and not find a single executable specification. Doesn't mean you can't write one and submit a pull request when you inevitably find errors in it. You just have to keep such alien super powers under wraps. Similarly if your goal is to write more Haskell at your job: just find opportunities to use it. Preferably ones where you can keep the secret of the sausage to yourself. When your bosses and colleagues begin to wonder how you consistently kick butt you can tell them. Then they might want to learn too. At least that's the story I tell myself. Most people are happy in their own instance on Plato's cave. If you bring in new ideas you might be ousted from the group. Or fired. Just keep doing the best mediocre job you can and try not to think about it too hard!