<![CDATA[Ben Birnbaum]]>http://bbirnbaum.com/http://bbirnbaum.com/favicon.pngBen Birnbaumhttp://bbirnbaum.com/Ghost 3.13Tue, 07 Apr 2026 02:52:27 GMT60<![CDATA[What I wish I knew about email development before I started]]>http://bbirnbaum.com/what-i-wish-i-knew-about-email/600fdeae18d68429ca4069a5Wed, 27 Jan 2021 14:21:37 GMT

Call me old school, but I’m a big fan of email. That’s part of why I built Cortado, an app that allows you to create a custom daily email digest from sources like Twitter, Reddit, YouTube, RSS feeds, and Hacker News.

But while I love using email, I hate developing for it. There are endless combinations of providers and clients, standards suck, and at the end of the day, you can't even be sure your email will get delivered.

After a year of working on Cortado, however, I think I’ve finally learned how to make well-designed emails and get them reliably delivered to inboxes.

These are the lessons I learned along the way. My hope is that by sharing them all in one place, with links to tools and additional articles, I'll save others some of the pain that I went through.

Know what CSS and HTML you can use

Want to use flexbox? Nope. Change the opacity of an element? Forget it. Add a box-shadow? Not going to happen.

A user on Hacker News recently wrote this about email: “Imagine you're building a site with one foot in 1999 and another foot in 2016, but instead of 4-5 browsers you have around 20 highly-idiosyncratic browsers past and present to deal with.”

A consequence of this chaos is that many features from CSS and HTML are off limits, even ones that are widely supported for general web development. So try to include only the simplest CSS and HTML, and use resources like this guide from Campaign Monitor or caniemail.com to determine how widespread support is for the features that you do want to use.

Inline all style directives, and get a good library to help

Speaking of CSS, there’s really only one way you should use it in email, and that’s to inline all of it. That means no external CSS files, no <style> tags, and no selectors. Snippets of code like this are distressingly common:

<td style="font-weight:400; padding:0; font-family:Helvetica, Arial, sans-serif">
  <a target="_" href="https://github.com/GRVYDEV/Project-Lightspeed" style="text-decoration:underline; color:#151C1C">Show HN: Lightspeed - subsecond, open source, self hosted stream from OBS</a>
</td>```

If you're thinking that this looks like a pain to write, you’d be correct. Luckily there are libraries that can help. I’ve had a great experience with premailer, a Python library that processes selector-based CSS and inlines it into your HTML. And if you use Node.js instead of Python, you can try juice or inline-css.

Don’t rely on CSS inheritance

If you look carefully at the code snippet above, you’ll notice that the font is being set for an individual table cell. Why not set it for the overall table, or better, the <body> tag? This seems like it would be cleaner since you wouldn't have to repeat the font declaration for all of the cells.

The problem is that the email client can inject CSS that can interfere with inherited styles.

I ran into this issue when I was trying to ensure that Helvetica was used throughout my email. This is not my favorite font, but as we'll see below, options for email fonts are very limited, and I like it better than the typical defaults of email clients like Arial or Roboto.

All of my content was in a big table (again, see below for why), and I had inlined the directive font-family:Helvetica, Arial, sans-serif at the table level. But all of the text in the email, when viewed in the GMail web client, was in Roboto. Eventually, I realized that GMail loaded CSS that set the font for all <td> elements to Roboto. So I had to ensure that every single <td> tag had an inlined font directive with Helvetica to override GMail's behavior.

Party like it’s 1999 — Use HTML tables to format everything

In the 90s, when CSS was still in its infancy, developers commonly used HTML tables to format their content. Since CSS support is so spotty for email, that’s still the best way to get reliable layouts in email.

Here’s a screenshot of an email from Cortado:

What I wish I knew about email development before I started
Screenshot of a Cortado email, formatted with multiply-nested HTML tables.

I’m happy with how the alignment of this email turned out, but it required tedious work with multiply-nested tables to make it happen. For example, each of the gray bullets in the Hacker News section is a middle dot that occupies its own table cell.

For some further reading on best practices for using tables in HTML emails, I recommend MailChimp’s Email Design Reference or Campaign Monitor’s guide for coding an HTML email.

Choose one of eight fonts

Google and Adobe Fonts are great for web development, but you can’t use them for email. Most clients will block emails from downloading custom fonts, so you are stuck with choosing web safe fonts, those that are widely available across browsers and operating systems. Think Arial, Verdana, Helvetica, Georgia, Tahoma, Trebuchet, and Times New Roman.

One tip: consider using system-ui font family declarations if you want the email’s font to look consistent with the user’s OS. For example, I noticed that The Skimm, which has a great, clean design that I used for inspiration, has the following font family declaration:

font-family:-apple-system,BlinkMacSystemFont,Helvetica,Arial,sans-serif;

Dark mode is your enemy

Who doesn’t like dark mode? Well, after trying to design a reasonable looking email that looks good in both light and dark mode, I don’t.

There is a lot of variation in how emails are modified when viewed in dark mode. Some clients don’t change the email at all. Some partially invert the colors, and some fully invert the colors. This heterogeneity would be fine if you could use something like prefers-color-scheme to modify your CSS depending on whether or not the user is in dark mode. But support for this feature is thin.

I've found that this means two things:

  • All images should have transparent background
  • Any colored text or images should be easily visible against both dark and light backgrounds

The second bullet in particular is quite constraining. In practice, it seems to mean that most of the colors in the email (at least those that will appear against the background) need to be close to 0% or 50% luminosity. The ones close to 0% luminosity will get inverted in dark mode, so they will have high contrast in both light and dark mode. But other colors may not get inverted, so anything that’s not close to 50% luminosity will have very different contrast in light and dark mode.

A lot of what I learned about how dark mode affects email came from this helpful guide from Litmus, which has a bunch more useful content on how to deal with dark mode.

Test your email in multiple clients

Even if you follow all of the best practices for creating well-styled emails, there’s no substitute for testing how they look in several different clients. You can do some of this yourself by looking at test emails across a few desktop and mobile clients (in both light and dark mode). There there are also tools that can be helpful, such as Litmus and Email on Acid. Both are a bit pricey, at least for hobbyists or indie developers, but both have free trials.

Use DKIM to make your emails look legit

You may have noticed that some emails you get are marked with phrases like “sent via gmail.mcsv.net” or “sent via amazonses.com”. This happens when the sender’s domain doesn’t match the email provider’s domain. In addition to making your email look shady to the recipient, this can increase the chance that it will be marked as spam.

Fortunately, there’s a relatively easy way to avoid this. You can use the DomainKeys Identified Mail (DKIM) standard to sign emails and prove that they are from the domain they claim to be from. How to set this up varies by which email API service you use, but you can typically find the instructions by Googling “verify domain <service>” (e.g. “verify domain mailgun” or “verify domain sendgrid”).

Choose your email API service carefully

The first email API service I chose was SendGrid. My research process for choosing it was (1) going to its website because I’d heard of it, (2) ensuring it had the features I needed, and (3) noting the trustworthy shades of blue on its landing page. I didn’t give it much more thought because I assumed these services were basically a commodity. What could be so complicated about sending emails?

More than I thought, it turns out. Things went well with SendGrid for a while, but one day I started to hear from users that they weren’t receiving their emails. It turned out that SendGrid had flagged my account as suspicious, despite no major changes and no spam reports, and it had suspended my account to perform a review. This happened without warning, and it took Sendgrid's support team days to respond to my help desk ticket. Luckily, my account was resumed without explanation after about a day.

I assumed that this was an anomaly and didn’t give it much thought. But a few months later I had another issue, and this one caused a five-day outage. It started when I got reports that the emails from Cortado were getting marked as spam. At first, I had no idea how to debug this issue.

Eventually, I found a site called Sender Score, which shows you the reputation of IP addresses that are used to send email. This is an important signal that providers use when determining whether an email is spam — more important than, for example, the content of the email, which in my case hadn’t changed.

Like many email APIs, SendGrid sends emails from shared IP addresses for low-volume accounts. When I looked at some of the IP addresses that were getting used for my account, I saw a sudden drop in reputation, along with a sudden increase in volume. It appeared that a spammer was now using the same IP addresses I was using. I filed another ticket with SendGrid, and again the support team was slow to respond. Eventually, I complained on Twitter, which did get a response from SendGrid, but I was told they couldn’t do anything about it, and that I should pay to upgrade to a private IP address. This was not an option for me, since it would've been more money than I could have justified for a free service, and private IP addresses don't even work well for low-volume accounts like mine.

What I wish I knew about email development before I started
The time another sender tanked the reputation of my IP and sent all of my emails to spam.

After five days of this outage, I had no option but to change my email API service. This time, I did more research, and I eventually settled on MailGun because it had a good reputation and was inexpensive. It took a few hours to make the switch. Luckily, after a few months, I haven't had any issues with MailGun.

I share this lesson not to throw shade on SendGrid. I’d imagine they just don’t prioritize smaller customers like me. And I’m sure MailGun isn’t for everyone. But it's important to research the email API service you choose, since it can be pretty annoying if things go wrong.

To research the reputation of an email API service, you can search around on Twitter or check review sites like g2 or capterra.

Tools and further reading

For convenience, here are all of the links from above in one place:

]]><![CDATA[When you might die]]>As a side project, I built whenyoumightdie.com, a website that helps you visualize the uncertainty around when you might die. I built this not as a gratuitous exercise in morbidity, but rather as a way to remember that there's no time to waste.

]]>http://bbirnbaum.com/when-you-might-die/5ffc2bf418d68429ca406945Mon, 11 Jan 2021 10:49:30 GMT

As a side project, I built whenyoumightdie.com, a website that helps you visualize the uncertainty around when you might die. I built this not as a gratuitous exercise in morbidity, but rather as a way to remember that there's no time to waste.

]]><![CDATA[My favorite books of 2020]]>http://bbirnbaum.com/favorite-books-i-read-in-2020/5fe9feac18d68429ca40686aTue, 29 Dec 2020 01:53:52 GMT

It was hard to find the time and headspace to do a lot of reading this year (for obvious reasons), but I did manage to read a few good books. Here are some of my favorites.

Command and Control: Nuclear Weapons, the Damascus Accident, and the Illusion of Safety

by Eric Schlosser (link)

My favorite books of 2020

This history book about the Cold War had me shaking my head, wondering how we survived the twentieth century. Schlosser interleaves a detailed play-by-play of an accidental 1980 explosion in an Arkansas nuclear missile silo with a broad history of the United States' oversight of its nuclear arsenal from the 1940s until the end of the Cold War. He describes how close we came to catastrophic nuclear accidents multiple times in that period. In one incident, for example, a hydrogen bomb was accidentally dropped on North Carolina, and all but one of the arming mechanisms triggered. At 640 pages, it’s a bit long, but it's very engaging. I wrote more about this book here.

Station Eleven: A Novel

by Emily St. John Mandel (link)

My favorite books of 2020

When the pandemic started, I, like many people, found it strangely soothing to expose myself to vivid depictions of worst-case scenarios. This book functioned perfectly. It takes place in a world twenty years after a deadly new disease has wiped out most of civilization. It follows a group of actors traveling through a dangerous and wild Great Lakes region. Interwoven into the main storyline are flashbacks to the world before and during the pandemic, including an especially vivid and terrifying sequence imagining what would happen if the vast majority of people in a major city died within a few days. Mandel has described this work as a love letter to civilization. After reading it, I certainly have a much greater appreciation for early 21st century life.

The Biggest Bluff: How I Learned to Pay Attention, Master Myself, and Win

by Maria Konnikova (link)

My favorite books of 2020

I’ve loved poker ever since high school when I first watched Mike McDermott take down Teddy KGB. So I was excited to read The Biggest Bluff, a memoir by Ph.D. psychologist Maria Konnikova that describes her journey from poker novice to elite tournament winner. What makes the book so compelling is not just the story itself (which is great) but also how Konnikova shows how we can apply lessons from poker to live a better life.

Ultralearning: Master Hard Skills, Outsmart the Competition, and Accelerate Your Career

by Scott Young (link)

My favorite books of 2020

My mid-thirties have been marked by an increasing appreciation for the shortness of life. I’ve now spent as much time being an adult as a child, so I can understand, in a way that I couldn’t before, how soon 40, 50, and 60 will (hopefully) come. One of the best tricks I’ve found to avoid feeling down about this is to learn new things. As Henry Ford wrote “Anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning stays young.” Perhaps that’s part of why I was so excited by this book, which is part manifesto, part guidebook for lifelong self-directed learning of challenging topics. Young’s strategies for effective learning originate both from cognitive science and from his own experience, such as teaching himself MIT’s 4-year computer science curriculum in 12 months.

Capital in the 21st Century

by Thomas Piketty (link)

My favorite books of 2020

Could this book be shorter? Yes. Do I feel slightly pretentious including it in this list? Yes. Did it change my understanding of what some of the world’s biggest problems are? Also yes. Using simple arguments and lots of data, Piketty makes a compelling case that wealth inequality usually tends to increase, that the reduction in inequality in the 20th century was a blip caused by the two World Wars, and that without fundamental changes to tax structure, inequality will continue to increase almost indefinitely. Along the way, he explains fundamental economic concepts in a clearer way than I’ve seen almost anywhere else.

]]><![CDATA[How a side project has made me a better manager]]>When I was first asked to be a software engineering manager, I knew that saying yes would come with tradeoffs. On the one hand, it would be a chance to have more impact, mentor people, and develop my leadership skills. On the other, it was a job change: instead of

]]>http://bbirnbaum.com/how-a-side-project-has-made-me-a-better-manager/5f7dd39318d68429ca406858Wed, 07 Oct 2020 14:44:34 GMT

When I was first asked to be a software engineering manager, I knew that saying yes would come with tradeoffs. On the one hand, it would be a chance to have more impact, mentor people, and develop my leadership skills. On the other, it was a job change: instead of solving technical problems myself, I would be helping others do the problem solving.

I said yes, and I’m happy I did. Being a manager has been rewarding. I like the variety of the job, being involved in a bunch of different things at once, and helping people. But I do miss the creativity and concreteness of building things myself. Some managers find time to code on the job, but for me it’s usually seemed more impactful to step back and focus on enabling others.

So, a year ago I decided to start a side project. It’s called Cortado. It’s a website that allows users to create a personalized daily email with content from sources like RSS feeds, email newsletters, Twitter, Reddit, YouTube, and Hacker News. I built it to solve a problem in my own life, which was that there were a bunch of information sources I wanted to read every day, but they existed across platforms, and there wasn’t an easy way for me to keep up without getting sucked into a bunch of feeds and losing hours of my time.

Cortado has given me a chance to do what I missed from my job: writing and shipping code. And I do it with complete autonomy. I prioritize what to work on, design the UI, and talk directly to customers myself.

Now, I don’t miss doing this stuff at work as much, and -- to my surprise -- I think the side project is actually making me a better manager. I’m no longer as tempted to write my own code or unnecessarily inject my own taste into technical discussions. I can retain my identity of being someone who builds things without having to reinforce that identity in counterproductive ways at work. I can, in the words of Molly Graham, “give up my legos” without it feeling like a loss.

There have been other benefits. For one, working on Cortado has helped me stay up to date on technology. It has exposed me to Lambda, DynamoDB, CloudFormation, Docker, Heroku, React, and Webpack. Now, I can be prepared to contribute to discussions when these technologies are mentioned in a work context. Instead of faking my way through them, I can speak from a place of deep, experiential knowledge.

Another benefit is that I’ve increased my understanding of non-engineering jobs. With Cortado, I play the role of individual contributor, product manager, designer, customer support specialist, and marketer. This increases my empathy for people in these functions at work. I experience how hard it is to predict how long a bug will take to fix, how hard it can be to get simple things to work. So I remember to cut my reports slack when things take longer than expected. I experience how hard it can be to prioritize things when everything feels important, how there is often a direct short-term tradeoff between building things the right way and solving problems for customers. So I remember to empathize with product managers when we are discussing difficult tradeoffs. And I learn that without marketing there are no users. So I develop a deeper appreciation for the sales and marketing teams who ensure that I actually have a job.

Of course, nothing comes for free, and the cost of a side project is time. Not everyone wants to, or can, spend their time outside of work coding, designing, and marketing a side project. I have two small kids, and it’s important to me to spend lots of my non-work time with them. So making progress on a side project has required me to step up my time-management game significantly. For me -- to be honest -- this has mostly meant streaming fewer TV shows.

I’ve also had to be patient. I can only spend a few hours on the project each week, which means that progress goes more slowly than I want it to go. But in this case having kids probably helps: if they’ve done anything for me, they’ve helped me become more patient!

People often ask me if, as an engineering manager, I miss coding. I used to say yes but that the tradeoffs were worth it. That was true. But now I don’t need to hedge. I don’t miss coding because I don’t have to give it up. And the coding that I’m doing isn’t distracting me from being a better engineering manager. It’s helping.

]]><![CDATA[When you find out you’re the copycat]]>http://bbirnbaum.com/when-you-find-out-youre-the-copycat/5f20c76218d68429ca4067fcWed, 29 Jul 2020 10:00:00 GMT

It was a rollercoaster of a week. It began when an article I wrote about my side project, which I’d been quietly building for seven months, unexpectedly made it to the number two spot on Hacker News. It ended with me considering whether I should give up on the project completely.

The side project is called Cortado. It’s a website that gives users control over their information intake by letting them create a customized daily email from sources like Twitter, Reddit, RSS feeds, Hacker News, and more.

Over the course of 24 hours, ten thousand people read my article. About one hundred of them clicked through to Cortado’s landing page and signed up. My user base grew from a handful of family and friends to more than a hundred strangers from across the world. These new users were giving me great feedback, saying nice things about the service, and sharing helpful criticism.

I was thrilled that something that I made for myself, something that I wasn’t sure anyone else would want, seemed to be solving a real problem for other people. I couldn’t wait to improve the product and grow my user base more.

But my excitement didn’t last long. The next day I noticed an email from a service called Mailbrew in my inbox. I didn’t give it much thought because I didn’t remember signing up for a something of that name. I assumed the email was spam and archived it. But the following day I got another email from Mailbrew, and this time I opened it.

It was a digest of sources from Twitter, Reddit, and RSS feeds about entrepreneurship. It felt familiar.

I clicked through to mailbrew.com and found a product just like Cortado. Even the copy on the landing page was similar. The term “information diet” was prominently displayed, and the two projects shared a coffee-inspired name.

But Mailbrew was much further along. It had more features, better-formatted emails, and wider visibility. I was really impressed by what the creators had accomplished.

My first thought, however irrational, was that Mailbrew must have been inspired by Cortado. Of course that was impossible -- it couldn’t have been so far along if that were the case -- but the idea was just so similar. Soon, however, I realized that the creators had launched their product quite visibly months earlier. In fact, the reason their email showed up in my inbox in the first place was that I had previously subscribed to a product built by them called Unreadit, which had morphed into Mailbrew after the launch.

I had already been working on Cortado for months before Mailbrew launched, but my progress had been slow (I have a full-time job and two small kids), and I hadn’t yet gotten any users apart from family and friends.

So it looked like I was the copycat.

I was bummed. Here I was, poised to double down on my side project and turn it into something bigger, fresh off of an unanticipated burst of validation, when I found out that not only did I have a formidable competitor, but also that I was the unwitting imitator.

Of course, there’s nothing wrong with seeing a good product and trying to improve on it, but it’s nice to at least know what you’re getting into up front. If I had known about Mailbrew before I started, I might have just signed up for it instead of investing hundreds of hours building my own product.

I considered my options: I could stop working on Cortado completely, I could find a way to pivot the product to distinguish it from Mailbrew, or I could simply press on, continuing to improve Cortado and grow its user base.

My first instinct was to stop. I wasn’t that interested in competition, especially when I was second to market. I couldn’t see how I could ever catch up to Mailbrew given my time constraints. But after some thought, I realized I wasn’t ready to stop. I couldn’t give it up just days after I had gotten my first real users, many of whom were telling me how much they liked it.

Next, I thought more about pivoting. But I was already building the product that I wanted, the one that was solving my own problem and that was apparently also solving a problem experienced by others. A pivot immediately after this positive feedback didn’t feel right.

So finally I decided to continue with Cortado, focusing on building the best product that I could for my users. Cortado would of course continue to evolve as I got more feedback, but any pivots would be based on what users were telling me instead of on what another product was doing.

That was two months ago. Since then, I’ve talked to a number of users and worked to address their feedback. Some people I've talked to have also used Mailbrew, and I've learned that one of Cortado's main selling points is simply that it’s free. So that’s at least one concrete difference between Cortado and Mailbrew. We’ll see what others develop.

The truth is I don’t yet have full clarity on what distinguishes Cortado from Mailbrew. I do know that I don’t want to stop building and growing Cortado, that there’s plenty that I can still learn from this project, and that it can’t hurt for users to have more choice.

Six months from now, I expect it will be more clear what makes Cortado unique. But the way I will get there will not be by focusing on a competitor. It will be from talking to users, responding to their feedback, and building the best product that I can.

Thanks to Yaw Anokwa, Josh Haimson, and Jenny Klein for providing feedback on drafts of this post.

]]><![CDATA[Strategic procrastination: keeping my perfectionism at bay]]>http://bbirnbaum.com/strategic-procrastination/5ef1edc218d68429ca4067a6Wed, 01 Jul 2020 01:24:54 GMT

Most people have more to do than time to do it.

The Eisenhower Prioritization Matrix is a conceptual tool for time management that can help people decide what to work on. It’s a 2x2 matrix with urgency on one axis and importance on the other.

Strategic procrastination: keeping my perfectionism at bay

Urgent and important tasks, the thinking goes, should be done right away. Non-urgent but important tasks should be scheduled. Urgent and unimportant tasks should be delegated. And non-urgent, unimportant tasks shouldn’t be done at all.

The insight behind this matrix is that people often spend too much time on urgent tasks and not enough time on important tasks. So by delegating urgent but unimportant tasks, you can free up time for important things you might not get to otherwise.

I’ve found this tool to be helpful in reminding me to focus on what’s important. But it doesn’t address another problem I have: even if I’m only working on what’s important, always starting with what’s most urgent can mean that I don’t have enough time for less urgent tasks. I’m too much of a perfectionist.

For example, when I start work in the morning, I almost always need to spend some time preparing for my meetings that day. This work is both urgent (they are happening today) and important (no one else can do it). So by the logic of the Eisenhower matrix, preparing for these meetings should be the first thing that I do.

But when I follow this reasoning, I often find myself putting too much time into the meeting prep. I might second-guess what I’m doing, spend too much time researching something tangential, or get distracted by a topic unlikely to come up in the meeting. So instead of always prioritizing what's most urgent first, I've learned to practice "strategic procrastination": purposely delaying urgent tasks to constrain the amount of time that I can spend on them.

For example, at the beginning of my morning at work, I might estimate how much time I’ll need to prepare for my meetings and then delay starting that work until I have exactly that amount of time left. Before then I’ll work on one of my other, less urgent tasks. In this way, I’m leveraging the urgency of a task to limit how much time I spend on it.

Strategic procrastination is also useful on longer time scales. When I have to prepare a presentation, for example, I often find myself wasting time on minor things, like tweaking formatting, instead of developing the core content. To avoid this I employ strategic procrastination. I delay starting work on the presentation until I have just enough time to complete it.

I sometimes adjust this method when the task requires creativity. Instead of completely delaying when I begin a task, I get started right away, but I do just enough to begin thinking about it. For a presentation, I might first spend 30 minutes writing a rough outline and then put the task aside for a few weeks. This gives me a chance to ruminate on it during downtime, and I often get ideas that I wouldn’t have gotten otherwise.

There is actually some experimental evidence behind my intuition that this approach can improve creativity. As described in this paper and in the book Originals (which also uses the term “strategic procrastination”), students who played video games for a moderate amount of time while working on business problems came up with more creative solutions.

Strategic procrastination comes with a major risk, of course. There’s a reason that it’s usually considered good advice to not wait until the last minute to do things. If I misestimate how much time I need to perform a task, then I either need to scramble to complete it or the quality will suffer. So strategic procrastination is only a good idea when I’m confident about long it will take or if it’s not a big deal to underperform.

As long as I consider this risk, strategic procrastination has been a helpful tool to make sure I have enough time for important but non-urgent tasks. Sometimes waiting until the last minute is exactly what makes me the most productive.

]]><![CDATA[Contingency and the Cold War]]>http://bbirnbaum.com/contingency-and-the-cold-war/5ec01a5918d68429ca406724Wed, 20 May 2020 00:37:57 GMT

I recently read the 2013 book Command and Control: Nuclear Weapons, the Damascus Accident, and the Illusion of Safety, a well-sourced account of the Cold War by the journalist Eric Schlosser. The book makes it clear what a miracle it is that humanity survived the Cold War intact. Here are some weird and terrifying facts I learned:

  • There were several incidents in which American hydrogen bombs almost blew up by accident. The book focuses on one of them, in which an ICBM exploded inside of an Arkansas silo in 1980, launching its nine megaton warhead hundreds of feet into the air before falling nearby (and thankfully not detonating). But that's not the only — or even the scariest — accident described. In 1958 a bomber was performing runway maneuvers at an airbase in Morocco while carrying a ten megaton hydrogen bomb. A tire blew and the plane caught fire, leaving the soldiers at the base with nothing to do but jump into their cars and speed into the desert, hoping not to see a mushroom cloud behind them. And in 1961 a bomber crashed over North Carolina and ejected its hydrogen bomb. All but one of the arming mechanisms on the bomb activated, and most of the Eastern Seaboard was saved by a single electrical circuit.
  • There were multiple false alarms in which American commanders thought Russia was starting a nuclear war. In one 1960 incident, for example, a detection site in Greenland reported with “99.9% certainty” that the Soviet Union was launching a massive attack against the U.S. The Joint Chiefs of Staff were notified that they had minutes to respond before risking annihilation. But then an American officer remembered that Khrushchev was in New York that day, making it unlikely that Russia was launching a preemptive strike. It was declared to be a false alarm. Later, the cause of the alarm was discovered to be a computer glitch in which the rising moon was mistaken for dozens of long-range missiles.
  • During training exercises, the Air Force often pretended to drop nuclear bombs on American Cities. Rhinelander, Wisconsin was a favorite, since its snow-covered terrain looked like the Soviet Union. And San Francisco was fake-bombed six hundred times in a single month.
  • Nuclear weapons weren't only put on top of bombs and missiles. There were nuclear land mines, depth charges, and even the "Davy Crockett," a nuclear rifle that NATO planned to use if Russia invaded Europe by land.
  • The Secretary of Defense was so worried about Nixon's mental health in his final days of office during the Watergate scandal that he made sure Nixon couldn't launch a nuclear war without his permission.
  • It is thought (though accounts vary) that in the 1980s, the Soviet Union built a system called Dead Hand that could launch an all-out nuclear war automatically. Soviet commanders could arm this system when they thought a nuclear strike was imminent. Then if it detected an attack, it would launch a massive retaliation with little or no human intervention required.

What stood out most to me from the book was the dizzying contingency of it all. What if that last electrical circuit in the bomb in North Carolina had malfunctioned and the thermonuclear payload had detonated? What if Khruschev wasn’t in New York the day that American commanders thought they detected a massive nuclear strike? What if the Soviet system for automatically launching nuclear war had a computer glitch that triggered it by accident? These scenarios are not implausible, and any one of them could have destroyed a city or even caused a nuclear war.

And now, just as much as then, it must be contingency keeping us from the brink. Nuclear weapons haven’t gone away, and they are not the only danger. SARS didn’t turn into a pandemic in 2003, and neither did Ebola in 2014. But coronavirus in 2020 did. Why? Randomness, at least in part. Just like the randomness that led to us surviving the Cold War. We should think of the near misses of that era to help remember the potential for dramatic and catastrophic surprises ahead.

Thanks to Jenny Klein and Stan Birnbaum for reviewing drafts of this post.

Image credit: Satellite watchers in the Space Computational Center, NORAD Headquarters. https://nsarchive2.gwu.edu/nukevault/ebb371/

]]><![CDATA[Two lessons on reducing sign-up friction]]>http://bbirnbaum.com/two-lessons-on-reducing-sign-up-friction/5eb8a5c818d68429ca40668dWed, 13 May 2020 14:20:00 GMT

Update: This article made it to the front page of Hacker News. Comments here.

I’ve been working for the past few months on a side project called Cortado. It’s a website that helps to give you control over your daily information intake. You can create a personalized daily email with content from RSS feeds, email newsletters, Twitter, Reddit, Hacker News, and a growing list of additional sources. The goal is to put everything you need, and nothing more, in a single place that you already go to every day -- your email.

A month ago, when my user base was still just a few family members and friends, I decided it was time to get at least one user I didn’t already know. I posted about Cortado in a few forums, and eight people signed up. Not a big number, but it was exciting to have people I had no connection with using something I had built.

More importantly, I learned the hard way how important a carefully designed sign-up process is. I saw a large percentage of interested people fail to sign up because of easily preventable flaws in the flow. Two lessons in particular stand out:

  1. Don’t require a user to be interested twice
  2. Email verification messages should take two seconds to read

Lesson 1: Don’t require a user to be interested twice

The sign-up section of my landing page used to look like this.

Two lessons on reducing sign-up friction
What the sign up form used to look like.

Users couldn’t get started on their own. They had to first leave their email address and then wait for me to send them an email with a link allowing them to register and start building their Cortado email.

My motivation was control. I was concerned about bots, and I was worried (unrealistically) that I’d get too many users too quickly. But a lot of people who left their email address didn’t actually register once they received the verification. After one of my posts climbed to the top of a small subreddit, 16 people signed up. I sent registration instructions to all of them within 8 hours, but only 6 people clicked the link in that email.

I had required people to be interested twice. First, they had to be interested enough to provide their email, and then they had to be interested enough to click through the verification message. Only 38% of people did this. If I had instead captured everyone as soon as they showed enough interest to leave an email address, I could’ve increased my conversion rate by 250%.

I’ve since decided that it’s better to have users than control. This is what the sign-up section looks like now.

Two lessons on reducing sign-up friction
What the sign up form looks like now.

As soon as users click the submit button, they get an email verification message in their inbox, which they can click on to set a password and get started. To retain some control, I put this permissive sign up flow behind a feature flag, and to help protect against bots, I added a reCAPTCHA. Now people only need to be interested once to sign up.

Lesson 2: Email verification messages should take two seconds to read

At first I didn’t put much thought into the content of the email verification message because it didn’t seem very complicated. All I needed was a secret link for users to click and instructions to click on it. What could go wrong? A lot, it turns out. Here is what the first version of my email looked like.

Two lessons on reducing sign-up friction
The first version of the email verification message

It seemed simple enough to me, but when I sent this email  to a friend he clicked on the “Cortado” link in the first sentence. This sent him to the landing page instead of the sign-up page. He texted me saying my website didn’t work. I told him to try the other link, but it took him a couple of days to get to it and actually log in. If he wasn’t my friend, I would have lost a user.

My friend spent two seconds reading the message and clicked on the first link he saw. I do the same thing. So I removed the extra link in the next version of the message. (I also added a friendly sentence asking for feedback because, well, I wanted feedback.) Here is what the new message looked like.

Two lessons on reducing sign-up friction
The second version of the email verification message

Now there was only one clickable link (not counting the one that’s obviously an email address). But there was still a problem: it was too hard to see. In fact, one user missed it entirely. After reading the email, he told me that there was no link. Totally understandable when you just spend two seconds reading. I was lucky that he emailed me. Most users would have just given up.

The fix was straightforward: make the link more obvious. Here is what the new version looks like.

Two lessons on reducing sign-up friction
The third, and final, version of the email verification message

Much better, no? The thing you are supposed to do is the first thing you read. Hard to miss, even in two seconds.

Have my changes helped?

It seems so. After implementing them, I posted a link to Cortado in Hacker News. I didn’t hear about any problems with the sign-up flow this time around. And the numbers, while small and subject to sampling bias and other confounders (including some changes to my landing page), support this conclusion. About 50 people clicked on the Hacker News link, and 9 of those people registered, an 18% conversion rate. In contrast, it took me 120 clicks to get the 6 registrations from my last marketing effort, a 5% conversion rate.

I’m encouraged by this improvement, and I’m excited for what I’ll learn next in the quest to find new Cortado users.

]]><![CDATA[Cortado]]>I built Cortado to make it easy to stay up to date with refreshing your feeds all day. It's a web app that gets the latest content from sources like Twitter, Hacker News, Reddit, and Youtube, and sends them to your email in a single daily digest.

]]>http://bbirnbaum.com/cortado/5ffc296218d68429ca40691dMon, 11 May 2020 09:35:00 GMT

I built Cortado to make it easy to stay up to date with refreshing your feeds all day. It's a web app that gets the latest content from sources like Twitter, Hacker News, Reddit, and Youtube, and sends them to your email in a single daily digest.

]]><![CDATA[Run visualization]]>Toward the end of 2014, I decided to take a break from running the same routes and instead systematically run on every street in a region around the Prospect Park. The animated visualization of these runs is surprisingly pleasing.

]]>http://bbirnbaum.com/run-visualization-2/5ffc30b718d68429ca406977Sat, 14 Jan 2017 11:04:00 GMT

Toward the end of 2014, I decided to take a break from running the same routes and instead systematically run on every street in a region around the Prospect Park. The animated visualization of these runs is surprisingly pleasing.

]]>