slide

Why software startups should hire functional programmers

Martijn Rutten
5 min read

If you want to conquer the world with high-tech software, you need a world-class team of programmers. Hiring functional programmers is your best bet.

Functional programmers? Hackers that make sure the functionality is right? No, I mean programmers that are well versed in writing in functional languages. Haskell. Clojure. OCaml. F#. Scala. Guys and girls that talk in monads, closures, and recursion. Who wake up at night screaming with nightmares about loops and mutable objects. Those that prefer Google Go over Python because it’s statically typed.

So what’s so special about this breed of programmers? Why does an affection for functional programming almost always equate to world-class programming skills?

Higher level of abstraction

Programming is a pretty abstract activity. Functional programming takes that to the extreme, lifting the problems much closer to the underlying algorithms and mathematics. Compared to the algorithm’s implementation in any particular language that is. If you train yourself to reason at this level, your code will benefit in terms of clarity, handling of exceptions, and (time and memory) complexity. A simple example is to write down a recursive problem such as a tree traversal with a recursion. Leave it to the compiler to implement this as a (tail-recursive) loop.

No more side effects

Not only by reasoning at a more abstract level about their code do functional programmers beat their imperative counterparts. Side-effects are the world’s biggest cause of nasty bugs and unmaintanable code. Function Multiply(a, b) may read like it returns the multiplication of a and b. But what if it secretly also modifies the memory at position 0xbadf00d? In Haskell that would be impossible. In C++ that kind of side-effects are the bread and butter of the language.

A functional programmers will code without side-effects even when writing low-level C code! Stateless and immutable. Exit nasty Heisenbugs. Hello productivity.

Our motto at Vector Fabrics using OCaml was:

If it compiles without warnings, it just works.

Any errors encountered at runtime always pointed to a flaw in the algorithm or design, never an implementation problem.

Functional programming at Vector Fabrics
At Vector Fabrics we mostly hired Haskell programmers. When we first started coding in OCaml for productivity and code quality in 2007, we were worried nobody would want to work for us. Who would want to write in a language that was only used by French academics? Writing OCaml was a statement: “we use the best tools and languages for the job”. The reaction? Finally a company where top programmers did not have to waste their brains on low-level implementation details. We got access to world’s best, despite not having a Michelin-star chef cook preparing lunch.

Recruiting functional programmers

So how to reel in these amazing programmers? Firstly, be honest about your company. Nowadays, companies have realized the quality of functional programmers, yet let them write mainly in imperative languages. That’s fine, but then don’t advertise the job as a functional programmer’s wet dream. Admittedly, we were guilty here too as over time we moved more and more of our code base from OCaml to C and C++. For a large part to get the rock-bottom performance our dynamic analysis technology needed. But also as the external libraries we linked to were unfortunately written in C++.

In a job interview, we ask candidates program on the whiteboard and let them reason about the time complexity of their solutions. Typical recursive problems. It is one thing to know the term monad, but being able to explain this to an outsider like myself makes it practical in a startup team.

Functional programming and quality

Then ask about how to ascertain quality. For a Haskell programmer, the first thing that comes to mind is QuickCheck. Now you instantly have a programmer that understands “programming by contract”, test-driven design, and random testing. Although I’ve never seen a viable equivalent of QuickCheck for C or python, you can expect the functional programmer to be able to translate the experience to another language.

At Vector Fabrics we coded in OCaml. The performance predictability of a stict language like OCaml versus the benefits of a lazy language like Haskell was a continuous lunch-table fight. Yet the productivity benefits were huge. In all 9 years of coding, the longest time we ever spent on locating a particularly nasty Heisenbug was in the C code that linked OCaml to Python. Where we had to deal with both garbage collectors simultaneously.

Computer science is underfunded

So where’s the caveat? Experienced functional programmers are hard to find. Recruiters don’t get beyond adding the “Haskell” keyword to their CV search.

More fundamentally, there is an imminent problem that the top-notch computer science departments struggle to get sufficient funding. Their research on, e.g., “datatype-generic rewriting” is deemed to esoteric and abstract. Too disconnected from the industry if it ain’t big data.

We hired our functional programmers from all over the world. Apart from the great cultural diversity that also had its downsides. We lost an unbelievably good programmer from Bolivia as he left for the vibe of Berlin vs. Eindhoven. Another brilliant mind went back to academia as our technical challenges could not compete with academic research.

So how to get and keep the best? Work on great technical challenges, be honest about your technology base, and shout out the relevance of functional programming to shortsighted university managers.

What’s your take on functional programming in a startup?

Author

About Martijn Rutten

Fractional CTO & technology entrepreneur with a long history in challenging software projects. Former CTO of scale-up Insify, changing the insurance space for SMEs. Former CTO of fintech scale-up Othera, deep in the world of securitized digital assets. Coached many tech startups and corporate innovation teams at HighTechXL. Co-founded Vector Fabrics on parallelization of embedded software. PhD in hardware/software co-design at Philips Research & NXP Semiconductors. More about me.