Just over six months ago, I started my own business. I was terrified.

But I’m happy to say the first half-year of The Andrew McGill Company has been really rewarding: Five great clients, challenging projects, and time to pursue my own passions (more on that soon!)

Somehow, new entrepreneurs are now reaching out to me for advice. I thought I didn’t have much to offer. But I’ve realized that starting a business is like learning any new skill – the early stages are filled with growth, and that’s worth sharing.

So I’m evaluating my thoughts through a matrix: from Surprising to Expected, and a Big Deal to a Little Deal.

## Surprising big deal: Your business at six months will not be the one you expect.

When I started my company, I figured I’d spend my time designing interactive experiences and stories. Instead, most clients want my help prototyping new products or building a business strategy — which has been far more rewarding.

## Unsurprising big deal: Starting a business is an emotional roller coaster, and building out your runway is the only antidote.

In the first few weeks of The Andrew McGill Company, one promising conversation would put me on top of the world, and a single discouraging word would send me back to the bottom.

That changed as I started earning money. I started with three months runway. The magic number for me was six months. I felt calmer, and I also had the confidence to turn away work — to focus on the projects that had the most value to me.

## Surprising small deal: Administrative work and menial tasks are way more bearable when they’re for your own business.

I’ve always hated submitting expenses. When I worked at Politico and The Atlantic, I’d put it off forever.

And yet — I now love opening Quickbooks and categorizing my spending.

My explanation? I’m now doing these things for myself. It’s not a hoop I have to jump through for someone else: It’s building my own wealth.

## Unsurprising small deal: it helps to enjoy business development when you’re developing a business.

My biggest fear in starting my company was that I’d be terrible at finding clients, or that I’d dislike doing it. I “hated networking” and how transactional it felt — I’d rather just have a conversation!

Well, that’s what business development is. I’m constantly having calls and conversations that could be categorized as “warm leads.” But I never consider these talks as me playing salesman. I’m listening to someone tell me about a problem they have.

It turns out that I really enjoy this! But on the flip side, if I didn’t — I would be utterly screwed. Business rarely falls in your lap. You have to seek it out.


(_Want to jump to the finish? [Here’s the newest game.](http://static.mcgill.cool/gpt-games/market-day/index.html)_)

As of the time of this writing, OpenAI has *********just********* opened broad access to its powerful DALL-E 3 image generation service. 

(And dropped the cost of GPT-4!)

This means that instead of manually asking ChatGPT for a cool pixel-art image, and getting them one at a time (like the title image for this blog post)...

...I can write a script to roll out dozens of images at once.

<figure class="bump-out">
    <img
        src="/images/blog/2023-11-02-point-and-click-adventure-game-gpt-ai/grid.png"
        alt="A three-by-three-grid of different pixel art scenes."
    />
    <figcaption>DALL-E 3 via API.</figcaption>
</figure>

Growing up, I loved [Maniac Mansion,](https://en.wikipedia.org/wiki/Maniac_Mansion#) a point-and-click adventure from LucasArts. Honestly, it was little too difficult for an eight-year-old. But I spent hours exploring that creaky old mansion — a perfect example of how games can transport you to a new world.

So! The time is right to make a **point-and-click adventure game** of my own.

## How I built it

Unlike my [last game,](https://mcgill.cool/blog/2023-11-02-ai-experiments-in-gpt-text-adventure-games) this game can't use a live OpenAI connection. For one, **generating images is expensive** — each image costs around 8 cents (though I could economize a bit probably). DALL-E 3 is also pretty slow.

That means I had to build a **completely static game** — something closed-ended that could be baked out ahead of time. 

It’s not *truly* the generative game I’m looking for, where everything is possible and every experience is unique. But… this is an experiment! And it’s still cool!

So how do I structure it?

The point-and-click games of my youth had a few common mechanics:

- **Rooms.** Whether you’re exploring a dungeon or the depths of space, you’re still moving from one setting to another.
- **Actions.** Some rooms should have stuff for you to do or take.
- **Obstacles and goals.** This can’t be a frictionless romp — you need a thing you’re pursuing, and some hardship along the way.

Of course, there are a million other things to consider — non-player characters, events, etc.

But with this in mind, I wrote a script using GPT-4 and DALL-E to do the following: 

## 1. Generate a game premise based off a prompt. 

My first prompt was simply “You’re in a haunted house.” GPT-4 spun this up: 

> In the dead of night, you find yourself standing before the crumbling gates of the notorious Ravenwood Manor, a once elegant estate now whispered to be haunted by the spirits of its former inhabitants. Your goal is to uncover the secrets of the manor and put the troubled spirits to rest.

Spooooky!
    
## 2. **Build rooms.** 

I specified the number of rooms and asked GPT-4 to generate and connect them. That resulted in a network like this: 

<figure>
    <img
        src="/images/blog/2023-11-02-point-and-click-adventure-game-gpt-ai/flowchart.png"
        alt="A flowchart showing the network of rooms in the game."
    />
    <figcaption>Don't get lost!</figcaption>
</figure>
    
## 3. Add actions to the rooms.

I asked GPT-4 to throw in some verbs where it made sense — “examine bookcase,” “pull lever.” 

Some actions required the player to do other things first — you can’t pull the secret lever until you search the bookcase, for instance. 

Sometimes these actions open rooms the player couldn’t access before, like a hidden chamber.
    
## 4. Build the images.

I wrote a basic prompt defining the pixel-art style I wanted. Otherwise, I let DALL-E interpret the room descriptions as it wanted.
    
So this description: 

> The unkempt Garden is filled with the ghostly silhouettes of dead trees and tangled underbrush. Moonlight eerily illuminates a path leading to a decrepit gazebo. The Kitchen door lies to the north, and a moss-covered path leads west to the Study.

Became this:

<figure>
    <img
        src="/images/blog/2023-11-02-point-and-click-adventure-game-gpt-ai/gazebo.png"
        alt="A Gazebo matching the above description."
    />
    <figcaption>Gothic!</figcaption>
</figure>
    
## 5. Use GPT-4’s new vision capabilities to identify the clickable portions of the room. 

I submitted the DALL-E image along with the list of exits and actions, and asked GPT-4 to identify where everything was in the picture so I could drop interaction points

## 6. Drop the game data and images into a front-end.

I coded a simple front-end that reads the game data, renders the images, places click targets, etc.

## So.... how’d it turn out?

Well… it turned out *****okay.***** 

I got games!

<figure class="bump-out">
    <img
        src="/images/blog/2023-11-02-point-and-click-adventure-game-gpt-ai/haunted-house.png"
        alt="A grand staircase in a decrepit foyer."
    />
    <figcaption>Spoooooky.</figcaption>
</figure>

And they ****work**** — you can click around and try stuff and eventually win. Here’s a few to try: 

- [Escape from the White House](http://static.mcgill.cool/gpt-games/white-house/index.html)
- [The Mystery of the Haunted House](http://static.mcgill.cool/gpt-games/haunted-house/index.html)
- [Lost in Space](http://static.mcgill.cool/gpt-games/spaceship/index.html)

But … they’re not completely fun. They're monotonous and confusing — you wander around and eventually win. (And GPT-4 Vision is [really bad](ttps://platform.openai.com/docs/guides/vision) at placing the click targets.)

## Making it better

I gotta confess: I got a little obsessed with this project 😬

It goes against the spirit of shipping quickly, but I ******really****** wanted these games to be more fun.

I found that they ******could****** be… if you’re willing to be a lot more specific in the prompt and do a bit of editing afterward.

**Introducing “A Trip to the Fantasy Marketplace.”**

<figure class="bump-out">
    <img
        src="/images/blog/2023-11-02-point-and-click-adventure-game-gpt-ai/market.png"
        alt="A bustling pixel-art marketplace."
    />
    <figcaption>Get yer magic amulets here!</figcaption>
</figure>

Here’s the prompt:

> You are a young child in a fantasy adventure (King Arthur setting) who has been sent to the market to get three items:
> 
> 1. A bunch of eggs
> 2. Some rope
> 3. A gift for your grandmother.
> 
> You cannot go home until you get these three things.
> 
> You might encounter a man selling magic beans. If you buy them, you lose the game.
> 
> You can steal the eggs, but if you steal the rope, you're caught and lose the game.
> 
> You can also buy things if you find coins or other goods to trade.
> 
> When you have all the things, you can return to the start of the game and complete a "Leave the market" action.

This actually feels like a real game. There are **goals.** There are **obstacles.** There’s a bit of **narrative.**

Now, this isn’t how GPT-4 actually generated the game. There was no magic bean merchant, and I didn’t get an option to steal the rope.

But there was a lovable urchin and a shopkeeper willing to sell you a locket. With some minor editing (clearing up some weird conditions, linking two quests together) I was able to turn this into a pretty fun little game.

## Final thoughts

Looking back, I went into this project with two secret rules for myself:

- I couldn’t edit the game files after GPT-4 made it;
- I could only offer a simple narrative prompt, like “You’re on an abandoned space station.”

These are both kind of dumb! 

If artificial intelligence gets 75% of the way there, but needs a bit of editing afterwards (”Hm, why is there a secret passage leading from the bathroom to the bedroom?”) – well, just edit it.

And of ******course****** AI is going to have a hard time pulling together a cohesive plot from just a one-sentence setting description.

It’s just another reminder that AI performs best with guidance from humans. (For now, at least.)

<a href="mailto:andrew@mcgill.cool">Let me know what you think!</a>


One of the reasons I founded **The Andrew McGill Company** was to carve away a bit more time to hack on side projects. 

After a busy first few months, I’m excited to drop the first of my experiments — an ongoing experiment in using generative AI to make a video game 🎉

## The game

I was a big fan of **“interactive fiction”** games growing up — _Zork_, _A Mind Forever Voyaging_, _Deadline._

<figure>
    <img
        src="/images/blog/2023-11-02-ai-experiments-in-gpt-text-adventure-games/infocom.png"
        alt="The opening screen from Infocom's Deadline, outlining the beginning of the adventure."
    />
    <figcaption><em>Deadline</em>'s opening screen.</figcaption>
</figure>

*Deadline* (👆) came out six years before I was born, but by the late 90s, you could download most Infocom games for free. I loved how detailed they were — and how much freedom they gave you to explore worlds and solve problems creatively. 

Of course, you weren’t ******really****** free to do whatever you wanted — the entire time, you were on carefully constructed rails, with all the narrative dead ends neatly rounded off. At no point in ********Deadline********, for instance, could I decide I wanted to leave the Robner estate and get a pizza. 

**Fast-foward to 2023.** AI models like GPT-4 have made generating text of astonishing complexity as simple as writing a prompt. As I began experimenting, I began to wonder… could an open-ended text adventure game finally be possible?

I’m on a mission to find out — or, alternatively, build a lot of fun prototypes.

## How this series will work

A few rules: 

- **Ship ship ship.** I’m going to run through a lot of experiments quickly…
- **Write write write.** … and blog about them quickly, too.
- **The games ideally should be fun.** They don’t have to be, but they should point in the direction of fun.
- **I’m cheap.** The games shouldn’t cost more than a couple bucks in OpenAI requests.
- **Lastly, I’m busy.** I might have to put the series on pause if work or life heats up.

OK, onto the game:

## Game 1: The Mysterious Space Station


<figure class="bump-out">
    <img
        src="/images/blog/2023-11-02-ai-experiments-in-gpt-text-adventure-games/game-opening-shot.jpg"
    />
    <figcaption>Dall-E 3</figcaption>
</figure>

My first attempt is really simple. 

- What if I gave GPT-4 a prompt setting up the background of a game…
- … asked it to return a JSON file with a description of what’s happening and a number of actions the player could take…
- … had the player pick one of the actions …
- …  then fed that back to GPT-4, asking it to spin up another description-action JSON object…
- … and kept this loop going, feeding GPT-4 an ever-growing transcript of game events?

Here’s the result: [https://gpt-game-eta.vercel.app.](https://gpt-game-eta.vercel.app/) Give it a shot, I’ll front the OpenAI credits until we hit $10 for the month.

<figure>
    <a href="https://gpt-game-eta.vercel.app/" target="_blank">
      <img
          src="/images/blog/2023-11-02-ai-experiments-in-gpt-text-adventure-games/game-excerpt.png"
      />
    </a>
    <figcaption>The opening screen from one of my play-throughs.</figcaption>
</figure>

If you want to dig into the source code, the real magic is in the [constants file,](https://github.com/arm5077/gpt-game/blob/main/api/constants.js) where I set up the prompts.


If you poke around in there, you’ll see that I set up the adventure by casting the player as **Han Greedo**, an intergalactic smuggler. They’ve docked with a mysterious abandoned space station, which harbors a secret…

As the player presses further, they encounter Vase Windex, who sheepishly admits they accidently turned the entire crew into coffee cups. 

It’s then up to the player to resolve the situation before they’re transmogrified themselves.

## Learnings
I have a few:
- **GPT-4 does a good job of thinking on the fly** — presenting the player with good descriptions and actions that make sense.
- **With prompting, it can also follow the outlines of a plot, though its pacing can be a bit weird.** As I raced to solve the coffee cup mystery, the game kept warning me that I’d turn into a coffee cup soon… but it never actually happened. That said, I’m impressed it was able to hold the thread even as the accumulated prompt.
- **GPT-4 is unforgivably slow.** This program requires a live internet connection and makes a request to OpenAI after every player selection. GPT-4 sometimes took as long as 20 or 30 seconds to respond.
- **GPT-3.5-Turbo** **writes a worse game.** The more basic model is a lot faster, but ultimately writes simpler prose, follows the plot less closely, and is more likely to get stuck in loops (”hey, do you want to look at this control panel AGAIN?”).
- **This game would be really expensive to bake out as static JSON.** I’d love to ditch the OpenAI connection altogether and just bake out a bunch of JSON files of various decision trees. But exponential math means this gets expensive fast. If every narrative beat has four possible actions, baking out a game that lasts 10 turns would result in over a million JSON objects (and would cost a couple thousand dollars in OpenAI API fees).

## Next experiments
Lots to consider.
- Can I write the opening prompt better so they are multiple characters and in-game events with whom the player must interact?
- Can I build a version of this that’s more conducive to baking out as static JSON?
- Can I have GPT-4 make up events and milestones, and intelligently add those to the prompt as the adventure progresses?
- Can I add an element of randomness or true risk?

Until next time!

<figure>
    <img
        src="/images/blog/2023-11-02-ai-experiments-in-gpt-text-adventure-games/han-greedo-waving.jpg"
    />
    <figcaption>Dall-E 3</figcaption>
</figure>

*(Just want to see the poop app? Here's the [InVision prototype.](https://invis.io/UB119WTWQ9AN#/454482736_Onboard-Title_Screen))*

I lead the Interactive News team at POLITICO, a collection of coders and designers based in the newsroom. Since we don’t have the burdens of a traditional product team — we’re not worrying about [maintaining our article page,](https://building.theatlantic.com/designing-the-story-for-the-readers-we-want-aeba392cd004) for instance — we travel light and approach each project design as a blank slate.

But! As we tackle ever [bigger](https://www.politico.com/2020-election/results/) [stuff](https://www.politico.com/interactives/2022/congressional-redistricting-maps-by-state-and-district/), I’m realizing the importance of defining **design systems** early, both for individual projects and the team at large.

Honestly, I thought we were covered because we already use **component libraries,** first in Sketch/Figma and again in code with [Storybook.](https://storybook.js.org) But without a more fundamental plan in place for big projects, we were traveling without directions — which often led to a bunch of arguments along the way.

A design system:

- Helps us figure out the **objectives** we’re trying to achieve;
- Forces us to **make decisions early** about basic stuff like colors and typography;
- Serves as a **baseline** we can rely on for every other aesthetic decision.

We’re relaunching our election forecast soon (more on that later), and since it’s a big multi-page project, I really wanted to build a design system. But ... I was stuck. I’ve never made one before. It felt overwhelming.

So instead of jumping right in, I decided to take a practice shot — with a poop app.

## Yes, poop

As a new(ish) dad, I am now very interested in baby bowel movements. When my daughter was younger, we used to track every poop with an app that was kind of janky. It always felt rote, something we had to do in case her pediatrician asked us for info.  I always wished the app could give me better direct feedback — ”hey, way too much pooping!”

Two birds, one stone — I could practice building a design system *and* sketch out the poop app of my dreams. And I already knew the name: **Poopsy.**

A few books were really helpful in getting me started:

- *[Expressive Design Systems](https://abookapart.com/products/expressive-design-systems)* by Yesenia Perez-Cruz
- *[Atomic Design](https://atomicdesign.bradfrost.com)* by Brad Frost (a bit heavier on component stuff but still useful overall)
- inVision’s [Design Systems Handbook](https://www.designbetter.co/design-systems-handbook)

## Defining Poopsy’s priorities

I pulled most of this first part from *Expressive Design Systems.* Perez-Cruz suggests starting with a purpose statement explaining what you’re trying to accomplish. It’s actually a series of four questions.

1. **What is the goal for the design system?** To create a suite of products that are easy — and fun! — for busy parents to use.
2. **Why is that goal important?** If a tired parent has any trouble using our tools, they'll bounce. And giving them a taste of delight will make their harried lives a little brighter.
3. **How will it help us?** By giving us a shared set of tools to craft clear and delightful experiences with.
4. **Who is it for?** Our design and product team (aka me 😉).

Pretty straightforward. Next, a bit tougher: I had to settle on a set of design principles that would embody Poopsy’s aesthetics.

These can be as complicated as you want, but I like the simplicity of single words — Salesforce has defined theirs as [*clarity, efficiency,* *consistency* and *beauty.*](https://medium.com/salesforce-ux/how-we-designed-the-new-salesforce-at-scale-6d3607fd92e5)

Here are Poopsy’s:

- **Confident:** Give parents confidence amid uncertainty 💪
- **Simple:** Busy parents don't need additional mental load 💎
- **Mischievous:** Tracking poop just shouldn't be this fun 🤪

Lastly, Perez-Cruz recommends conducting an inventory of your user interface, pulling together similar components and generally bringing order to chaos. Since Poopsy wasn’t real, I instead built user paths that I would later use to design actual screens. Here’s the “flow” (sorry) for adding a new bowel movement:

<figure class="bump-out">
    <img
        src="/images/blog/2023-03-01-design-systems-and-baby-poop/user-flow.png"
        alt="Flowchart showing user's progress through logging a new baby poop"
    />
    <figcaption>A beeyootiful flowchart!</figcaption>
</figure>

## Typography & color

Now I knew I wanted the app’s design to feel confident, simple and mischievous. Cool! Time to put that into practice.

The next decision was my **primary typeface.** The winner was **Sofia,** a rounded sans-serif that felt whimsical and uncomplicated.

<figure class="bump-in">
    <img
        src="/images/blog/2023-03-01-design-systems-and-baby-poop/poopsy-logo.png"
        alt="A small poop symbol next to a rounded font spelling 'Poopsy'"
    />
</figure>

Most POLITICO projects have two typefaces — a sans-serif for display elements and a serif for body copy. Sofia was a little hard on the eyes in paragraph form, so I stayed in the san-serif lane and picked Proxima Nova, an old standby, for any body text the app might have.

Next, **colors!** InVision’s guide recommends picking 2-3 brand colors in addition to a background tint. I separated these into **core brand**, **accent** and **light.**

This one was a bit tougher. Here’s a few I considered:

<figure class="bump-out">
    <img
        src="/images/blog/2023-03-01-design-systems-and-baby-poop/poopsy-color-schemes.png"
        alt="Thre mock-ups of the Poopsy app, each with a different color scheme"
    />
</figure>

Somehow, a minty fresh theme felt less mischievous than just plain misplaced. Ultimately, I picked the variant to the right — I mean, it *is* a poop app.

With these two in hand, I had the fundamentals of my visual style nailed down...

<figure class="bump-out">
    <img
        src="/images/blog/2023-03-01-design-systems-and-baby-poop/poopsy-design-guide.png"
        alt="A card showing different typefaces and sizes, as well as colors"
    />
</figure>

...and could start actually working on screens.

<figure class="bump-out">
    <img
        src="/images/blog/2023-03-01-design-systems-and-baby-poop/poopsy-screen.png"
        alt="Two sample screens from Poopsy"
    />
</figure>

## How the system was helpful

Defining the colors up front forced me to keep things simple. And once I knew my typographical sizes and styles, weighting elements correctly was easy.

But the most helpful guidance ended up being the three design principles — confident, simple and mischievous. I found myself referring to them again and again. For POLITICO’s election forecast, I now knew that picking principles would be one of my most important first steps.

I could write a whole second blog post about how I designed **Poopsy** and built/de-duped component styles. Suffice it to say it was a lot of fun, and introduced me to Poopsy’s mascot, whom I’m calling Toots:

<figure class="bump-in">
    <img
        src="/images/blog/2023-03-01-design-systems-and-baby-poop/toots-logo.png"
        alt="A cute little blue baby"
    />
    <figcaption>Awwwww</figcaption>
</figure>

If you want to see the whole app, I’ve got an [inVision prototype rigged up.](https://invis.io/UB119WTWQ9AN#/454482736_Onboard-Title_Screen) Accepting pitches from angel investors!


_**Update 2023:** Even though smart speakers never fully resolved into anything useful (yet), this is one of my favorite posts. I think this was when I first _really_ understood that prototyping could be a full-time gig, and a useful one at that._

We have so many toys. If you’re a developer, I’m guessing there’s a new framework you’re itching to try tomorrow. And if you’re a news developer, or involved in news product development, there’s even more to tempt you—AMP Stories, ARKit, chatbots, podcasts, IoT, that 3D graphics library you never manage to find time to crack open…

All of this stuff is awesome and you should use it to make great journalism. And yet… haven’t we all been in this position?

> **Product manager:** Guys, Facebook just released a new feature where you can post a picture of yourself smiling, and it’ll make a hot-dog dance next to your face. What could we do with this?
>
> **Excited developer:** Oh man, so many things! (skims documentation) And it’s so simple! We need to get on this platform immediately!
>
> **Product manager, now also excited:** OK! Let’s build something! How many sprints will it take?
>
> **Boss:** Uh, hold on a second…

I am intimately familiar with the rush of adrenaline that comes from hearing about a new platform or technology and *needing to build something with it, immediately.* But what if the platform is more annoying to work with than you expected? Or it isn’t a good fit for your users? Or — and this is always the heartbreaking one—what if you just don’t have a good enough idea of how to use it?

Our team at The Atlantic is mighty and growing mightier, but we’re still small enough that we have to choose our shots carefully. So here’s a proposal: Before you go whole-hog into launching a creative initiative with new tech, build **three completely different prototypes first.**

## Prototype, prototype, prototype
By “prototype,” I mean a thing that is proudly held together with duct tape. It is the minimum of your minimum viable product. It is hopelessly bespoke.

It is also a crucial first step. Without getting your hands dirty, I find it’s very hard to get a sense of how a technology could fit into your systems and editorial workflow. Also, your audience (or a small slice of them) can play with a prototype. Who knows if they even want the latest journalism-hot-dog mashup?

Here’s the bottom line. If you’re going to spend a bunch of time reading documentation to make a level-of-effort recommendation to your boss anyway, why not make something while you’re at it?

Well, not something. Three things. You have to make three things. What’s so special about the number three?

* **It’s not one.** Your first idea for this platform might be complete magic. But never test just your first idea. You’re too enthusiastic about it to be objective.
* **It’s not two.** Two ideas means you have a winner and a loser. Don’t give your brain (or your bosses) an excuse to ditch the insights from a “losing prototype” because you built a duopoly. You need to learn from both.
* **It gives you permission to move fast and be imperfect.** When you’re just building one thing, you’ll want to make it perfect. Building two things is definitely a grind, so you’ll end up putting 75 percent of your effort into the idea you like better. But when you have to build three prototypes, all those excuses go out the window. You don’t have time to focus on your favorite, and no one’s expecting you to come up with something production-ready.

So those are the rules. Get excited. Build three things. Put them in front of people. Then figure out the next step.

## How we did this with the Amazon Echo
The Atlantic is no stranger to audio — we have two podcasts we love and a slew of audio articles. But we haven’t built anything for smart speakers like the Amazon Echo or Google Home.

We knew we *wanted* to. But the prospect of having to learn an unfamiliar SDK and the difficulty of coming up with a worthwhile idea that could also attract sponsors meant smart speakers always got pushed to the back of the line.

In February, we resolved to break the stalemate with a prototyping blitz. Oh, and do it within a month.

* On Day 1, we pulled newsroom editors, product leaders and sales reps into a conference room. Their topic of debate: How could smart speakers improve The Atlantic’s journalism, and also present an attractive opportunity to underwriters? Together, this larger group hashed out a few broad areas of interest — quizzes, archive material, scientific and cultural discoveries, and non-political news content.

* We then whittled the group down, keeping only the key stakeholders. They refined the broad areas and came up with a list of “prototype candidates” — around a six or seven ideas. (A requirement — they had to have goofy names.) To help the group see potential costs, I found it helpful to plot how hard they would be to **build** versus **maintain,** using a chart like the one below:

<figure>
    <img
        src="/images/blog/2018-03-29-excited-by-latest-news-platform-build-three-prototypes-first/build-maintain-chart.png"
        alt="A chart showing a number of prototypes plotted along a chart, with \"Build\" on the x-axis and \"Maintain\" on the y-axis."
    />
</figure>

* Voting time! From that smaller list, the stakeholder group picked three ideas to rapidly prototype and test with readers. They ending up selecting the two flash briefing skills, as well as one custom skill. Remember, you have to build three!

* The Atlantic Product team got to work. For each of the feed skills, we produced a week’s worth of “episodes,” pulling talent from the newsroom to help us write scripts and line up interviews. The custom skill required a bit more work in Node, but also a fair amount of voice acting — let’s just say we discovered some emerging radio talent from the ranks of Atlantic developers. All in all, building the prototypes took two weeks.

* Simultaneously, we recruited beta testers from our readership. We’d give them things to listen to over their smart speakers, and they’d fill out a survey after every episode/interaction. We’re lucky to have dedicated Atlanticans who are willing to play around with what we create.

* Launch day! All three products went live to various segments of our beta testers. Before long, we started getting feedback through surveys (and by surveys, I mean Google Forms, because what else do you really need?):

<figure>
    <img
        src="/images/blog/2018-03-29-excited-by-latest-news-platform-build-three-prototypes-first/prototype-net-promoter-score.png"
        alt="A bar chart showing how people responded to the classic \"How likely are you to recommend this\" question."
    />
</figure>

* This real-time feedback was super helpful, and allowed us to switch things around in the second week of beta testing. By the end of the week, we had hundreds of responses — tons of quantitative and qualitative data to pore through.

* It’s over! We convened a wrap-up meeting to discuss what we learned and what products we wanted to build next.

That was our prototyping blitz. At the end of it, we had a) three working products, b) lots of data about customer preferences, and c) tons of enthusiasm for the next steps, both on our team and among our readers/testers.

<figure>
    <img
        src="/images/blog/2018-03-29-excited-by-latest-news-platform-build-three-prototypes-first/prototyping-team.jpeg"
        alt="A bar chart showing how people responded to the classic \"How likely are you to recommend this\" question."
    />
</figure>

Maybe you don’t have the time for this approach. (I’m betting you do.) And perhaps the technology you’re looking to test is just too complicated to cram into a one-off prototype. (Is it really?) If that’s the case, I guess you just have to wing it.

But if you’ve got any flexibility in your pipeline, give yourself permission to rough out a new thing (three things!) and learn along the way what you really want to create.


At any given moment, people are doing some pretty neat stuff at _The Atlantic._ Just last week, my coworkers: 

* Wrote a story about [snakes that are good at killing other snakes;](https://www.theatlantic.com/science/archive/2017/03/snake-vs-snake/519696/)

* Experimented with how to hype a magazine story [in a really cool way on Instagram;](https://www.instagram.com/p/BReEOpLD8zm/)

* Compiled a [crazy photo essay on Mount Etna,](https://www.theatlantic.com/photo/2017/03/mount-etna-europes-most-active-volcano/519681/) Europe's most active volcano.

But here's the sad truth: I  only see a tiny percentage of the things my officemates make. I just don't have enough time in the day to read through every story on [theatlantic.com.](https://theatlantic.com) And even if I could, I'd still miss all the things our events staffers are planning, or what the product team is coding, or what the graphic artists are cooking up...

We all work in the same building, but I know very little about what people outside my own team (politics) do on a daily basis. And although I don't really _need_ to, I wondered if there was a way to introduce some serendipity into our working lives.

**Why is serendipity even important?** This probably deserves a longer answer, and at some point, I'll write a standalone post.

For now, here's my best shot: Encouraging serendipity at an organization makes room for happy accidents, where something unexpected results from the collision of two separate things. Some of my favorite projects have come from chance conversations — and they're usually something neither me nor my conversation partner would have developed alone.

## Enter SerendipityBot

They say that if [all you have is a hammer, everything looks like a nail.](https://en.wiktionary.org/wiki/if_all_you_have_is_a_hammer,_everything_looks_like_a_nail) I'm trying to be more careful about jumping to a technical solution when something might just need a simple conversation — or might not be a problem at all.

But in this case, I felt pretty confident about my idea: **What if we had a Slack bot that unobtrusively asked random staffers about what's energizing them this week, and then shared that with the office at large?**

Here was my idea:

* I'd make a Slack #serendipity channel where people who are interested in learning about what their coworkers do — and telling their own stories — could join and engage in conversation;

* I'd code a Slack bot that would randomly ping people from that channel to share what they're passionate about at that moment, at an interval of no more than once every two weeks or so.

* Every day, the bot would ping coworkers during working hours until it had three responses. And at a set time, it would post all three to the #serendipity channel as a small blog post.

Would anyone even want to participate? I floated a trial balloon:

<figure>
    <img
        src="/images/blog/2017-03-18-finding-serendipity-at-the-atlantic/serendipity-pitch.png"
        alt="i’m considering an experiment: i enjoy learning via serendipity what my non-political coworkers are working on and wondered if there was a way to find out more intentionally. i’m rigging up a slackbot that would a) ping random dot-com folks at non-annoying intervals (every few weeks?) to ask what they’re writing/coding/videoing about and b) distill that into a occasional digest on a special slack channel. could be a neat place to get some ideas or offer suggestions. if you’re interested in being a part of the beta, throw me a robot emoji here!"
    />
</figure>


OK, so I wasn't crazy! Those 25 people became my beta testers.

First job was figuring out what the bot would say to people. I wanted it to be chill and non-threatening, and give people the option of ducking out — but also be fairly direct.

Here's what I ended up with: 

<figure>
    <img
        src="/images/blog/2017-03-18-finding-serendipity-at-the-atlantic/serendipity-intro.png"
        alt="Hi! I'm SerendipityBot, created by @andrewmcgill. I ask random Atlantic people what they're working on this week that excites them, and share a brief digest every day in #serendipity. It's a fun way to get an idea of the cool things your coworkers are doing. Want to partipate? If so, tell me something you're working on this week that you'd like to share, in the form of \"I am *building a rocket,*\" or \"I'm *writing about Capt. Jean-Luc Picard*.\" If you don't want me to bug you right now, reply *\"snooze.\"* If you never want to hear from me again (:sob:), type *\"I hate you.\"*"
    />
</figure>

The bot waits a while for an answer. If it doesn't get one, it nudges politely: "I'll ask one more time before leaving you alone: Any chance you want to share a cool thing you're working on this week?"

It's key, by the way, to give people a way to let the bot know they don't really have anything they want to share. Sometimes, you're just not working on anything exciting at the moment. Or maybe you're too busy. In that case, the bot happily accepts `snooze` and leaves the person alone for two weeks.

Right now, I have the bot pinging a random employee every 10 minutes, from 11 a.m. to 2 p.m., Monday through Friday. Once it gets three responses, it stops for the day. (Of course, sometimes people respond a few hours late, after the quota has already been filled, so we'll occasionally have four or even five responses in a single day.)

At the stroke of 2:30 p.m. — I originally set it for the next morning, but people didn't like waiting a whole day to see their responses go up — the bot posts in #serendipity.

Here's an example:

<figure>
    <img
        src="/images/blog/2017-03-18-finding-serendipity-at-the-atlantic/serendipity-example.png"
        alt="A slack conversation initated by the bot that culminates in a picture of a panther with a breathing mask."
    />
</figure>

## How has this experiment turned out?

Pretty well. More than 70 people have joined the #serendipity channel — somewhere around a quarter of the entire _Atlantic_ Slack community. SerendipityBot had some hiccups: It spammed a bunch of people on Martin Luther King Jr. Day, which is on a Monday, when the bot thought everyone would be working. But overall, I think it has made each day a teensy bit more delightful.

What's the long term impact? I don't know. So far, I haven't seen The Next Big Atlantic Idea bubble up from a conversation in #serendipity. But that's not really the point. Getting to know your coworkers better is a worthy goal on its own — and I think SerendipityBot has helped with that.

_If you'd like to look at the code powering SerendipityBot, [it's available here.](https://github.com/arm5077/sup-slackbot) Tldr: It's a Node app that lives on Heroku and stores user information in a MongoDB database._


So I've taken a stab at the TikTok-style news app posited in [this previous post.](http://www.andrewmcgill.me/2019/06/15/why-dont-we-have-news-apps-like-tik-tok.html)

My premise: Most news apps look the same and emphasize browsing when you're stting with a cup of coffee in the morning. How would I design a news app for in-between moments — standing in line, waiting for the elevator — when I didn't have a specific thing I was looking for, beyond something interesting to read?

Here's what I came up with — you can take a look at [https://atlantic-tik-tok.herokuapp.com:](https://atlantic-tik-tok.herokuapp.com)

<video 
  style="margin: 24px auto; display: block"
  src="/images/blog/2019-07-07-a-tik-tok-news-app/swipe-demo.mp4" autoplay muted playsinline loop></video>

It's a progressive web app modeled loosely after TikTok, where every swipe up gives you something new. If you're interested in a story, you can tap it to read it in full.

The app starts by pulling the latest news from The Atlantic. But once you finish swiping through those, it prompts you to "Enter the Wormhole," pulling the best stories from out archive.

A few notes:

* The app saves the stories it's already shown, so you never see the same story twice. 
* Right now, archive stories are sourced exclusively from The Atlantic's Science, Health and Family sections. I'm figuring that once people are caught up with the latest news, they don't want to see old politics stories. So I'm focusing solely on wonder-and-delight stuff.
* The little Poseidon illustrations are from the wonderful [Andika Wahyu.](https://www.behance.net/andikkawah0f09/) He's available for commissions!

Since this is a web app, not a native iOS app, you have to manually "install" it by opening the URL in Safari or Chrome and clicking "Add to Home Screen." You can also just visit it as a website, but I prefer the fullscreen version.

I'm going to sit with it for a bit and see if it fills a hole in my news habits. But there's definitely already a few things I want to improve. 

* **It desperately needs a "Save for later" feature.** Sometimes the app gives me a story that looks interesting, but really is just too long for me to read right away. I'd love to be able to bookmark it to read later.
* **I'm not sure the background-screened image works.** I wanted to feature the article art in way that felt dramatic but not distracting, but I'm not sure I've hit it here. The cropping often looks funny, and I have to choose a better set of screen gradients. Maybe there's a smarter way to include the photo in its original aspect ratio, or to target the right spot to center the crop.
* **Offline reading isn't a thing yet.** While the app caches the stories locally after pulling them from The Atlantic, I need to refactor the app so it knows to pull from local storage when it doesn't sense an internet connection.

Plenty of room to improve, but it's a start. [Give it a shot yourself](https://atlantic-tik-tok.herokuapp.com/) and [let me know what you think.](mailto:arm5077@gmail.com) (And here's the [Github repository](https://github.com/arm5077/atlantic-tik-tok) for the code.)


I'm newly obsessed by TikTok, the social video platform that combines the best parts of Vine and a casino slot machine. Its interface is easy. IT shows me just one thing at a time. And the algorithm powering it is uncannily good at learning my tastes and serving up what I like. 

<iframe height="700" src="https://www.tiktok.com/embed/6646016679396510981" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen style="margin: auto; display: block; width: 100%; max-width: 350px"></iframe>

Why aren't more news apps like this? I recognize there's a big difference between quality journalism and funny videos, but I don't see a single major news app emulating the awesome, serendipitous user interfaces we're seeing from social media companies.

I think three things apply:

* **News apps (and homepages) are generally organized around breadth.** They want to show you all the stuff that's going on, instead of directing your attention to a single thing, or series of things.
* **New organizations prize curation and editing, and are reluctant to surrender that judgement to algorithms.** (Vox and Flipboard use computer logic to determine the best homepage layout, but not the stories being displayed.)
* **News apps don't want to look frivolous.** A lot of the newest ways to navigate apps -- swiping, tapping -- have been pioneered by companies news orgs would rather not be associated with. No editor-in-chief wants to hear, "Oh, your app is just like Tinder!"

I'm not arguing that these positions are _wrong_ -- though I look askance at being conservative for conservativeness's sake. But I do wonder if a more serendipitous, easier-to-navigate news app would appeal to people in interstitial moments, those times when you're waiting in line or taking a Lyft and just want something to occupy your attention. 

A few apps ([Economist Espresso,](https://apps.apple.com/us/app/economist-espresso/id896628003) [Refinery29 This AM,](https://apps.apple.com/us/app/refinery29-this-am-top-8-news-headlines-updates/id988472315) the now-defunct [Quartz Briefing](https://digiday.com/media/quartz-is-shutting-down-its-quartz-brief-mobile-app-july-1/)) have tried to hit this target. But right now, my go-to is TikTok or Instagram. Is there room for something more intellectually fulfilling?

## A proposal
I'd argue a place like The Atlantic actually has a good mix of content for a TikTok-type app. Instead of simply relaying the news, most of its stories consider a question or pose an argument. And a lot of its stuff falls nicely into the "wonder-and-delight" category that could grab people immediately.

Here's how it would work:

* **First, get good content.** Pull The Atlantic's 500 best-performing stories, and strip out political news. That way, we get stories we know people have enjoyed, but are also less likely to be flash-in-the-pan spot coverage.
* **Guarantee a surprise.** Every time the reader opens the app, it shows them a new single-screen promo to an interesting story. It can be simple -- maybe just the headline, a deck, and the amount of time it would take to read the full story.
* **Give them a choice.** 
    * If the reader is interested in a story, they tap it. A screen pops up with the full story text, which they can scroll through or dismiss.
    * If they're not interested, they swipe up. Boom! They get a new story. 
* **Keep doing this forever.** Once the reader swipes through the first set of stories, we pull another 500. 

<figure>
    <img
        src="/images/blog/2019-06-15-why-dont-we-have-news-apps-like-tik-tok/wireframe.png"
        alt="A wireframe showing an app flow described above."
    />
</figure>

We'd need to record which stories they've read or swipe through, so we avoid showing them again. And it might be nice to have a "save-for-later" function -- if they're interested but don't have enough time in the elevator, they can bookmark a story.

Now, I'm not saying this replaces an organization's news app. It's still important to have the editors' voice saying, "These are the stories you _should_ read!" But as a complimentary app, or even a tab within a larger site, I think this could be pretty fun.

_Catch up: [In this post](http://www.andrewmcgill.me/2019/05/07/mcu-ninja-ranking-part-one.html), I describe how my Marvel fandom compelled me to make an app that allows me to objectively rank my favorite superhero movies. I've settled on using the Quicksort algorithm, and have built a command-line proof-of-concept. Now, I just need to build the real thing._

In order for [mcu.ninja](http://mcu.ninja) to work, the app had to do a few things at once:

* **It needed to present dozens of pairs of movies to the user in sequence.** Quicksort relies on comparing a _test item_ to a _pivot._ As the algorithm rolled through the Marvel Cinematic Universe, it would show a bunch of 1-1 matchups, like _Captain Marvel_ vs. _The Incredible Hulk._
* **Picking one movie over the other had to be super simple.** People needed to quickly vote, and they're not going to do it if it's hard.
* **What's more, it has to be super simple even after you do it dozens of times.** When you're trying to order a list of 20+ movies, you're going to run through a _lot_ of comparisons.
* **It has to make the choice easy to understand.** A lot of superhero movie titles sound the same, and there are many, many sequels. This app had to make _Iron Man 3_ and _Guardians of the Galaxy Vol 2_ look distinct.

Not easy!

But I drew inspiration from another app on the market that's really good at presenting a bunch of choices quickly: **Tinder.**

## The swipe-y solution
In a way, Tinder has a similar goal. You're shown someone's profile and asked to make a decision — are you interested in them or not? And since they're essentially turning dating into a volume play, they want you to be able to rip through a bunch of options _fast._

To make this happen, Tinder refined swiping. If you like someone, you swipe right. If you're not interested, you swipe left. You can blaze through dozens of profiles in a few minutes.

Turns out this mechanic works pretty well for my app, too. First, I show them the pivot movie. I then run a series of other movies past them. Just like Tinder, if they like the test movie better, they swipe right. Otherwise, they swipe left. 

Once the pivot movie has run out of comparisons, we choose another pivot, and the swiping continues. 

Granted, Tinder isn't asking user to compare _two_ people and pick their ideal date — that's where the comparison to mcu.ninja breaks down. But swiping just made sense. It collapses a long list of comparisons into a single series of a few dozen swipes, resulting in a perfectly sorted list.

Here's how it looked in practice:

<video 
  class="video" 
  style="max-width: 400px; margin: 24px auto; display: block;" 
  src="/images/blog/2019-05-14-mcu-ninja-ranking-part-two/swipe-demonstration.mp4" muted loop autoplay plays-inline></video>


## Some findings from user testing
I learned a few important things from putting the app in front of people.

* **Swiping is harder than I thought.** People sometimes forgot which direction to swipe halfway through a series. To cue them, I added labels to the swipe animation making the comparison clear: "The Incredible Hulk is Worse 👎" and "The Incredible Hulk is better 👍".
* **You need an undo button.** Making a fast-paced app means people will make mistakes. I ended up storing the entire decision chain in memory — the yes-or-no vote on every movie pair. That way, people could jump back if they realized they swiped the wrong way.
* **Showing people how many questions they have left is hard.** The tough thing about Quicksort is that it doesn't guarantee finding a solution within a set number of sets, making a progress bar tricky. I ended up having _two_ -- one at the bottom of the screen, to show how far along you were in the given comparison set, and another at the top, for how close you were to getting your final list. I'm still not sure it works great.

## How it turned out, and next steps
I really enjoyed seeing my friends use the app and post their lists.

But it became clear that it's still not super easy to share your results, even though the app offers a Twitter and SMS share feature. Most people ended up taking screenshots and sharing those. Long-term, I'd love to have the app produce a card image that you could export and send to other MCU fans, or post on social media.

Also, this is just a demo website/web app. While I don't think there's a _huge_ demand for ranking favorite superheo movies, it might be interesting to convert it to an iOS app at some point. 

But most importantly, I'm interested to see how this list sorting mechanic could be put to other uses. Why stop at MCU movies? I could see a version of this becoming a new quiz format.

Regardless, it was a lot of fun to make. If you're reading this post first, here's my personal list (_7/2019: I've updated this list to include_ Spider-Man: Far From Home.)

1. The Avengers
2. Iron Man
3. Guardians of the Galaxy
4. Thor: Ragnarok
5. Avengers: Infinity War
6. Captain America: The Winter Soldier
7. Captain America: Civil War
8. Avengers: Endgame
9. Black Panther
10. Spider-Man: Homecoming
11. Spider-Man: Far From Home
12. Iron Man 3
13. Captain America: The First Avenger
14. Captain Marvel
15. Ant-Man
16. Avengers: Age of Ultron
17. Doctor Strange
18. Ant-Man and the Wasp
19. Thor
20. Guardians of the Galaxy Vol. 2
21. Thor 2
22. Iron Man 2
23. The Incredible Hulk


I love superhero movies. Specifically, Marvel superhero movies. Specifically specifically, Marvel Cinematic Universe movies — Iron Man, Captain America, Thor, and so on. Never thought I'd be that guy, but somehow I've seen _every single MCU movie_ — 22 in total. 

Why? Because they're super good! There's a reason they have an average Rotten Tomatoes score of 84%.

But which ones are the _best?_ This is a constant debate among my friends. And with the latest phase of the MCU coming to a close with _Avengers: Endgame_, it's been a good time to take stock and make best-of lists.

A few problems, though:

* **There are too many movies.** Organizing 22 films in order of preference is a... _tall order._ (🥁) You have to keep track of every other movie when you're considering one, or chunk them in ways that could lead to misalignment later.
* **You're probably going to give better scores to movies you just saw.** Because I watched _Avengers: Endgame_ more recently, I'm more likely to rate it higher than the original Avengers, just because I remember more details about it.
* **You probably know your favorite and least-favorite films, but nothing in between.** This is a twist on the well-documented [recency/primacy](https://en.wikipedia.org/wiki/Serial-position_effect) effect, where humans are better at remembering the beginnings and ends of lists than things in the middle. In this case, fans probably never formed opinions on middling movies, focusing on just the best and the worst.

All of these problems mean tools that let you [drag around movie names](http://rankthemcu.com) probably aren't helping you come up with a definitive list. They're just confusing you!

<video autoplay="" playsinline="" muted loop preload="auto" poster="https://thumbs.gfycat.com/SleepyAngelicGiantschnauzer-mobile.jpg" tabindex="-1"><source src="https://thumbs.gfycat.com/SleepyAngelicGiantschnauzer-mobile.mp4" type="video/mp4"><source src="https://giant.gfycat.com/SleepyAngelicGiantschnauzer.webm" type="video/webm"><source src="https://giant.gfycat.com/SleepyAngelicGiantschnauzer.mp4" type="video/mp4"><source src="https://thumbs.gfycat.com/SleepyAngelicGiantschnauzer-mobile.mp4" type="video/mp4"><meta itemprop="contentUrl" content="https://giant.gfycat.com/SleepyAngelicGiantschnauzer.mp4"></video>

My take: **It's easier to pick your favorite movie when you just have two options in front of you.** If you run through enough pairings, eventually you'll get an ordered list. 

That's the idea behind [mcu.ninja,](http://mcu.ninja/) a ranking tool I put out last week. 🎉

In this post, I'm going to explain the logic behind the ordering algorithm powering mcu.ninja and the command-line utility I built to demonstrate it. Next week, I'll discuss the UI and why I thought Tinder-style swiping was the right decision.

<a href="#my-list">If you just want my MCU movie ranking, here you go.</a>

## Sorting is hard

If you need to order a list of 22 items, it's simplest to go one by one and compare every movie to every other. 

Let's say I start with _Captain Marvel._ I'd compare it to _Iron Man_, the first film in the MCU.

<figure>
    <img
        src="/images/blog/2019-05-07-mcu-ninja-ranking-part-one/marvel-vs-iron-man.png"
        alt="Movie posters of Captain Marvel and Iron Man"
    />
</figure>

OK, that's easy — I like _Iron Man_ better. But that's only the beginning. I still have to compare _Captain Marvel_ to every other MCU movie — 21 comparisons in all.

<figure>
    <img
        src="/images/blog/2019-05-07-mcu-ninja-ranking-part-one/marvel-vs-everyone.png"
        alt="Captain Marvel vs. every other Marvel movie — quite a few!"
    />
</figure>

Once we're done with _Captain Marvel_, we move on to the next film: _Avengers: Endgame._ Since we already compared it to _Captain Marvel_, we don't have to match them again. But we still have 20 other movies to compare.

<figure>
    <img
        src="/images/blog/2019-05-07-mcu-ninja-ranking-part-one/marvel-and-endgame.png"
        alt="41 movie posters"
    />
    <figcaption>Let's add in Avengers: Endgame. SO MANY MOVIES</figcaption>
</figure>

So far, we've made 41 comparisons. If we add just two more movies, we're up to 78:

<figure>
    <img
        src="/images/blog/2019-05-07-mcu-ninja-ranking-part-one/obviously-crazy.png"
        alt="78 movie posters"
    />
    <figcaption>This is obviously crazy.</figcaption>
</figure>

Taking this to its mathematical conclusion, we'd have to make comparisons equal to 21 + 20 + 19 + 18... + 1, or *(n^2 + n) / 2*. That's 231 match-ups — only marginally better than watching [14,000,605 alternative futures.](https://screenrant.com/infinity-war-doctor-strange-futures-how-many-why/)

## Quicksort to the rescue

There are plenty of [better ways](https://en.wikipedia.org/wiki/Sorting_algorithm#Comparison_sorts) to sort stuff. In this case, topping the list is the **[Quicksort](https://en.wikipedia.org/wiki/Quicksort)** algorithm.

Let's line up all the movies by date released — the order doesn't matter — and randomly pick _Captain Marvel_ to start:

<figure class="bump-out">
    <img
        src="/images/blog/2019-05-07-mcu-ninja-ranking-part-one/quicksort-step-1.png"
        alt="All the Marvel movies lined up, with Captain Marvel highlighted."
    />
</figure>

_Captain Marvel_ is the **pivot.** Our job is to re-order the list so every movie that's worse goes on the left, and every movie that's better goes on the right.

It doesn't matter what order we put them in — only that they're better or worse than the pivot.

<figure class="bump-out">
    <img
        src="/images/blog/2019-05-07-mcu-ninja-ranking-part-one/quicksort-step-2.png"
        alt="We've sorted the movies to be better or worse than Captain Marvel."
    />
</figure>

Ater sorting (your choices might be different!), we now know Captain Marvel is No. 16 on list. To do this, we had to make 21 comparisons — same as we did before. But the next step is different. We consider the better-than and worse-than movies as _their own sets,_ and run the method again.

So in the "worse-than-Captain Marvel" set, we randomly choose _Thor: The Dark World_ as our pivot. In the "better-than-Captain Marvel" set, we choose _Captain America: Civil War._ For each of these sets, we again sort the movies by whether or not they're worse than the pivot.

<figure class="bump-out">
    <img
        src="/images/blog/2019-05-07-mcu-ninja-ranking-part-one/quicksort-step-3.png"
        alt="A long of movie posters, sorted."
    />
</figure>

Now we have three movies properly ordered — with only 40 comparisons, instead of 60 with our previous method. That's a huge improvement. 

That kind of efficiency isn't guaranteed. Quicksort works best when the pivots land in the middle of a given set — in this case, the movie that's chosen is average, not terrible or spectacular. But unless you're really unlucky, Quicksort will work far better than brute force.

## Building a proof of concept

Before I built out the full [mcu.ninja](http://www.mcu.ninja) app, I wanted to make sure this method actually made sense. In practice, would it work to present people with pairs of movies and having Quicksort figure out which to show next?

So to test, I built [mcu-rankings-cli,](https://github.com/arm5077/mcu-rankings-cli) a command line interface script written in Node.

<video autoplay loop muted><source src="/images/blog/2019-05-07-mcu-ninja-ranking-part-one/cli-example.mp4"/></video> 

Pretty simple — it gives you two options, and you pick one. On the back end, I wrote a `MovieList` class that handled making match-ups and accepting votes from the user. On the front end, the [inquirer](https://www.npmjs.com/package/inquirer) makes the CLI magic happen.

The method seemed to work pretty well. Sometimes the pivot movies weren't great — it's annoying to get a stinker like _The Incredible Hulk_ and have to vote against it 20-something times. Later on, I decided to use Rotten Tomatoes data to choose the most "average" movie in a set as the pivot. 

But otherwise, success. Next week, I'll talk about how the final swipe-y UI came to be!


## For the record, here's my list: <a name="my-list"></a>

1. The Avengers
2. Iron Man
3. Guardians of the Galaxy
4. Thor: Ragnarok
5. Avengers: Infinity War
6. Captain America: The Winter Soldier
7. Captain America: Civil War
8. Avengers: Endgame
9. Black Panther
10. Spider-Man: Homecoming
11. Iron Man 3
12. Captain America: The First Avenger
13. Captain Marvel
14. Ant-Man
15. Avengers: Age of Ultron
16. Doctor Strange
17. Ant-Man and the Wasp
18. Thor
19. Guardians of the Galaxy Vol. 2
20. Thor 2
21. Iron Man 2
22. The Incredible Hulk


Every so often on The Atlantic’s Product team, we drop what we’re doing and spend a day messing around. Lots of whiteboards, some frantic coding, usually ending with presentations over beers. We call it a “hack day,” but I think of it more as a talent show for ideas — a chance to take all those concepts we’ve been privately mulling, put them on stage, and see how they perform.

Today, we’re publicly launching one of the reader-focused projects we prototyped at our last hack day: Serendipity, a Chrome and Firefox extension that displays an awesome piece of Atlantic journalism every time you open a new tab.

<figure>
    <img
        src="/images/blog/2017-11-15-atlantic-serendipity-browser-tab-chrome/serendipity-example.gif"
        alt="A picture of Serendpity in action, rotating through stories."
    />
</figure>

## What it does
Are you on your desktop computer? Hit Cmd-T (or Ctrl-T, if you’re on a PC).

OK, now come back. Are you back?

Good. You probably saw an empty screen, or maybe a Google search bar. Chances are, you don’t think about that page. It’s a blank nothingness, waiting for you to type a URL.

We saw a canvas.

[As I’ve written before,](https://medium.com/building-the-atlantic/building-a-slack-bot-to-inspire-serendipity-in-the-office-30dc658f8609) I’m fascinated by the concept of serendipity, the collision of unrelated things that result in something new. True serendipity is rare, but it can be encouraged. I think that’s what we’re trying to do when we publish a magazine: We take a bunch of ideas, bundle them together, and deliver them to you for inspiration.

With [The Atlantic Serendipity,](https://www.theatlantic.com/serendipity/) we’re aiming to do the same thing. With every new tab, it surprises you with a new piece of journalism. Maybe the article catches your eye, and you read more — or maybe it doesn’t, and you finish typing in the website you were going to visit.

Either way, you get a bit of delightful (we hope!) randomness, and we get a chance to show you a piece of writing or video we think is really good.

## How we built it
When the team ([Ana Carano,](https://www.linkedin.com/in/ana-carano-3a5b7090/) [Thanh Do,](https://www.linkedin.com/in/thanh-do-03b9b096/) [Kevin Mahoney,](http://kevinmahoney.me/) and [Carson Trobich](https://twitter.com/carsontrob?lang=en)) huddled up on Hack Day morning, the only thing we knew was that we wanted to put The Atlantic on someone’s Chrome tab. What it looked like, or even how we’d do it — no idea.

Our first step was to look at the competition. Here are a few extensions we found helpful for inspiration:

* [Momentum](https://momentumdash.com/), the grande dame of them all, with more than 11,000 reviews on the Chrome store. It puts a clock, a quote, and a beautiful picture on your browser, and greets you by name. It also has a number of optional widgets.
* [Wallcat](https://beta.wall.cat/). Like Momentum, it displays a new piece of stunning photography every day.
* [Wandertab](https://chrome.google.com/webstore/detail/wandertab-by-hitlist/fobdcmnamenjmkffajcbljjpgiolooeh?hl=en). This one is fun: It features airfare deals from the location of your choice, updating frequently.
* [Mainichi](https://chrome.google.com/webstore/detail/mainichi/dfekdjmdikicceaiokcmmchenpilglhn?hl=en). Kevin and Thanh were fans of this one, which drops in a flashcard of foreign language vocabulary into each new tab.

After some initial brainstorming, Thanh put together some sketches of three approaches, varying in density and tone:

<figure>
    <img
        src="/images/blog/2017-11-15-atlantic-serendipity-browser-tab-chrome/serendipity-thanh-prototype-1.jpeg"
        alt="A prototype of Serendity, largely black and white."
    />
    <figcaption>
        This one looks a bit like Tweetdeck, with cascading columns of Atlantic stories.
    </figcaption>
</figure>

<figure>
    <img
        src="/images/blog/2017-11-15-atlantic-serendipity-browser-tab-chrome/serendipity-thanh-prototype-2.jpeg"
        alt="A prototype of Serendity, this one a bit more bold."
    />
    <figcaption>
        This is less busy, but still with three stories.
    </figcaption>
</figure>

By the end of hack day, we had semi-interactive version of the second design ready to show the rest of the Product team. Folks were intrigued. There were a few complaints, however:

* It was monochrome, and didn’t feature any of the photography or graphic art that usually accompanies our stories.
* Even with just three stories, it was a bit dense.

A week or two after the presentation, I went back to the drawing board and mocked up a simpler version, featuring just one headline, and using our new display font, Noe:

<figure>
    <img
        src="/images/blog/2017-11-15-atlantic-serendipity-browser-tab-chrome/serendipity-andrew-prototype-1.png"
        alt="A single story, this time, with a blue background."
    />
    <figcaption>
        This is simpler, and colored in reverse.
    </figcaption>
</figure>

Hm! Much cleaner. For variety, I played around with having the background tint change every time, cycling through some of our new brand colors. (I also attempted a misbegotten adventure with a shifting animated gradient, which nearly sent my computer’s CPU marching to the picket lines.)

But was there a way to integrate photography? Turns out that a good number of our display photos looked decent behind the headlines, so long as they were toned correctly to avoid conflicting with the text. I also added an Atlantic logo and a “Next story” button, so people could cycle through without having to open new tabs.

<figure>
    <img
        src="/images/blog/2017-11-15-atlantic-serendipity-browser-tab-chrome/serendipity-andrew-prototype-2.png"
        alt="A single story, this time, with a blue background."
    />
    <figcaption>
        Added a photo and a next button.
    </figcaption>
</figure>

Right now, the story-recommendation algorithm is simple: We’re just using the our homepage’s RSS feed. The first time you open a new tab, Serendipity pulls the latest stories and stashes them in your browser’s local storage; that means it works even when you’re not connected to the internet (though the photos don’t show up.)

Every time you pop open a tab, it shows you a different story. After 30 minutes or so, it’ll check back with us to see if there’s new content.

## What's next

In October, we debuted Serendipity to The Masthead, The Atlantic’s membership program. Based on their feedback and new responses from you, we’ll be updating the extension as time permits. Some of the ideas we’re fielding:

* A “back” button,for those times you glimpse an interesting story just before gmail.com or facebook.com loads;
* A “quiet” mode, where the same story is shown to you on every new tab, refreshed every half-hour;
* An accessibility theme, losing the image and switching to high-contrast font and background colors.

We’ll see — it all depends on what our readers say. And so I hope you’ll [give Serendipity a try!](https://www.theatlantic.com/serendipity) And please let me know what you think at andrew@theatlantic.com. Excited to hear from you.

_Endnote:_ The New Yorker _has published their own cool new-tab Chrome extension [here.](https://chrome.google.com/webstore/detail/the-new-yorker/apbnnoblhichgncodkjnmlbgmdclkmco?hl=en)_



Earlier this month, hackers used a massive botnet to spam Dyn, a domain name service provider, and block access to dozens of popular websites. It turns out [the worm that recruited the botnet](https://github.com/jgamblin/Mirai-Source-Code) targeted IP-connected devices, including an old brand of webcam popular in warehouses and industrial settings. 

Scanning the internet for open ports, the Mirai worm connected to unsecured servers and ran through a common dictionary of passwords, including `xc3511`, which unlocked the webcams. (There's a good writeup on the mechanics of the bot [here.](https://www.incapsula.com/blog/malware-analysis-mirai-ddos-botnet.html))

Let me first say that [this didn't affect many residential users.](https://www.wired.com/2016/10/internet-outage-webcam-dvr-botnet/) Very few people plug their devices directly into their modem; pretty much everyone filters their traffic through a router, which has ample safeguards. Plus, many of the devices targeted by Mirai were super old. 

All the same, I wondered if this was really a big deal. The internet is huge—there are _so many_ IPv4 addresses out there. Even if I had been playing fast and loose with security, weren't the odds astronomically small that a hacker would randomly happen across my server and take notice? 

So I devised an experiment.

My fake web toaster
------
I decided to set up a honeypot—a purposefully unsecured server that would give hackers the illusion of control, but would actually record their keystrokes and IP addresses. I could have used a Raspberry Pi and connected it to my home router (using port forwarding to bypass security), but in the interest of time, I ended up running a virtual server through Amazon's EC2 service. 

I wrote [a Node script](https://github.com/arm5077/mirai-honeypot/blob/master/index.js) that mimicked a Telnet login on port 23, asking for a username and password, and delivering a faux shell prompt. To a hacker's scanning script, it would look like a real Telnet server. In honor of one of the internet's [first connected devices,](http://www.livinginternet.com/i/ia_myths_toast.htm) I had it masquerade as a web-connected toaster. Here's what the hacker would have seen when they tried to log in: 

<figure>
    <img
        src="/images/blog/2016-11-02-making-a-honeypot-to-tempt-the-mirai-botnet/intro-cli.gif"
        alt="Rendering of a terminal login screen reading &ldquo;I'm The Atlantic's utterly unsecure internet toaster! You should hack me."
    />
</figure>

I set the thing up and stepped away, expecting to wait a while before recording a hacking attempt. Wrong. The first unauthorized login came within an hour, using `root:root` as login credentials.

<figure>
    <img
        src="/images/blog/2016-11-02-making-a-honeypot-to-tempt-the-mirai-botnet/hack-attempt.gif"
        alt="Demonstration of a hacker remotely entering a username and password into the terminal."
    />
</figure>

Over the course of the next 12 hours, the server registered around 300 attempted hacks. I wrote about this experiment for _The Atlantic_ [here](https://www.theatlantic.com/technology/archive/2016/10/we-built-a-fake-web-toaster-and-it-was-hacked-in-an-hour/505571/) (and talked about it on [_All Things Considered_!](http://www.npr.org/sections/alltechconsidered/2016/11/01/500253637/an-experiment-shows-how-quickly-the-internet-of-things-can-be-hacked))

What does this tell us?
------
I admit that this project is flawed in a few ways:

- **It wasn't a real IoT device.** This doesn't bother me quite as much; the Mirai bot doesn't seem to exploit any device-specific security bugs, so a generic server with an open port fills the role fine. But there's no doubt that _other_ worms take advantage of weaknesses inherent to specific IoT gadgets, so it would be interesting to more closely simulate them.
- **I didn't conduct the test over residential wireless.** I bet hackers closely monitor Amazon's IP range, looking for unsecured server instances spun up by rookies. If I had run my script through my apartment's internet connection, I probably would have seen fewer login attempts. That said, the security folks I spoke with agreed any unsecured server would have eventually been breached, probably within a day to a week.
- **Most consumer IoT devices don't connect to the internet directly.** Like I said above, most routers will kill the most obvious routes hackers use to gain control of computers. So the average person hooking up a webcam to their WiFi is probably OK. It would be interesting to simulate the security defects of older routers, and try to get a sense of how many of those exist in the wild. 
- **IPv6 might solve these problems.** The new protocol allows for _way_ more possible addresses—like, 7.9x10<sup>28</sup>. Assuming addresses were randomly distributed (and I have no idea if they will be, or anything about this protocol beyond what I've read on Wikipedia, to be honest), the sheer amount of territory hackers would have to cover might give me the effective anonymity I thought I already had.

I did get a few tweets that linked to this [xkcd comic](https://xkcd.com/350/), the thought being that my experiment is nothing new: Security folks have been setting out unsecured honeypots for years. 

That said, I think this story illustrates a few things that most people didn't know:

- **The Internet isn't that big (not yet), and it's packed with hacking scripts.** Bots scan the IPv4 space frequently enough that nearly every computer that's not behind a firewall can count on being recorded in less than a day.
- **The Mirai bot is still out in force.** Many of the hack attempts used the same sequence of password (and shell commands) outlined in the Mirai botnet's code. It appears other folks have spun up multiple copies of the bot and are busy recruiting unsuspecting servers.

My toaster experiment isn't a situation most consumers will face. But it's an accurate analog to the plight of the kinds of unsecured devices harnessed by the Mirai botnet, and shows how quickly they can be pulled into a hacker's thrall.

_**June 2023:** When I was hired at The Atlantic in 2015, my editor told me that my writing was impressive and I was certainly a bright young man. But what had sold him, he confessed, was this blog post. It showed I knew how to have fun._

Last month, someone dropped a crumpled Kleenex in the stairwell of my girlfriend’s apartment building.  No one — myself included — wanted to pick it up. It sat there for weeks, a miniature rebuke to all of us.

Yes, I could have just cleaned it up. But what happened next was more fun — and gave me a new respect for my neighbors.

<figure class="bump-out">
    <img
        src="/images/blog/2014-03-06-the-case-of-the-fallen-cloud/cloud1.jpeg"
        alt="A series of miniature police officer figurines positioned around a fallen tissue."
    />
    <figcaption>The scene of the crime</figcaption>
</figure>

I bought a set of [Bachmann Trains miniature police officers](http://www.amazon.com/Bachmann-Trains-33104-Police-Squad/dp/B001RG29W8) and set up a perimeter around the tissue, securing them to the floor with double-sided tape.

<figure class="bump-out">
    <img
        src="/images/blog/2014-03-06-the-case-of-the-fallen-cloud/cloud2.jpeg"
        alt="Two police officers talking to a third."
    />
    <figcaption>Two officers reporting to their lieutenant</figcaption>
</figure>

No, the patrol officers aren’t wearing Pittsburgh uniforms — but the white-shirted lieutenant would fit in!

<figure class="bump-out">
    <img
        src="/images/blog/2014-03-06-the-case-of-the-fallen-cloud/cloud3.jpg"
        alt="An officer calling to the tissue through a bullhorn."
    />
    <figcaption>An attempt at communication</figcaption>
</figure>

I figured I’d leave it up for a day or two and then clean the whole mess up. But the next day… this showed up.

<figure class="bump-out">
    <img
        src="/images/blog/2014-03-06-the-case-of-the-fallen-cloud/cloud4.jpg"
        alt="A note left alongside the police officer scene"
    />
    <figcaption>How surprising</figcaption>
</figure>


The text: “Clouds fall from the sky/No one wants to notice them/Art makes us all smile. ” What an awesome neighbor!

I left behind a thank you…

<figure class="bump-out">
    <img
        src="/images/blog/2014-03-06-the-case-of-the-fallen-cloud/cloud5.jpg"
        alt="The police officers lined up behind a note"
    />
    <figcaption>Thanks for the support</figcaption>
</figure>

<figure class="bump-out">
    <img
        src="/images/blog/2014-03-06-the-case-of-the-fallen-cloud/cloud6.jpg"
        alt="A close-up shot of the police officers lined up behind a note"
    />
</figure>

The next day, got one final message back:

<figure class="bump-out">
    <img
        src="/images/blog/2014-03-06-the-case-of-the-fallen-cloud/cloud7.jpg"
        alt="The police officers collected inside a sunflower"
    />
</figure>

Sometimes it pays to sit back and see where things go.


I never suspected the meter maid. 

Sure, we take constant, unblinking (if mostly uninterested) surveillance for granted these days, but I blame the usual suspects: the FBI, ATM cameras and those not-so-discreet bubbles above cashiers at the grocery store.

Then I read an [ACLU report](https://www.aclu.org/alpr) on automatic license plate readers, [an emerging class of high-speed cameras](http://en.wikipedia.org/wiki/Automatic_number_plate_recognition) that can scan and identify thousands (millions?) of passing cars per hour. The idea is that a computer can run photographed plates instantly through a carjacking database and alert police if a stolen vehicle drives by, but the ACLU found that many police agencies were keeping all the non-hits as well, building massive databases of when and where people were driving.

After looking through [the ACLU’s online map of records-request responses,](https://www.aclu.org/maps/automatic-license-plate-reader-documents-interactive-map) I realized one unexpected Pittsburgh agency was very interested in the technology: Our municipal parking authority.

Yep, the folks who ticket you for pulling too close to the hydrant.

Apparently, the PPA was using the cameras to find folks who had amassed obscenely high fines, stopping as they passed by on the street and booting their cars. Through Pennsylvania’s open records laws, I obtained from the authority a database of every car scanned in August 2013 by the PPA’s two boot trucks, who toodle throughout Pittsburgh most weekdays.

Turns out those two trucks are really freakin’ efficient, scooping up between 150,000-200,000 license plates every month. And sure enough, they weren’t deleting the licenses plates that DIDN’T have fines.

Filter that database by a certain plate number, voila: You can track a car’s location through the city. For example, here’s a screenshot of all the locations license plate HYN8398 had been scanned. (That plate belongs to a shuttle van, so it chills downtown a lot.)

<figure>
    <img
        src="/images/blog/2013-12-23-how-to-track-license-plate-cameras-tracking-you/license-plate-1.jpg"
        alt="A map of a number of scanned plate locations"
    />
</figure>

Kind of freaky, huh?

I ended up writing [this story](http://www.post-gazette.com/neighborhoods-city/2013/09/22/Pittsburgh-s-parking-authority-snaps-200K-motorists-a-month/stories/201309220010) about the practice, highlighting a lady from the city’s Beechview neighborhood who had unwittingly been photographed all around town. The Parking Authority eventually responded, [promising to clear out its database daily.](http://www.post-gazette.com/neighborhoods-city/2013/10/17/Pittsburgh-license-plate-data-on-lockdown/stories/201310170254)

## How I did it

This data came on two USB drives in a collection of wonky, 40,000-entry HTML tables. Concatenating those together using Notepad++, I opened the combined file in Excel and converted it so a CSV (it was only about 150,000 lines, so not a problem for Excel 2007 and up). Dumped that file in Access.

I quickly figured out that some of the reads were duplicates — the camera would have two separate images at the same location and the same time. To get rid of those, I used Access’s “find duplicates” wizard [along with this method,](http://www.techrepublic.com/article/eliminate-duplicate-records-with-this-built-in-access-query/) using the timestamp (which was unique) as my primary key.

The database would also use a regular expressions-like syntax for a license plate’s number if the camera didn’t get a full read. I want those included when querying for the count of unique plates, so I made sure to include a `NOT LIKE “*[[]*”` clause in my SQL.

That gave me a reasonably clean list of unique moments a license plate had been photographed. But now I wanted a good example for my story — a person who had been photographed multiple times at disparate locations in Pittsburgh.

Standard deviation to the rescue. Calculating the standard deviation between any given plate’s various scanned latitudes and longitudes let me pick out vehicles that had been photographed multiple times and in different places.

At the same time, I had to actually find these cars, too. So I looked within the set for plate numbers that also had modest clusters of records very close together in a residential neighborhoods, wagering that might be where its owner lived. That’s how I found Donna Scuilli: Here’s what a portion of her records looked like mapped out.

<figure>
    <img
        src="/images/blog/2013-12-23-how-to-track-license-plate-cameras-tracking-you/gbs-car-detail.jpg"
        alt="The view of Donna's street from above"
    />
</figure>

I also built uploaded the database to a mySQL server and built a [simple web tool empowering people to search for their own license plates.](http://newsinteractive.post-gazette.com/tracking/) It wouldn’t show them where they had been scanned — what if a guy put in his ex-wife’s plate number and found her new house? — but it would show them how many times they’d been photographed and when.

Take me: I was scanned 3 times (all while parked on my street).

<figure>
    <img
        src="/images/blog/2013-12-23-how-to-track-license-plate-cameras-tracking-you/scan-app-closeup.jpg"
        alt="The UI showing how many times my car was scanned by ALPR readers"
    />
</figure>

I’ve uploaded the cleaned dataset (no duplicates but still ambiguous plate numbers) [to Github.](https://github.com/arm5077/pgh-ALPR-records)


Last week, I got an email from a man named Jerry Green in California. “I saw your byline in a newspaper out here,” he wrote. “Are you the Andy McGill I knew 30 years ago working at the Detroit News?”

Unfortunately, I’m not. This Andrew McGill met Jerry at least six years before I was born, and I’ve never been to Detroit. I wrote and told him that with regrets. But the idea of another Andrew McGill in journalism fascinated me. What did he do at the Detroit News? What kind of reporter or editor was he? Did he have dashing good looks?

Jerry wrote back with more information. 

“Andy McGill, back in the early 1980s, was an assistant managing editor at The Detroit News, for which I worked in the sports department from 1963 until retirement in 2004 and actually for which I still work as a freelance contributor. 

Andy was a very good guy… supportive and passionate about journalism. He left the paper, I’m guessing, around 1990 or so.”

My interest was piqued. A Google search of “Andrew McGill Detroit News” didn’t turn up much – a few bylined articles in the News dating back to the late ‘80s and early '90s. And he wasn’t listed on the paper’s website.

But a Lexis-Nexis search did reveal one Andrew Ralph McGill, now 67, living in Ann Arbor, Michigan. 

Not only did this alternate Andrew McGill share my name, he shared my middle initial. (Mine is Robert.) The ages matched up, and I could see an old newspaperman moving to Ann Arbor to retire.

It had to be him.

I called the number. Got a voicemail. Halfway through leaving the message – “Hi, I’m looking for Andrew McGill, and my name is, uh, also Andrew McGill…” – Andy picked up.

He had just walked in the house and heard me leaving my message. If he was surprised that a 23-year-old was calling him out of the blue from Pennsylvania, he didn’t show it.

Andy McGill was born in Michigan, but his moved family moved to Florida when still a boy. That’s where he picked up journalism, writing sports for small papers and eventually working his way up to the Miami Herald. But Michigan called back to him, and in the early 1970s, he returned to the Great Lakes State as part of a team that intended to turn the Detroit News around. 

There he stayed for the next 20 years. You could hear the pride in his voice. He left when the Gannett Co. bought the newspaper, briefly moving to California to head Automobile Magazine. As he put it, “I looked around, and everyone at the 10 or so jobs better than mine were all my age. They’d retire when I’d retire.”

So he headed back to Michigan and settled in Ann Arbor, teaching journalism at the University of Michigan. Even though he’s fully retired today, he still teaches a few web classes.

He remembered Jerry Green and had plenty of compliments. (Mr. Green, apparently, is one of the few sportswriters who has been to every Super Bowl.) He also remembered The Morning Call, saying he read some interesting coverage when he had reporters in Pennsylvania for the 1980 presidential election. And we had a good chat about what we’d like to see survive in journalism.

I gave him Jerry Green’s email and left him with a promise to show him around Allentown if he ever swung by. Jerry wrote me later to say Andy had immediately reached out and that they planned to talk soon.

What an affirming conversation. Long before I was born, Andrew Ralph McGill was paving the way in newspapers. What has come before will come again. More importantly, it was proof that you can still pick up a phone, dial a stranger and have a good conversation. 

Thanks, Andy. Nice to meet you.

What I learned in my company's first six months