How to introduce Haskell into your company

📹 Hate reading articles? Check out the complementary video, which covers the same content.

---

A lot of people want to get a Haskell job. One way to get a Haskell job is to make your current job a Haskell job.

I want to share a few methods of introducing Haskell into a company. Growing from there or making Haskell a primary language is a whole other topic.

Note:

• These methods can be applied to any niche language or technology; we chose Haskell to be specific.
• These methods might not work for you or your company. But you won’t know if you don’t try.

So, let’s go in the order of complexity.

Build tools and scripts using Haskell

Every now and then, we stumble on tedious tasks that can be done with a script or automated: doing some primitive data investigation, searching for anomalies in the logs, making requests while handling auth, and so on. Just check your scripts directory.

But how many one-off scripts are actually used once? Why not help your future-self and write maintainable scripts?

What if you put your bash aside next time and do it in Haskell? Aren’t you tired of guessing how the script’s arguments work? Or dealing with deprecated usage comments?

#!/usr/bin/env bash
#
# Usage:
# - 'scripts/my-simple-script.sh cmd1' does X
# - 'scripts/my-simple-script.sh cmd2 <dir>' does Y
set -euo pipefail

...

Haskell is one of the best languages for writing CLI tools. It allows us to provide neat interfaces for our tools. For example, this is how we add a comprehensive usage/help screen with optparse-applicative:

myOptionsParser <**> helper
--              ^^^^ ^^^^^^ 
--              helper takes any parser and adds a help option to it

Then, running the program with --help displays the full help text:

my-tool-name - a description of the tool

Usage: my-tool-name COMMAND [-q|--quiet] ...
  Some description ...

Available options:
  -q,--quiet            Whether to be quiet
  -h,--help             Show this help text
  ...

Available commands:
  cmd1                  Description ...
  cmd2                  Description ...
  ...

The next level

The next level is automating your occasional support requests and even tasks for other departments. For instance, you don’t have to manually “quickly get reports” or search for some data inconsistencies. Just build a (quick) Haskell tool for it. Bonus points if you can slap a UI on top of it. Even if it only has one button and one output.

They don’t even have to ask you. Heard a colleague complain about a routine task? Give them a Haskell tool, endpoint, or UI — make their life easier.

⚠️ Warning: This shouldn’t come at the expense of your actual work. Even though this brings outside karma, your boss might not be as happy.

Handling both? Good, nobody gets fired for doing too much work! But watch out for burnout!

Build prototypes using Haskell

🤔 “There is nothing more permanent than temporary”

If you’ve been in the tech industry for some time, you’ve probably noticed that nobody rewrites prototypes.

Prototypes just go to production. Occasionally, the big “let’s do a rewrite” gets dropped if the service grows and becomes important.

So, why not make a prototype in Haskell? Worst case, you (or someone else 😉) have to do a rewrite in a year or two.

Beware that you might need to do a lot of work (and quickly!), especially if this is your first “real” Haskell service. But nobody said it’s going to be easy.

What if my company doesn’t do prototypes? Well, maybe it’s time to introduce prototypes. Or perhaps it’s time to do an Internal hackathon! The same law applies to the prototypes written during hackatons.

Clone your CTO

The fastest way to switch to Haskell is to clone your CTO and switch immediately.

Some argue that cloning a CTO is more complicated than selling Haskell to one. But I disagree. I have yet to see somebody at that level without prior Haskell experience get convinced to switch to Haskell.

On the other hand, if you get blessed with a CTO who knows the pros and cons of using Haskell and is open to it, that's it – you made it.

Alternative: become a CTO

This should be self-explanatory.

Start with gateway drugs

The slowest way is introducing different technologies to build-up to Haskell.

For instance, if you are doing JavaScript, the jump to Haskell is too big – you might need to go through something like Elm or PureScript first. Or, if you are doing Java – something like Rust or Scala could be your intermediate step.

But you have to keep pushing the limits of these tools. Otherwise, you can settle on a local maximum (which might be a great outcome). Start a functional study group, make good use of types and abstractions, etc.

⚠️ Warning: If you get carried away, for example, start abusing operators or doing type-level hackery just for the sake of type-level hackery with no real benefits, you risk turning people away from FP and Haskell forever.

If you play your cards right, build up the hype right, and your team/department/company has ripened, switching to Haskell is unavoidable at some point.

Strike a deal with an upper-manager

💡 This one is the most complicated and should be used as the last resort

It’s a well-known technique but often used in reverse or retrospect. But you can use it upfront.

If you know a (self-aware) manager who has been given a project doomed to fail and doesn’t want to be blamed for it, you can arrange to use Haskell for the project and use it later as a scapegoat.

You can find multiple projects (documented online) that failed for reasons, and Haskell was publicly blamed for the failure. No questions asked. None of the managers took the accountability. Haskell is a perfect scapegoat, it’s proven to work.

So, you get time to write Haskell, the manager gets another project (or maybe a promotion), and Haskell keeps avoiding success.

You’re welcome.

In conclusion

If you were wondering how to start getting paid for doing Haskell, I hope you now have something to experiment with.

And in case it wasn’t clear: The more people and experience you all have, the more likely you can do this.

---

Comments

[JoelBonetR 🥇]

It's all laughs and giggles till your MR gets rejected 😂

Now being -more- serious, it's always better to lower the stack to the minimum needed rather than diversifying it.

If there's no real need to add a piece you shouldn't add it, KISS is the most important principle and gets ignored more times than what could be considered "acceptable".

If you are working on a different language, use Haskell (or whatever) for your side projects and search for a specific Haskell (or whatever) job in the meantime if you already know it's not used in any project in the current company you are working on.

Cheers