paint-brush
Dos and don’ts while trying to persuade functional programming.by@puemos
1,755 reads
1,755 reads

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

by Shy AlterApril 17th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Like many others I fell in love with functional <a href="https://hackernoon.com/tagged/programming" target="_blank">programming</a>, the problem was that I was the only one in my team.

Company Mentioned

Mention Thumbnail
featured image - Dos and don’ts while trying to persuade functional programming.
Shy Alter HackerNoon profile picture

A short list for helping you to convince 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.

http://bit.ly/microsoft-functional-programming-vs-imperative-programming

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’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 fighting

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 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…