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?
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.
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.
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.
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.
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.
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?
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.
Related Posts