Dos and don’ts while trying to persuade functional programming.

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.

http://bit.ly/microsoft-functional-programming-vs-imperative-programmingDon’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’s will solve all their problems will just create very high expectations that will crash on the first obstacle.

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 the Either monad will become clearer.

Don’t write your next feature completely in a 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 wrote 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 fight 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.

a very important reason for fightingBe 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 did he 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!

Go a spread some functional magic out there…

Dos and don’ts while trying to persuade functional programming. was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.