Written by James Sinclair on the 18th October 2022
Indulge me a moment, and picture the following scenario. You’ve just come back to work after a summer break. And over the break, you’ve been working hard. You’ve taken some time to learn functional programming. You’ve been reading articles, devouring books, following tutorials, and practising code kata. And for some reason, this summer, something clicked. Somehow, the pieces fell into place. It makes sense. The way you think about code will never be the same again.
Now, though, you’re back at work. And you’re eager to put what you’ve learned into practice. You grab a new task from the backlog, and you’re away. It feels fantastic. It’s like the code is flowing through your fingertips straight into the computer. And you know the code you’re writing is objectively better than the code you used to write. You’re confident that it works. It has comprehensive test coverage. It’s less likely to explode, because side effects are carefully managed. It handles errors gracefully when things do go wrong. It’s clean. It’s elegant. It’s expressive. And you’re justifiably proud.
Next, you create a pull request (PR) so the team can review your work. And you’re not expecting applause. It’s just code, after all. But you’re hoping that maybe the senior might notice there’s been a change. This code is solid. And compared to how you used to write, it’s light-years ahead. Hence, you’re more than a little surprised when critical comments start trickling in.
“This is too clever. It’s unreadable.”
“How will we debug this?”
“Have you measured to see if this degrades performance?”
“Have you considered the effect of this new library on our bundle size?”
“Too much magic going on here”
Someone even writes “how do errors get handled here?” in the exact place where you wrote an elegant abstraction to factor out the error handling. The code handles the errors fine. They just can’t see it.
And, try as you might, you can’t help but feel hurt. It’s like you’re under attack. You’re confused. The code is better than what you used to write. You’re sure of that. But they’re carrying on as if you lit a paper bag full of dog poop on fire, and asked them to merge it to the codebase. What’s going on?
https://jrsinclair.com/articles/2022/what-if-the-team-hates-my-functional-codepeakzorro 86 points 11 hours ago
I have never worked somewhere where functional code is rejected. There is definitely a place for it. As long as it is readable.
This article is more about making the code readable than it is a criticism of the reviewers not "understanding" functional programming.
Full-Spectral 100 points 9 hours ago
It can also be an issue of consistency. Having one person writing in a completely different style isn't ideal even if it could be unambiguously proven that it was technically superior.
https://old.reddit.com/r/programming/comments/yewe2g/what_if_the_team_hates_my_functional_code