A shortlist to help you persuade your teammates to adopt functional programming (or any technology/practice/tool currently unknown to your team).
Like many others, I fell in love with functional programming, the problem was that I was the only one in my team.
I believed that functional programming could have a great impact on our code base that’s why I’ve tried to convince my fellow developers to make the change.
These are my dos and don’ts from that experience.
Don’t sell it as the solution for everything
First, it’s not 😬.
Yeah sure, functional programming is awesome and solves many issues but it’s not a silver bullet and has many other pitfalls. Telling everybody that it will solve all their problems will just create very high expectations that will crash on the first obstacle.
Do present it as another approach to solving problems
Try to take a specific issue and show your team how it can be done in a functional way. In that way, the benefits will be clear and a lot easier to digest. Choose a complicated pipeline that, with the help of Either monad, will become clearer.
Don’t write your next feature in a completely functional way
Okay, so the feature is written flawlessly but you are the only one that can understand that code 🤓. It’s way more important to have a unified code base than having your feature written in an adequate way. You will create confusion and make your team feel overwhelmed by the names and unfamiliar patterns.
const simple = fn1 => fn2 => fn3 => fn4 => fn1(fn2(fn3, fn4)); WTF?!?
Do a workshop
A workshop is a wonderful way to teach new techs and paradigms. Start from the very basic and move to more advanced areas, take an existing feature, and refactor it together while indicating the best practices and the benefits.
Don’t fight
Many people just love wasting time and fighting over stupid things like tabs vs. spaces, vim vs. emacs … imperative vs. functional 😤. Try as much as possible to avoid any battle because they will make people automatically reject the functional ideas.
Do be flexible
It’s ok if someone mixed some imperative code inside your beautiful functional module. Go to this developer and open a discussion about why he/she chose that way and show him the other approach and be open to accepting his way.
Changes are a process, don’t give up and stop writing functional code in your job projects.
Do you have any tips from your experience? Please share them!
Top comments (0)