🧪 Technical Storytelling: Making of Elixir at Ramp 🗣

🎵 The song for this post is John the Fisherman, by Primus. 🎵

It's been nearly two years since I wrote Elixir at Ramp. I'm really proud of the post I ended up shipping, and thought I'd write up what I was trying to do and how I did it with some behind the scenes. My background is in theater, and stories are the stuff of life, maybe this little peek can help you in crafting narrative at your company.

This is the art for the "bard" class in D&D. I've played tabletop games for decades and was always put off that these little musicians and cheerleaders were given the same weight as, like, powerful wizards or legendary fighters. But then I had a strong reaction realizing that of all the classes, I'm probably a bard.

Goal (and table stakes): Be fun to read, and coherent

Obviously, the should be fun to read. Some writing is more for the writer, some writing is for a close circle and less about craft, but this was to dazzle an audience and so, table stakes, I needed it to hit.

The hardest part is packing everything I wanted to say to a digestible length: if you look at a lot of my early blogging, there's definitely an element of "…is it really important to include every thought you have about the topic?" So I needed a coherent narrative structure arising from these goals. What am I trying to do? is each subheading of this post, but for what content will enable that?, I structured it into 4 little sections:

• Why Erlang (and moreso, the BEAM)? I gave myself only a few paragraphs for this: near the beginning and in unfamiliar territory for most, it's where readers are most likely to abandon ship. A full treatment of this is hard when I could barely contain my feelings on this in a 24 minute talk.

• Why Elixir, especially, and not just Erlang.

• Make an original, credible claim!

• Tie it back to the goals of the post: this is for a company blog. What are the objectives of engineers in companies, and what are the objectives of a company engineering blog?

For the first section, I breezed past the substantive points but hyperlinked the hell out it. Basically: "this is transformative stuff, and here's where you can find out about it, but I won't want to rehash the old masters." Second section was easier to write because most "why Elixir" posts have to cover some ground from section 1, here I could focus only on how it differs from Erlang, and critically, compare it with other comparable startup tech stacks (Node, Python, Ruby) by focusing on ergonomics and community.

This set me up for section 3, which I consider the meat of the post, since I was already comparing with other stacks.

Goal: Avoid genre traps

There used to be a ton of startups writing blog posts saying "Why we use Julia" or somesuch, and most of these read exactly the same: "we love that headline feature of our weird language; here's a very short and questionably-explanatory paragraph on what that feature is. We feel it makes us so much more productive." Maybe reductive, but it often feels like "our CTO was impressed when they played with it in non-industrial settings." Here are some for OCaml, Scala, Clojure, Clojure, Clojure.

I rarely find these interesting or persuasive: if you've played the weird language game enough, you know it's hard, and not something you want to inflict on most programmers. The most popular thing I've written on this personal blog is all about weird tech programming, and I put a giant "don't go there with your company!" at the very front. I understand the temptation: I do all my weird language hacking for a reason! But cool features that feel like gamechangers are beyond the imagination of people who've only worked in traditional langs — telling someone what OCaml's type system feels like if you've only used Java or Golang's, without them actually trying it, is like dancing about architecture. You seem like a maniac. You're a bird describing the concept of lift and why your wings are shaped that way to a sea turtle.

I link a few "Why Erlang/Elixir?" posts in the intro of mine. I love those companies and think they made a great choice, but wanted to aim for something different. Additionally, I wanted (and want) to sell the idea that Elixir is less "weird tech" for a web application than even Scala or Clojure at this point. I didn't link it from our blog for SEO reasons, but Brex has one too and I felt I could do better (they've sinced abandoned Elixir).

So I had the following tactical points, under "avoid genre tropes":

• Don't try to explain the headline features (BEAM's scheduler, supervisors, OTP, Phoenix channels…); like "dancing about architecture," you won't do a great job and most people will lose interest. Link out for the curious.

• Don't lean exclusively on those headline features as justification for the choice (because they weren't; not exclusively anyway).

• Advocate without sounding like a sycophant.

• Make it clear you understand what working with the other stacks looks like. If you have a case to make, compare it directly against Python/Ruby/Node. This establishes credibility for a few reasons, one of which is that fights against the argument that you're in an atypical language because you hope it'll save you from the horrors of programming.

• Those comparisons should apply to something that matters, actually. Most examples in posts like these showcase little features for writing a snippet or two of source code with less boilerplate; my example source was nonsensical, and it was a switcheroo: it was about what you didn't see, about global properties of a growing codebase.

• Connect on a human level. Again, my faith that a purely technical argument will retain or persuade visitors is low compared to an emotional argument around the act of building software. The Joe quote in the illustration, for example, resonates with anyone who writes in any language. The necromancer cartoons are downright funny.

Goal: Establish technical credibility

You're representing the engineering culture of a company, it's important you present informed and mature. Every interview is also an audition, for both sides: there's an evaluation whether the candidate's technical chops and company fit together, but both sides are also selling the idea of "wouldn't you like to work with someone like me on a regular basis?" Engineering voice in a blog is no different.

I did this a few different ways:

• Back everything up with hyperlinks to sources. Most people won't click them, but those that do will really appreciate it, especially if they're good reads.

• Establish bonafides as applicable: I have been an Erlang hacker for over a decade. I was at an Elixir meetup; cool, I'll use that photo. I namechecked the bolt-on typesystems of every other dynamic language in a photo caption. I link to a talk I gave on the subject at a very selective conference.

• Make original claims! ChatGPT couldn't write Elixir at Ramp because as far as I know, the section 3 points have never been expressed this way. Even the other stuff, it certainly couldn't do it in my voice (or always linking to sources correctly). Per "genre tropes" above, I suspect it could write a closer approximation of other ones.

• When connecting on a human level, do that right too When the plot twist comes, I link to tons of research. And again, it grounds the Ramp part of Elixir at Ramp.

Goal: Say something original!

Section three, I think I hit the ring just outside of bullseye. It's got a few winning lines for sure, but it suffered from the main risk areas of the post: cramming too much idea in too little space, and it coming out muddy. There are two claims I was trying to make, but I think it could have used just one or two more grafs to properly explain them. Compared to other comparable stacks (dynamically-typed languages that are popular with startups), Elixir also gives you:

• Enforced immutability, which means as your app grows there's an entire category of state nonsense you never have to worry about when editing code locally.

• A unique set of module contraints, and a mechanism for calling code in other modules without having to evaluate arbitrary statements in them (fully-qualified module, function, arg calls; a bit like dynamic dispatch). This means you can have two modules alias another without "circular import" dependency hell.

While these aren't wicked brand new insights (there are a million "immutability good!" articles, with very weak rationalizations), I can't remember when I've seen these to features called out specifically for the case of a growing dynamic language codebase. It's something almost everyone who's worked in big Python or Ruby codebases understands viscerally.

A little Sapo photo, around when Elixir at Ramp was written. My life looked pretty different then.

Goal: People, tech, and tie it back to the company (or: who doesn't love a plot twist?)

It's a bit awkward to write an entire post on The Better Tech Of Elixir (and, per my intentions, one of the better ones) while the fact is Ramp is mostly a Python company. Every alchemist at Ramp has had to write Python at some point, most Pythonistas haven't written any Elixir. This is unfortunate but not surprising; how this kind of thing happens is the subject for another, maybe surprisingly short post (most industry tech strategy is optimized for very, very local maxima, which looks like learning very few new things).

So what to do? Well luckily, while the position is awkward, the solution is simple: be honest. I walked into Ramp as employee 1 being like "ahhhh, greenfield!" but finding ~30k lines of co-founder/contractor code. I could have Been A Leader and said "ELIXIR BETTER! WE'RE MOVING IT ALL!!," but it was obviously a terrible idea for the people aspect, especially for a crew that's built amazing Python software before. You can also establish better credibility if you find the good in competitors, so I namecheck that I love Python too (I don't always, but Lord it does a few things very right).

I think a lot of people say "Use Boring Tech" as a credibility boost, since "Use Fun Hot Cool Tech™" wasn't a sufficient strategy in the late-aughts/early 2010s to save bad businesses. But I think this is a reaction in the wrong direction: the proper response is "People are what matter most." Just like the opposite of love isn't hate (it's apathy), "Use Boring Tech" is a medicine, but not for "Nonstandard tech as a disease." You can build amazing tech companies on atypical tech: BEAM systems have powered giant systems all over the world for two decades. Reminder how weird Ruby, as a language, is! It's now considered Boring, but after years of people being happy little nerds with it. When it exploded into the scene, it was a super-niche language.

I expand on it here, but "boring" is one strategy (risk minimization). You can persue a different one (gain maximization); what makes companies work or fail are people things. So I linked the research around effective employees and happy teams and say "as far as Ramp: yes we've got some Elixir, yes we've got Me The Informed Narrator, but most importantly we've got all this cultural awareness around what makes people happy at work."

I have a few other posts in me about how people actually skimp out on things that are objectively good for teams and their performance. There's little real science on this, but it's there, and it is real, studied science, with Experiments and Peer Review and all that (open office plans go against decades of research; I linked sleep research, also, sleep deprivation is literally a torture technique but we still have VCs pushing a culture of "sleep under your desk and Grind Till You Die," which many legendary hackers will remind you is bullshit; where is the talk of air monitors and good HVAC?). That begets another post about how most "value" in startups is just a weird theatre show instead of what it actually outputs. But we'll keep the talk on storytelling scoped appropriately here.

Easter egg

ElixirNYC meetup was hosted… at Brex NYC. So if you look at that photo, I'm wearing a Brex nametag 😉

Hope that helped! Let me know if you have any questions or reactions in the email or comments.