Ten Questions with Angus Croll, Author of If Hemingway Wrote JavaScript

I never thought I’d know how to code. Although I am a software engineer now, I studied history and literature in college and took a job in marketing after graduation. Working at a tech company made me hunger for engineering skills, so I resolved to learn programming.

My friends were shocked. One of them, upon hearing my plans for a career transition, recommended a book called If Hemingway Wrote JavaScript. “If any programming book is going to speak to a humanities type like you, it’s this one,” she promised. I purchased it.

Fast forward 14 months. I’ve just started an engineering role at Uber Eats, and I see a chat message flash across my screen from Angus Croll. The name rings a bell. Could it be the author of my first and favorite software book?

It was! Angus works on Uber’s Web Platform team, where he helped write the JavaScript that powers the m.uber mobile web app, among other key projects. Thrilled to realize we were colleagues, I reached out for a conversation about code, literature, and their intersections.

Have you always been a reader?

Yeah, I’ve always been really into literature. I probably prefer reading to writing code—I kind of ended up in software by accident.

How was your software career an accident?

I was working in a dead-end job right after college, then one day I applied for a job with a company that was willing to hire and train programming interns. At the beginning, I wrote software as a job, to get paid—I was just going through the motions. It was only after I discovered JavaScript that something clicked.

What was so enchanting about JavaScript?

I like it for its flexibility and its quirkiness; even though the syntax is really quite straightforward it can be adapted to multiple approaches: functional, objective, and procedural. It is common for one module to combine several approaches. Kind of like English or other spoken languages, you can get by with a relatively small vocabulary, and yet it’s highly expressive and continually evolving.

JavaScript is this unconventional language that computer scientists tend to look down on and disparage. It doesn’t have type checking, its equality checking is a little left-field, and it will coerce variables without asking. Maybe that quirky contempt for traditional languages is part of the attraction for me. It’s also very forgiving—your code can look like a dog’s dinner but it will still run—encouraging exploration of the language’s core mechanics, which in turn encourages experimentation and the development of new idioms. All of this helps keep JavaScript interesting and fun.

When did you start feeling the style of JavaScript?

It took a while. When you’re learning a language for the first time, and I’m sure you’ve felt this, you tend to be in panic mode. You think, I don’t really get this and other people do, and that’s stressful, so it’s not the time to experiment. When you first learn a language, you just want to be able to write it the same way other people write it. It’s like speaking a foreign language—you just want to fit in. But, after a year of working in a language, you’re comfortable enough to start getting creative.

It took a few years until my JavaScript started to get creative. My company at the time asked me to write a blog about JavaScript, and I started to go really deep into the language, because I didn’t feel I could write publicly about something I didn’t thoroughly understand. So I started studying the standards, the underlying specification for the JavaScript language. It’s this huge document—incredibly dry—and even understanding how just one operation actually works requires a lot of attention.

Slowly, piece-by-piece, I gained an understanding of the JavaScript engine and realized JavaScript did more than I thought. There were more edge cases and unusual things than I had realized. Think about browsing a dictionary and finding all these interesting words you’ve never heard of before—it felt like that. So that was cool, and as the blog developed, I began to push boundaries and start doing things with JavaScript that other people hadn’t done before.

How were others using JavaScript at the time?

Well, because JavaScript is flexible and lets you do a lot of things, you can get yourself into trouble if you’re not careful; you can write really bad code. There were people who set themselves up as leaders of the JavaScript community, and they argued that we should only use a subset of the language, because half of the language was quirky or difficult to understand and could lead to trouble. I didn’t like that. I thought, Hey, you’re dismissing some really powerful tools. Instead of ignoring them you should understand them (and once you understand them, you can use them).

For 90 percent of JavaScript programs, you can probably get by with the half of the language that’s widely accepted. But it’s so satisfying when you discover a utility from the other half of the language and it’s exactly the tool you need for the job. I gave a conference talk in Berlin in 2012 called “Break All The Rules.” It was controversial: I explored the JavaScript features that had been declared unsafe and showed how, used well, they are not only safe but very useful, and, moreover, are the foundation of some of the most popular libraries. The talk ended up being really successful.

So those two things, diving deep into the language and learning to think about it for myself, made me realize there’s a rich vocabulary out there that’s not being used to its fullest.

How did those experiences lead to the book?

I was constantly thinking about the expressive possibilities of JavaScript and their parallels to literature. I was in an IRC chat group with other programmers who loved literature and other creative forms, and one day one of the group members (Jacob Thornton, who wrote the foreword to the book) asked what I was up to and I said, “Oh, I’m trying to write JavaScript in the style of Hemingway.”

I wasn’t actually doing it— it was just an idea I’d been thinking about on the way into work, wondering if it was doable. But Jacob loved the idea and encouraged me to write a blog post about it. Over the next few days I wrote and rewrote the Fibonacci algorithm until I had something that resembled the style of Hemingway and several other authors, mostly the ones in the first chapter of the book, and published it as a blog. The post was hugely popular and even got mentioned in The New Yorker.

At the time I was already writing a serious JavaScript book for No Starch Press, a thorough reference to the language. I was getting burned out, so I asked if I could take a break from it and pursue this new book. The publisher was skeptical: “This won’t work, where’s it going to go in the book store even? Under literature? Under software?” I said, “it won’t take long—give me six months.” He agreed. It actually ended up taking me about a year, but that was including editing,  production, etc.

The book presents canonical algorithms as if they had been written by literary greats. Who were the authors whose styles were the most joyful to write?

I really liked writing Virginia Woolf — she’s one of my favorite authors. I used to find her writing difficult until I learned how to read her: don’t stop, don’t think too hard, just keep on reading. It’s like a stream of consciousness; chaotic, just like real life, and it will get under your skin if you let it in. Her sentences are so rich and tightly packed, often running on, that they can feel like statements in code. And although Woolf didn’t write much poetry, her prose is naturally poetic; you can arrange JavaScript to mimic some of those patterns. The bold, distinctive approaches of Vladimir Nabokov, Jorge Luis Borges, and Lewis Carroll (to name but a few) were also a lot of fun to mimic.

Were there any authors whose styles just didn’t work out?

The Russians: Tolstoy, Chekhov, and Gogol. I really love their writing, but they were just too hard because they’re quite subtle. It’s easier to mimic authors with highly distinct styles. Tolstoy and Chekhov definitely have their own styles, but they’re harder to nail, and I felt I didn’t have the skill to translate them into code. Toni Morrison was another author I spent a lot of time trying to get right, but ultimately failed.

What features of JavaScript did you feel you could tweak to achieve a distinct style?

I played with naming, comments, different ways of expressing functions. Different coding paradigms such as functional, objective, and procedural naturally fit some authors more than others. Also, the thing is, a lot of the best authors don’t stick to rules; they break rules the whole time. Arundhati Roy breaks the rules constantly and that’s why she’s so good. She’ll capitalize words all over the place and make up new words and just play with prose, and it makes me smile because people say, “Oh, you’ll never be a great JavaScript programmer if you don’t stick to the rules,” and I think, the best authors break rules all the time.

A lot of writing this book was about how to break the rules of JavaScript, and that’s why I wouldn’t recommend that people use most of the code from the book in their day job. Breaking rules is what authors do, and I set out to break the rules of JavaScript the way these authors liked to break the rules of literature.

What’s the reception of your book been like? Who have you seen that has been most excited about it?

I thought interest would mostly come only from the coding community, so it was exciting that it generated so much enthusiasm from people who don’t have a coding background, like the many people with a humanities background who have felt shut out from this whole tech thing. There’s this tech exceptionalism where tech people feel that we can use algorithms and data to solve everything and we don’t need humanities. That annoys me so much! And a big part of writing this book was reaching out to people in humanities and saying, “You have an important role here.”

In general, the diversity of people who have either tweeted at me or emailed me about the book is so much higher than the diversity of employees at most tech companies. Even if this book was just a tiny step towards broadening the diversity of people and approach in software, just by saying “Hey, you know, there’s another way to approach it,” that’s something I’m proud of.

Subscribe to our newsletter to keep up with the latest innovations from Uber Engineering.