Amit Patel on making things
For decades, Amit Patel’s interactive explainers have been reference points for programmers, game developers, and curious people on the internet. Red Blob Games is one of my personal favorites.
As part of the Making things project (intro here), I asked Amit how someone starts and sustains that kind of work: how he chooses projects, makes them great, and sets them free. We got to dive deep over a long email chain.
(This transcript has been edited for clarity.)
Bobbie Chen (BC): When anything is possible, how do you decide what to create?
Amit Patel (AP): Honestly, the biggest factor is whatever I'm interested in at the time. But the style of project depends on my goal.
In the trading card game Magic: The Gathering, there’s a "deck building" part where you expand your capabilities. Then there's a "battle" part of the game where you put those capabilities to good use.
I try to model my projects the same way. Some projects are "deck building", to learn new things. Some projects are "battle", to use the things I've learned. Not everything I learned will get used, but it's important to spend time learning new things so that I have more skills for future projects. This is the exploration-exploitation tradeoff.
I distinguish these on my site. My learning projects are in the /x/ folder on my site, and these are usually time limited to 1 or 2 weeks ("timeboxing") but scope unlimited. The non-/x/ folders on my site are usually scope limited but time unlimited. Those are where I put to use the things I've learned.
I maintain a list of possible projects to choose from. When deciding, I'm usually combining an emotional aspect (what topic makes me most excited to work on) and economic aspect (what are the costs and benefits). I think of "economics" broadly, not specifically about money:
Pick projects that have a high benefit.
If it's a learning project, pick things that let me learn a lot.
If it's a tutorial project, then pick something that many people are interested in.
For tutorials, I also try to think of the"marginal" benefit. I generally prefer to write about things that haven't been explained yet, or write about a different aspect of them.
Pick projects that have a low cost to me.
If two projects have the same value but one is much easier to implement, then I tend to pick that one.
For example I have a lot of code sitting around for hexagons, so projects involving hexagons are often quick for me to make.
I ended up picking topics that are visual, but small enough to fit on a web page. A downside of this strategy is that I can end up in a local maximum. And sadly, I think I am already in a local maximum. I keep revisiting map projects and making interactive web pages instead of trying something completely different. So it may be time to try a different approach.
BC: If someone else can create it, why should you?
AP: I've been trying to think less about "should". Especially for creative works, I find that when I think about what I "should" do, it often makes the results worse. "Should" is an external motivation, but I want to move to internal motivations. I've been asking myself these questions:
Is it that I want it to be done? Would it have been done if I didn't? (Additionality)
Is it that I want to have done it? Would I be happy if someone else did it? (credit)
Is it that I want to be doing it? (achievement/process)
I want to have a mix. I want to do some things for the experience and some things for the accomplishment. I want to do some easy things and some hard things. Some fun things and some unfun things. Some things just for me and some things for others.
Once I wanted to make a game based on conveyor belts, and then I learned about another game that did something similar. I had to ask myself: if I want there to exist a game about conveyor belts, then I should be happy that someone else did the work. But if I want to have made that gamemyself, then I would want to continue my project.
There are often times I want to have done something, but when I sit down to do it, I don't actually want to do it. That's ok.
And sometimes the problem is that I don't know how to do it. That's ok too.
But when I tell myself I "should" do something, and I don't, I end up feeling guilt. I'm trying to get better at letting go of that guilt.
A downside of this strategy is that sometimes you have to actually do the hard thing before you can get to the fun thing. Without any external pressure on me, I haven't been doing some of the hard things when there are so many easy things I could be doing instead.
BC: I see a lot of ambition in what you're saying: the desire to learn new skills, reach many people, do "hard things", and not limit yourself in a local maximum. Do you ever feel like you'll have "enough" (skills, people reached, hard things accomplished, potential reached)? How will you know?
AP: Yes! I do feel like I have "enough" with Red Blob Games.
I realized my "big hits" are behind me: Hexagons (2013), pathfinding (2014), and map generation (2017). I never did end up writing games or turning it into a sustainable business.
Red Blob Games isn't the only thing in my life. There are plenty of other things I want to do. So I will keep working on Red Blob Games but I don't expect it to be much bigger than it is now.
There's a related concept of "maximizing" vs "satisficing". When maximizing, I would often try to optimize for some specific metric like "views" or "likes" or "wishlists" or "revenue", instead of spending my effort on something that doesn't have a metric, like how enjoyable or useful my page is.
I thought about all the best things in my life, and … they don't have metrics. I started out a maximizer but realized that I'm happier and healthier as a satisficer. I'm trying to spend more of my energy on things that aren't measured and optimized. A downside is that I have become less ambitious than I used to be. I'm working on smaller projects these days.
BC: You mentioned one motivation is to "want to have done something”. That sounds a bit like "Type 2 fun", experiences that are unpleasant in the moment but satisfying in retrospect. But do you ever find yourself looking back, and realize it was actually not fun at all?
AP: Yes, but I've also done the opposite. I've done things that I thought would not be fun but turned out to be fun after all. Our brains are funny. We don't remember the average amount of fun we're having, but insteadit's weighted towards the most intense and the end of the process. A hike might be grueling but we might enjoy it at the top of the mountain, and that can outweigh the hours of non-fun going up. Daniel Kahneman's book Thinking, Fast and Slow called it the "experiencing self" vs "remembering self".
BC: When you were just getting started, was there particular advice, experiences, or communities you found helpful? And if you were talking to a new person who wants to create new things, what would you tell them?
AP: It was a long time ago, in the pre-internet days. We didn't have online tutorials or forums or social media, so there was no quick way to get a question answered. We learned by reading books and magazines and documentation. When we did get forums, they were small communities, not the large ones we have today. We didn't have search engines we could count on, so when we found good things, we bookmarked them, curated the bookmarks, and shared that knowledge in our communities. My site started out as a collection of curated bookmarks before it grew into a place where I wrote articles.
So take my answers here with a grain of salt: a lot of how I got started won't apply today.
Some advice I got and heeded:
There's only so much you can learn from tutorials. You can read books and watch videos about riding a bike but to actually learn you have to sit on the bike. You're going to fall down. That's ok. That's how you learn some things.
Advice I got way too late in life:
People often fall into the trap of waiting for motivation to do something. But a lot of motivation comes after starting the work. Do something even if small to get the ball rolling.
Advice I wish I had gotten:
Especially for creative work, you should experiment. Try things, learn the standard advice but also try the opposite. Learn the reasons for things.
In programming there are lots of rules about coding style. Follow them for a while. Then do the opposite. See what happens. You'll learn a lot.
In photography, there's the rule of thirds. Follow it for a while. Then try not following it. What happens?
In gamedev, there's the rule that you should start with small games. But what would it take to write an MMO in one week? Try it. See what happens.
You can learn a lot by going against the common wisdom. Sometimes you'll learn that the rule only applies some of the time. Sometimes you'll learn that the rule is outdated. Sometimes you'll learn the reason why you should always follow that rule.
Advice I wish I hadn't gotten:
How to maximize productivity, hustle, efficiency. I didn't realize until later that maximizing productivity might be getting in the way of creativity.
I like to think of having a "coffee mode" and a "beer mode". When I want to increase creativity, I need to work less. Take a break. Go on a walk. Get inspiration from outside of work. But when I want to increase productivity, I need to switch to a different mode. Pay attention to where my time goes. Reduce distractions. Turn off wi-fi.
I need both of these phases. A lot of my creativity comes from things I discovered while in coffee mode. But a lot of my productivity comes from ideas I had while in beer mode. When I'm in coffee mode all the time, my work suffers. And when I'm in beer mode all the time, my work suffers. I need to alternate between them.
Think about what you're creating, why you're creating, who it's for, and how long you want it to last. What worked for my web site was to focus on what's timeless instead of what's ephemeral. Aspects of this:
It's fun to get a lot of "likes" for making something that goes viral. But what really matters to me is creating something that people still use/enjoy after months or years.
I focused on the math and algorithms, though I could have also written tutorials for the game engines of the 1990s. Those old game engines aren't around anymore, but the core ideas for the math and algorithms are just as relevant as they were then.
If I had focused my content on social media sites, I'm at risk of it all going away. It was more work to make my own site but it's something that can last a long time.
When choosing what technologies to use, I think about whether I can still update the project 30 years from now. This guides me towards "boring" technologies that will last a long time.
In addition to what's public I keep lots of notes on private web pages. I don't spend a lot of time organizing them. They're something I can reach for years later. Sometimes I organize my notes into a public page. Sometimes I use it as part of a new project. The value isn't something that shows up right away.
Advice I've gotten but also gotten the opposite of:
Announce your plans. I've heard that if you tell everyone your plans, it's a commitment and you're more likely to follow through. But I've also heard that if you tell everyone your plans, it reduces the motivation, and you're less likely to follow through. Some advice you'll get when starting out is contradictory! That's ok. There's no silver bullet. Life is messy.
BC: Amazing, thank you Amit. Last question is a free soapbox: is there anything that you wanted to talk about that wasn't covered already?
AP: People say "follow your dreams" but I think that advice is incomplete. Dreams are malleable. Don't limit yourself to what you're dreaming today! You're changing. The world is changing. You can follow a new path if you want.
See what Amit Patel is up to now at Red Blob Games.
Or check out the other interviews about making things with Nolen Royalty, Morry Kolman, and Seth Larson.