đč 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.
Top comments (1)
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