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 201
