Why I Wrote the Beam Book

Summary

Why I Wrote the BEAM Book Post-mortems, coffee, and a decade of stubborn curiosity Posted: 2025-06-03 Why I wrote the Beam Book After ten years of keeping Klarna’s core system upright I know this: a 15 millisecond pause in the BEAM can stall millions of peak-shopping payments, trigger a 3 a.m. Christmas-Eve post-mortem, and earn you a very awake call from the CEO. I wrote The BEAM Book so the next engineer fixes that pause before the coffee cools. Origins I opened the project on 12 October 2012 with a lone DocBook file with four lines of text and an oversized sense of optimism. After two weeks, the commit log is mostly me adding structure, moving headings, and updating metadata. Most of it is scaffolding. The actual content is still just a few hopeful lines. By November I had abandoned DocBook for AsciiDoc, written a custom build script, and convinced myself the book could be wrapped up in six months. Those early commits glow with energy: adds, rewrites, then more rewrites to fix the rewrites. Delusion is underrated. In 2013 I managed to convince O’Reilly to publish. Moving the repo to their Atlas system sounded simple until Atlas began hiding my main file and overwriting half-finished chapters. The Git history reads like a diary of frustration: “Moving files to top level to cope with Atlas,” “Atlas seems to be overwriting book.asciidoc”. Word count shot past 120 000 while actual progress crawled. On 10 March 2015 I was literally “Smashing chapters into sections” just to keep the build green. The quiet cancellation came two months later. No drama, just a polite call and a line through the contract. Relief mingled with embarrassment, I had spent two years rearranging files rather than finishing sentences. Pragmatic Bookshelf took over that same year. I kept working in CVS for their production system, but progress was slow. Eventually, they cancelled too. On 20 January 2017, I imported everything into a new repo in one massive commit: 6,622 files, over a million lines...