I've tried twice to grow coffee from seed at home and bought coffee plants on a few occasions. In this post, I want to document my attempts and what I've learned both for my own notes and in case other people want to give it a try.

If you haven't had a good look at a coffee tree before, here are some pictures I took at Kew Gardens in London. The tree they had in the greenhouse was coffea canephora (robusta), but they're also doing research on other species of coffee that may help protect coffee against threats from climate change.

On the surface, growing coffee sounds pretty doable: the coffee we drink is the roasted seed of the coffee plant after all, and Trader Joe's sold coffee plants as indoor house plants that one time. Since I have roaster friends around the Bay Area, it wasn't too hard for me to get access to coffee in different stages of processing to play with.

My First Try: Starting with Cherry

When I was taking classes at Boot Coffee Campus, they had a pair of coffee trees growing in a raised planter by the door. That tree had fresh fruit and flowers, and it was the first time I'd tasted coffee fruit.

These trees are really beautiful in person. They have long, slender branches and the leaves hang off them in orderly rows like strung-up lanterns or dangling paper kites. The red fruits sit tantalizingly at every node, and the flowers held aloft by the branches catch every passing breeze and fill the area with a fragrance like strong jasmine and faint perfume.

Because I started from fresh fruit, the seed was still wrapped in a protective layer of parchment. This sturdy layer is removed during coffee processing, leaving the green coffee seed. I tried germinating the coffee in the parchment at first, and while it was slow, several of the seeds did manage to germinate that way. After a while, I got impatient and started soaking them in water. This greatly sped up the germination process and softened the parchment, allowing me to remove it manually.

I germinated them on the surface of the soil, which was tedious because I had to mist them every few days for weeks on end until they put roots into the soil. I considered just sandwiching them between some moist towels, but I feared that this would cause mold. It would also have been easier if I buried them in the soil and covered the seeding tray with a greenhouse cover (e.g. clear plastic lid) since the soil would keep them evenly moist without having to water them as often, however the downside is that you can’t see if they’ve germinated or not. Since it takes almost two months to germinate, it’s a long wait and I wanted to check that my seedlings were alive. For a grower with a lot of parchment coffee or whole cherry, a “spray-and-pray” approach where you bury 3 cherries in each nursery pot and then thin them down to one per pot after they germinate might be more efficient and reliable, but when you only have a handful of cherries and want to maximize the number of viable seedlings, you kinda want to baby them (perhaps more than is good for them).

Here are some photos of the germination process starting from the seeds that I extracted from the coffee fruit to the point where the seedlings unfurled their cotyledons (seed leaves).

My attrition rate was really high. I started with about 12-15 seeds and ended up with two surviving plants. If I recall correctly, about 10 germinated, 6-8 made it to the soldier stage, and then 4 survived to put out true leaves. I think I could've improved my germination process, which would've given the plants more energy to grow through their early seedling stages.

Here they are putting out their first true leaves:

Here's what they look like after a year of growth. You can see the round cotyledons as the lowest pair of leaves, but the plant has since grown several pairs of true leaves (which are pointed).

I suspect they're growing slower than they should, but my house is neither an Ethiopian cloud forest nor the Panamanian mountains, so I'll let them take their time.

My Second Try: Buying A Plant

I got impatient and figured I'd hedge my bets, so when I saw that FRINJ were selling coffee trees at SF Coffee Fest, I bought one. FRINJ is a California based coffee grower and one of the only producers in the continental United States. If anyone had trees that were well-adapted to the California climate, I figured it'd be them.

Some sources on the internet say that coffee plants take a few months to get to be a few inches tall, then within the first year, they should be around 2 ft. This lines up with the tree I got at Coffee Fest. I think it’s about a year old. All told, buying trees from FRINJ for $35 seemed like a good deal given how many hours of babying it took for me to get two viable plants from seed.

I had to carry the tree in my backpack across San Francisco and take it home on public transit, which was fun.

If you want a coffee plant of a variety actually known to produce good quality coffee, you can order one from them online – you don't need to grab it in person like I did. Unless you have a full-scale farming operation, it's unlikely that you'd grow enough coffee at home to process, roast, and brew for yourself, but I'm still debating growing a small coffee garden to have some demo plants to use as educational aids.

FRINJ Geisha Coffee Trees - FRINJ Coffee

COFFEE PLANT CARE INSTRUCTIONS This coffee plant originated from plants grown organically in the hills of Santa Barbara, the home of California’s first commercial coffee farm. With just a little sun, moist soil and occasional feeding this tree will make […]

FRINJ Coffee

FRINJ Catuai Rojo Coffee Trees - FRINJ Coffee

COFFEE PLANT CARE INSTRUCTIONS This coffee plant originated from plants grown organically in the hills of Santa Barbara, the home of California’s first commercial coffee farm. With just a little sun, moist soil and occasional feeding this tree will make […]

FRINJ Coffee

After a few months, my tree is still doing well and has put out new leaves. I up-potted it into a tree-sized nursery pot and it seems happy there.

I put the planter on a rolling tray and wheeled it out for various coffee events. I find it easier to explain the process of creating coffee to people when they can see it as a plant instead of thinking about it as a bagged product.

Varieties

I’m unsure what any of the coffee plants I have are. I think the FRINJ one is Red Catuai because it has a red tag on it. The seedlings came from the two trees from Boot, but I’m unsure which they are: one tree was a gesha, the other is unknown. Maybe when they grow up I can try to identify them.

Geisha, Bourbon, & More: How to Identify 6 Coffee Varieties

Do you know what Geisha/Gesha looks like? How about Bourbon? Read on to learn more about identifying coffee varieties.

Perfect Daily GrindSawang Thongdee

My Third Try: Germinating Green Coffee

Again, green coffee is just the coffee seed, removed from its outer layers. Some aggressive processing methods might chemically affect the seed, but processes like washed and natural coffees aren't too different than the processes that a coffee seed might encounter in the wild. I figured it was worth trying to get some green coffee to germinate. How cool would it be to be able to serve someone an excellent pour over and then show them a small plant germinated from the same coffee seeds?

Tom from Sweet Maria’s says he’s tried growing coffee from green but it doesn’t work for him (25-30% germinated, and about 1 in 50 germinated seeds actually grew). I soaked about 300 seeds and hoped to get at least one live start.

I read up on several guides on how to germinate green coffee, and settled on just soaking them until they put out embryos.

How to Grow a Coffee Plant at Home

This guide will outline how to grow your own coffee plant, how to care for the plant, tips for growth, and common questions.

Real Good Coffee Co.Adam Gante

A good number of them actually germinated. I should've taken more detailed notes at the time, but I think about 30% of the green coffee I soaked germinated.

For a moment I thought that I might actually succeed in getting a live plant out of this process given that I had over a hundred germinated seeds, however it takes a long time to go from germination to an established plant. The embryo needs to grow big enough to reach the soil, put down roots, and then grow a sprout strong enough to lift the seed off the ground. That can takes months.

Tom mentions that you should plant the seeds 1.5” deep in a pot that has space for a taproot (which adds up to a pretty deep pot). This tracks with the photos James Hoffman has in World Atlas of Coffee (on page ~18?) where there’s a grid of deep pots. The tree I got from FRINJ came in a roughly 4x4 by 12” deep nursery pot.

Thinking back to the seeds I started from parchment, I wondered if this had something to do with why a handful of my “soldiers” (seedlings at the “bean on a pole” stage) died. They’d start to grow black from where the embryo exits the seed and progressively blacken down the stem until the whole seed was drooping and the stem withered off. I started mine in seeding media: peat pellets and cardboard cells that you’re supposed to be able to directly transplant into the ground and let the roots grow through them. I think some of the plants did grow roots through the starting media when I repotted them into 4” round x ~6” deep nursery pots, but I wonder if some of the ones that died did so because they failed to grow through the cardboard/webbing at the bottom of the starter media.

The alternative theory is that the seeds got too wet during this stage and started to mold internally. I noticed that the ones that turned black and withered were less far along in escaping the bean. For one of them, I think watering it accelerated its death. I saw a speck of black on the stem and thought maybe if I sprayed water on the bean it’d help soften the parchment and outer layers, but instead it just died after a few hours.

So for this experiment, I decided to put them in a large seeding tray with a cover. I still wanted to be able to see the seeds so I could monitor their progress, but the large tray had a cover and would retain moisture better, hopefully reducing the amount of time I'd have to spend keeping them moist.

Things started going poorly almost immediately. After a day or two, some seeds were turning a dark blue-green color and getting slimey.

I kept them for a few weeks over the winter holidays, misting them occasionally. By the time New Year's rolled around, they were covered in mold. I'll spare you the photos – they're upsetting. I threw out the whole batch.

If I tried it again, I think I'd do it like Tom recommended and bury the germinated seedlings. That way, when some start molding, the spores are contained in the soil instead of being free to float around and infect other seeds. I'd also start with fresher green coffee than the ones I used.

I suspect that if I had been more selective with the seeds and only focused on the most viable ones (e.g. the ones that germinated fastest, had the best shape, least discoloration, etc.), I might have been able to keep them alive for longer. However, I didn't have time to turn this experiment into a project, so I had to leave it there.

Viability

While my seedlings were dying, I found a study from 2007 evaluating the viability of growing plants from green coffee.

In all samples that were hulled prior to storage, >50 % of the seeds lost viability within the first 3 months of storage. After 6 months, the fraction of seeds still viable was <10 %. After 1 year of storage, all seeds were dead (Fig. 2). The mode of processing had no effect on the time course of viability loss. In contrast, the so-called ‘pergamino’ or ‘parchment coffees’ (German: ‘Hornschalenkaffee’) revealed a different pattern. These coffee beans were stored within the parchment (endocarp) and, although these samples were derived from the same processing batch as the corresponding wet-processed samples, the loss of viability was quite different. Even after a longer storage period than 1 year, more than half of the beans stored as parchment coffee were still alive (Fig. 2).

The Storage of Green Coffee (Coffea arabica): Decrease of Viability and Changes of Potential Aroma Precursors

When green coffee is stored for a prolonged time the coffee quality decreases distinctively. Apart from well-known ‘off-notes’ that arise from undesired oxidations of lipids, a typical ‘flattening’ of the cup quality is…

PubMed Central (PMC)Dirk Selmar

These numbers approximately line up with the numbers Tom reported. Processing coffee can take 1-2 months, followed by potentially 1-2 months of transit. By the time the green coffee arrives, it could've been stored for 2-4 months. According to figure 2 from the paper, the researchers found about 20% of seeds to be viable, which roughly matches up with Tom's germination rate of 25-30%. That said, Tom reported that of the ones that germinated, only about 1 in 50 successfully sprouted. That puts us in the range of about half a percent for seeds surviving, which the researchers estimate would happen after about 9-12 months. Coffee is considered "past crop" after about a year, so I doubt that Tom was trying to germinate coffee that's 9 months past harvest (especially since he's an importer and would have access to a constant supply of fresh coffee).

The paper had one other interesting note:

Imbibition by coffee seeds that had died a number of months before resulted in a characteristic appearance. During imbibition by dead seeds, many, mainly brownish substances leaked out, due to the disintegration and decompartmentation of the seeds. In contrast, imbibition of seeds that had been dead for only a few days or weeks resulted in a quite different picture: 2–3 d after imbibition, the dead seeds had acquired a dark blue-green colour (Fig. 3A). The characteristic blue-green colour is known as viridinic acid (German: ‘Viridinsäure’). This results from the oxidation of chlorogenic acids and subsequent reaction with primary amino compounds (Watanabe et al., 1996; Yabuta et al., 2001). Similar reactions are frequently visible as the result of injuries that occur during wet processing, especially in the course of mechanical pulping and demucilation (Fig. 3B).

[...]

Direct contact of enzyme and substrates should be a precondition for such enzymatic oxidation; this may occur in the course of decompartmentation due to cell-death-related disintegration. As mentioned above, the formation of the blue-green compounds only took place in seeds that died within a short time period preceding evaluation. However, in seeds that had lost viability several months before imbibition, these oxidation-induced processes could not observed, although in all cases the tissues of the dead seeds would have disintegrated. Consequently, the enzymes that are responsible for the post-mortem oxidation of chlorogenic acids are still active in seeds that have died within a short period preceding imbibition. In contrast, these oxidative enzymes were already inactive in stale seeds because of denaturation processes that proceeded during the storage of dead seeds.

This explained the blue-green color I was seeing on my seeds and in the serum from soaking the seeds: these seeds had died, but relatively recently. The green coffee I used had been imported some months ago, in addition to however long it had been sitting after processing and in transit. They hadn't been sitting around for years (which could've deactivated the oxidative enzymes), but they'd also had plenty of time to lose viability.

Conclusion

Having tried a few different methods for acquiring a coffee plant here are my thoughts:

• If you just want a decorative plant, just buy one. Many nurseries carry small coffee plants (around the size of my seedlings) that make good house plants.
• If you want a larger plant that might produce cherries, buy an established plant from a specialized coffee nursery or farm like FRINJ. This also ensures that you're getting a coffee plant of a specific, known variety. Many of the decorative coffee plants I've seen from general purpose nurseries only specify that the plant is coffea arabica (the species level) and don't list a variety because it's not likely to get big enough to produce fruit if it's grown in a small pot. As an educational tool, I'd want it to bear fruit, and it's better if I can explain what variety it is.
• If you plan to start from seed, buy seeds with the parchment (aka pergamino) layer still on. Unprocessed coffee seeds in the parchment are the most likely to be viable. You can get seeds in parchment of specific varieties from different nurseries and specialty seed shops. If you have a friend with a coffee tree, you can also ask for some cherry. Regardless of how you acquire your seeds, buckle up for a couple months of careful watering and waiting as you wait for them to push out of the ground.

As for me, I'm glad that I managed to get viable plants from the cherries I got at Boot. Those plants remind me of where I started this chapter of my coffee journey, and every time I see them, it reminds me of my instructors, my friends, and the memories I made taking classes there. Hopefully one day, my seedlings will grow into big trees that can produce their own cherries, and the cycle can continue.

Additional Links

For an introduction to Tom from Sweet Maria's, I like this podcast episode he did talking about his views about coffee tourism, as well as an episode he did with Lucia Solis discussing it.

Alright, this one's pretty nerdy, even by my standards. Brace yourselves.

I feel like I should mention up top that I have cautious feelings about the impact of generative AI on the livelihoods and esteem of artists who have traditionally designed and illustrated characters for tabletop games. Also, none of this is endorsed by the companies who make the tools I used. At the professional level, I favor having artists involved, and I hope we find good ways to integrate these tools into their arsenal. However, I happen to be artistically challenged, and I can't visualize characters without some help, so my table and I spent some time trying to get inspiration from ChatGPT.

We ended up with this process that produced pretty cool art that matched our (developing) vision for our characters in an impressive if sometimes inconsistent way.

The tl;dr is this:

1. Start with some visual inspiration, either art found online or AI generated portraits.
2. Use that art as a reference for making a 3D model using Hero Forge (a character builder tool for making D&D minis).
3. Tweak the pose, equipment, and colors of the 3D model in Hero Forge, then have ChatGPT translate those screenshots into high quality character art.

Looking at that list, you may be wondering why I ran the art back though ChatGPT if I started out with an AI generated portrait as inspiration. The main reason is control over details. When having AI generate the image purely from a text description, it has very few constraints which makes it hard to make small tweaks without ending up with a very different style. For example, you might want to change the character's pose or what weapon they're holding, or the color of a specific item. It's possible to do this iteratively by selectively regenerating parts of the image, but this is time consuming and cumbersome, and I think that it tends to drift away from your original style over time. By giving the AI a reference image and asking it to target a certain art style, I found it easier to control the details of the character.

Step 1: Visual Inspiration

• For some characters, we used existing art that we found online as a placeholder character portrait. This is common, especially for NPCs. None of us have a strong sense of what these characters look like, so it's easy to find something acceptable and just move on.
• For characters that had established visual elements or that were important enough for us to develop custom looks for, we used ChatGPT interactively to discuss the characters, and it generated concept art for us using its integration with DALL-E.

This is the starting prompt I used:

Hey can you help me design a character for D&D? I've been playing this character for a while but I don't know what he looks like. I'm going to tell you a bit about him, and then I'd like you to ask me questions to refine how he looks. Finally, I'll ask you to generate some images based on our conversation. Sound good?

I think just saying it was supposed to be a character portrait for D&D did a lot of heavy lifting in terms of establishing the visual style. It implies things like "fantasy", "painterly", "portrait framing", etc.

The results were helpful in three ways:

1. Chatting with ChatGPT about the character's appearance helped us develop them iteratively. For someone who doesn't think visually about characters, it was helpful to have the AI prompt me back with questions about details.
2. Even though the generated art doesn't perfectly capture the tone of the characters or could contain extraneous details that are hard to remove, it looks nice. It's evocative and makes a character sheet/token feel more personal. The goal of the art is to aid in roleplaying and immersion, so it doesn't have to be perfect, it just has to set the tone and remind us of key details about the characters.
3. The faces are detailed and unique. Ok, this one is more subtle, but it's important for the next step. Interactive character builders like the one we used to create 3D miniatures ("minis") of the characters are like videogame character creation screens. There's often a limited number of stock faces and body parts to use as a base, so often characters will look same-y. The tool we used, Hero Forge, has very detailed customization controls that affect the face mesh, but since I'm not a sculptor, I can't use them right without a reference image. That's where the generated art comes in: the faces are pretty unique and give me a target to aim for.

Step 2: Turning It Into 3D Modeled Minis

So the next step was to use the reference images to create models in Hero Forge.

Hero Forge has a set of stock face shapes. They tend to be a bit cartoonish, (probably to make them easier to see when they're on a 1" tall mini), and if you over use the same ones, characters won't look very unique. Humans are very sensitive to the geometry of faces, so even small tweaks can lead to unique looking characters. For that, I delved into the advanced tools in the Hero Forge face editor and tweaked the dimensions of each part of these characters' facial anatomy until they were close to the reference images.

Because I backed one of their Kickstarters, I have access to a Hero Forge feature that lets me make spinny GIFs of the models. Take a look:

And introducing some new characters:

This is Callum, an NPC who became an Oath of Glory Paladin through the tragic loss of three of his friends in an ill-fated encounter with a fire elemental. We started with art from internet for him since prior to the encounter with the elemental he was a minor NPC. As a result, I don't have his source art to share.

...well once our characters (Bud and Gliran) heard about the demise of the rest of the NPCs (Callum's friends), we had to go clean up after them, so we went to fight the elemental. That fight felt so unwinnable that we turned to superstition.

See, the dice give and they take away. They're fickle. But they have one weakness: reverse psychology. If we wanted our characters to live, they'd definitely die, and we had just invested a few hours in developing art for them, so the dice knew we were invested. Not good. To convince them otherwise, we devised a scheme:

• My friend asked me to come up with the class and lineage of his next character. Knowing him, I picked a combo that he'd never pick for himself: a genasi bard. Genasi are half-elemental people, so like fire hair, or water hair, or wind hair, or crystals for hair. (Sounds like lazy writing when I say it out that way, doesn't it?) Turns out he had never even opened the players handbook to the bard page, so mission accomplished.
• Then, during the fight, every time he had to roll for something important, I'd whip out Hero Forge and start working on a model for the genasi bard while we loudly proclaimed how much more fun it would be to play that character than the ones we were playing now. Because of course, the only way to convince the dice that we were even more serious about this character than the ones we just made art for was to pretend to make and buy a physical mini, the next level of commitment.

By making the 3D models, we could control the details of their faces, items, colors, and motifs. Working in Hero Forge can feel unconstrained in a different way, where without reference art, it's easy to make unnatural looking faces by playing with all the sliders. Starting with some generated art fixes that. On the other hand, it's a lot easier to experiment in Hero Forge when customizing the way the character feels because you get immediate visual feedback when adding items, changing body proportions, tweaking their stance, and fiddling with colors.

Step 3: Pose The Models and Regenerate the Art

I tried to constrain the type of image that got generated by starting with a posed image of the mini against an appropriate background.

Let's start with Callum.

Here's the prompt I gave ChatGPT:

I have a 3D rendered character token for a D&D character, but I'd like help generating a more realistic, illustrated portrait of him. His name is Callum and he is an Oath of Glory paladin. He's 18 or 19 years old, and despite his youth, he's become more serious lately due to the loss of some friends.

And this is what it gave me:

And then for our edgy-boy, Bud:

I have a 3D rendered character token for a D&D character, but I'd like help generating a more realistic, illustrated portrait of him. His name is Bud and he's a servant of the goddess of darkness. In this portrait, he's standing in a fiery volcano casting a dark spell. He's about 35 years old but his skin in a pallid white and his face is gaunt and bony, like a skull. His eyes are dark in their sockets and emit a faint aura of night.

The generated image didn't make his eyes as dark as I'd wanted. In the lore, Bud has "Eyes of the Void", and we're not sure if that means he has obsidian eyeballs or black-hole voids. I got ChatGPT to tweak just the eyes by selectively regenerating just that part of the image. Because so much of the image stayed the same, it was very consistent, keeping the details and motifs from the Hero Forge design.

Experimenting With Changing Poses

One of my hopes was that by starting with 3D models that I could modify and re-pose, I could get more consistent portrayals of the same characters in different situations.

I started by editing Callum's model in Hero Forge to depict him at a bar, mourning the loss of his friends. This would be shortly before Bud and Gliran picked him back up.

So I tried to get ChatGPT to generate a new image based on this, keeping in mind the awesome paladin illustration it did earlier:

Can you make me another illustration with the same style based on another source image? This image shows Callum a few months earlier, grieving at a bar after losing his friends in a fight with a fire elemental. He's looking at his injured left hand. Please take care to match the image you just generated as closely as possible in terms of Callum's facial features.

Here are a few of the results it created after several tweaking prompts attempting to get the visual style to match the paladin pic:

These results weren't as impressive as the original ones. The last image in the gallery wasn't bad, but even then it was clearly a different style. It sorta had that fan art look where many different artists draw the same character in different styles, but I wanted to do better.

So I did the only reasonable thing in this age of AI, and I asked ChatGPT to compare the really cool paladin image with the others, and asked it for help describing the difference between the styles. After a lot of back and forth (it was really obsessed with the backgrounds being different), we landed on some descriptors: "photorealistic", "painterly", and "natural lighting".

After some reprompting using those keywords, this is what I got:

That's a lot better. Not quite perfect, but close enough in style and depiction to be useful.

Iterating On the Prompt

I decided to try this regeneration approach on one more character and decided it'd be cool to see what it did with the genasi bard.

From talking to friends and experimenting a bit, these are the elements of the prompt that I wanted to include:

• Add stylistic notes: "photorealistic", "painterly style", "natural lighting"
• Include a name and age, to get it to focus on making a more realistic person.
• Some personality or biographical details, to let it fill in the blanks with tonally appropriate things.

So my friends and I had to come up with some details for this bard on the fly since our characters did in fact survive the encounter with the fire elemental and the genasi bard had not yet seen service.

We named him Kalani, using a d100 table I found on Reddit.

The prompt:

I have a render of a D&D mini and I'd like you to help me generate a portrait based on it. The portrait should be done in a painterly style with photorealistic details and natural lighting. This character's name is Kalani and he is an air genasi bard, riding a griffin or a hippogriff. He's in his early 20's, and either as a consequence of his air genasi heritage or his youthful inexperience, he's pretty prone to seemingly random outbursts. He sometimes hears voices and music in the wind as it passes by. This leads him to sometimes vacillate between saying insightful or helpful things, and then doing more questionable things like egging on bar patrons, dishing hot takes, or making jokes that cut too close to truth. However, given his high charisma and good looks, he often gets a pass.

The results:

Dang. Kalani's looking good on his first try. I legitimately want to see this character happen now.

Conclusion

Yeah, that was fun. I'm convinced that generative AI is a really great tool for inspiration and ideation, especially for folks like me that lack visual art skills. I think that if I had bigger plans for these characters, I'd still want to commission an artist that could work with me to develop them further, both visually and as a character. That said, these characters feel so much more real when I can see them illustrated this way, knowing that they're custom and unique.

I think I'll try this technique again whenever I get a chance to make a new character (hopefully because I join a second campaign and not because Gliran kicks the bucket).

When my friends Mabel & Ming from Moonwake Coffee Roasters (@moonwakecoffeeroasters) told me they were looking to open a cafe, I started wondering whether we could use data to evaluate potential locations in the Bay Area that might be underserved by specialty cafes relative to their demand. Unfortunately, my experiment didn't work out, and I was unable to get good quality data that could support cafe owners in selecting a location. The good news is that Moonwake will open their first cafe in San Jose soon (later this year, fingers crossed!). Despite the lack of results, it was a fun exercise in simple data science and market research.

New coffee roaster to open shop in San Jose

Moonwake Coffee Roasters began in a place many well-known businesses around the Bay Area have started: a garage.

The Mercury NewsKate Bradshaw

This was my starting hypothesis:

We can use free or cheaply acquirable data to identify whether a location in the Bay Area is over- or under-served by specialty coffee cafes.

There are many new cafes opening in the Bay Area, and I think there's room for many more as we all collectively grow the market of people who appreciate specialty coffee. My hope was that we could show that with data, and help potential cafe owners identify areas where their cafes would make a big impact.

Let's jump straight to the results:

It Didn't Work Because I Couldn't Find Good Enough Data

I don't think that free or cheaply available data is capable of providing significant signal for potential cafe owners in the Bay Area, at least not in a way that's better than general-purpose market data for retail businesses. I found some market research firms that had reports about coffee, but they weren't cheap and they weren't specific.

I found national level trend data, but it's hard to apply nation-wide demographic breakdowns to a particular region. It might have been possible to look for census tracts in the Bay Area that roughly matched the demographics in the national studies, but it didn't seem like it would be high signal. I evaluated commissioning a survey, but the costs were too high for my little (unfunded) experiment:

Here's what I would've wanted to learn (though probably not in 5 questions):

• How many people brew their own coffee at home? How many brew specialty coffee from whole bean?
• How many people order pour-overs at cafes? How often?
• Which Bay Area specialty coffee brands are people aware of?
• How far are they willing to drive for better coffee?
• How much do they know (or care) about various characteristics of coffee such as where it's produced, the processing method, its flavor profile, its cupping score, roast freshness, certifications, etc.?

I was only able to source general population demographic data from the US Census (via the American Community Survey), as well as some broader market research about coffee that was freely accessible:

NCA Coffee Market Research

Get the information your business needs to succeed - from consumer insights to emerging coffee market trends.

Business Insights from the Square Coffee Data Report and the Retail Sentiment Index (RSI) — Specialty Coffee Association

The independent coffee shop is an integral part of so many neighborhoods. It’s a space where communities come together.

Specialty Coffee AssociationSCA Staff

Square and the Specialty Coffee Association Release Coffee Data Report in honor of National Coffee Day

Square

Scaling beyond specialty coffee: Is the market smaller than the industry thinks? - Coffee Intelligence

Despite the fact that the definition is more complex, “specialty coffee” as a concept is still largely used to refer to small, single-store owner-operated businesses rather than larger organisations.

Coffee IntelligenceGabriella Oakley

However, the biggest revelation for me had nothing to do with the data: finding commercial real estate for your first cafe is highly idiosyncratic. There are a million other things to consider before the size of the specialty coffee market. Despite the commercial real-estate market's current woes, it's still hard to find a suitable location for the right price. Cafes are food service facilities and need spaces that can be renovated for their plumbing and electrical needs without breaking the bank. For a small business, proximity to the owners and their community is also a critical consideration. It's unlikely that a prospective cafe owner would open their first shop on the other side of the Bay just for the specialty market. That said, this data might be more useful for picking a second location: expanding to another location requires scaling the business in ways that make some of these proximity requirements moot, and the business has more time to consider where to expand to since they have one location that can continue generating revenue in the meantime.

Okay, but what about these maps?

I built a prototype map with some heuristics for supply and demand based on the data I got from the ACS and some manual data generation:

• I used population density and the density of high-income households (>$200k annually) as proxies for demand.
• I used isochrones representing a 10-minute driving distance radius as a proxy for cafe availability.

The first thing I did was cosplay as a Data Scientist and plop my data in a Python notebook via Google Colab. I came up with a list of fifty Bay Area cafes that I thought might count as specialty, manually geocoded them (got latitude/longitudes for them based on their address), used Open Route Service to generate the isochrones, and then used plotly to make the maps with Open Street Map styled tiles.

Here's what the resulting map looked like:

A couple things jumped out immediately:

On one hand, my data was really spotty. The list of cafes was incomplete, and everyone I showed the map to would ask "Why isn't XYZ cafe on this list?". The definition of a "specialty" cafe is also vague and varies from person to person. I thought that fifty cafes would be a large enough sample, but in places where there are few cafes, the inclusion or exclusion of a single cafe can make an area look reasonably covered or extremely empty. For example, in Fremont, I didn't include Tamper Room (@tamperroom) because they were pretty new at the time, but they're one of my favorite cafes in the Bay. If I had included them, Fremont would look a lot more covered (and if I were remaking the list today, I'd definitely include them). Ditto for Kaizen and Coffee in San Mateo (@kaizenandcoffee)

Tamper Room (@tamperroom) • Instagram photos and videos

4,398 Followers, 455 Following, 82 Posts - See Instagram photos and videos from Tamper Room (@tamperroom)

Instagram

Kaizen & Coffee (@kaizenandcoffee) • Instagram photos and videos

2,283 Followers, 67 Following, 52 Posts - See Instagram photos and videos from Kaizen & Coffee (@kaizenandcoffee)

Instagram

On the other hand, it's clear that there are pockets of the Bay Area that are dense with cafes, and others that that have very few. Even accounting for my incomplete list of cafes, there's a stark difference between Dublin (all the way to the right, middle) and Palo Alto.

Knowing where existing cafes are is only half the equation though: my goal was to find places where demand for specialty would exceed supply, which meant that I needed a proxy for demand. As I mentioned before, I didn't have access to granular coffee demand data by locale, so I used population and income data from the American Communities Survey as a very blunt heuristic. The ACS is conducted by the Census Bureau each year. It is less precise, but more responsive than the Census, which is run every 10 years. ACS data is also presented in five year rollups, which gives more granular data than the annual ACS, but less than the decennial Census. I used the five year rollups of ACS data from 2016-2021 for my visualizations.

To plot the data, I used Leaflet.js, a Javascript library for rendering maps and plotting data on top of them. But to get the data ready to plot, I first had to transform the massive Census data CSVs into GeoJSON layers that Leaflet could render.

I used a data tool called DuckDB to do the data munging necessary to get the census data into the right format. I've included some details on that process at the end of the article.

The result was a giant JSON file that had many entries like this for each census tract and zip code:

{
  "type": "Feature",
  "properties": {
    "geo_id": "1400000US06085504321",
    "census_tract_name": "Census Tract 5043.21, Santa Clara County, California",
    "land_area": 1450237,
    "population": 5511,
    "per_sq_km": 3800.068540521308,
    "median_household_income": 146941,
    "high_income_households": 448,
    "households": 1675,
    "high_income_per_sq_km": 308.91502561305498,
    "perc_high_income": 0.26746268656716415,
    "median_household_income:1": 146941
  },
  "geometry": {
    "type": "Polygon",
    "coordinates": [
      [
        [
          -121.875559,
          37.39924
        ],
        [
          -121.875352,
          37.399076
        ],
        "..."
      ]
    ]
  }
}

Let's Make Some Maps

Finally, with all the pieces together, I got a map:

I could toggle layers on and off to include or exclude the "base map" (that's the Open Street Map) and overlays for population density and high-income household density by census tract or zip code. Removing the base map reduces the visual noise, so I toggled it off for most of these graphics.

The map below shows population density in blue, and cafe isochrone coverage in red. The darker the blue, the higher the population density, and the darker the red, the higher the number of specialty cafes nearby (from my list of 50).

At this point, all I could say is that, from eyeballing the map, the density of coffee shops seemed to be correlated with population density. There are some spots of higher density in the East Bay from Oakland to Hayward that aren't as well covered by cafes, but for the most part, the cafes are in the Bay's major population centers: San Francisco, San Jose, Oakland, and the mid-Peninsula.

But population density isn't the only metric we can get from the ACS data. I wanted to look at income as well to see if there was any correlation between areas with higher incomes and places with more cafe coverage. The Census Bureau estimates that the median household income across the US was $74,580 in 2022 (source). However, most Bay Area counties have a median household income well over $100,000. If you look at the distributions, the income inequality is pretty stark. The map below shows population density in blue and high-income household density in green. For the purposes of this analysis, I considered households making over $200,000/year to be high income. This is the highest income bucket for which the ACS provides data.

You can see some spots of blue or green that don't overlap much. San Francisco seemed to have a high density of people as well as high-income households while areas up in the hills tended to have a disproportionately high density of high-income households.

Here's the same data, but flipping back and forth in a GIF. Blue is population density, green is high-income household density.

Interesting, but what does this mean for cafes? Let's compare the cafe isochrones to the high-income household density map.

Eyeballing it, I think this matches up a bit better than against the population graph, but only because large parts of the East Bay are excluded.

I would caution against drawing strong conclusions from this map. Like I said earlier, the map is heavily influenced by the list of 50 cafes I picked, and small changes to that list (like including a couple more cafes in the East Bay or Tri-Valley) would make these maps look a lot different.

Wanna Try Playing With The Map?

I don't keep it updated, so consider it an archived version of the map. The list of 50 cafes that I included are not an endorsement. If you want to play around with it, you can find it here (https://coffee-map.ifwego.co/):

A couple pointers:

• The "census", "zipcodes", and "places" layers show population density.
• The "censusHighIncome" and "zipcodesHighIncome" layers show high-income household density.
• The "zipcodesIncode" layer shows median income by zip code. It's the same color as "zipcodesHighIncome" so be sure you have the right one.
• You can click on a census tract/zipcode/place to see stats about it.
• You can enable the "cafePins" layer and click on a pin to see the name of the cafe and its 10 minute isochrone.

Conclusion

Maps like these might be useful for seeing where existing cafes are, but they don't present a clear picture of supply and demand. It might be possible to infer some data about how many coffee drinkers there are in an area based on the density of chain coffee shops like Starbucks and Peet's that likely have commissioned much more expensive and thorough market research. It's also probable that a roastery-cafe will start to accumulate their own data on where their customers live around the Bay and could use that data to inform where to put a second cafe.

Ultimately, a prospective cafe owner has a lot to consider besides the local demand for specialty coffee. People are willing to drive longer than 10 minutes to have good coffee. If some of those other considerations lead to cafes being closer to their communities than to coffee aficionados, I don't think that's a bad thing.

Technical PS: Using DuckDB

I have a friend who works at Mother Duck who won't stop talking about DuckDB, but I figured since I never shut up about coffee, I could make both of us happy and use DuckDB for my coffee project.

I had two data files I needed munged together:

1. The ACS data CSV tables containing population and income data by census tract and zip code.
2. Shape files describing the outline of each zip code and census tract.

I wanted to get the geometry, population density, and high-income-household density for each census tract and zip code, and output that data to a GeoJSON file that Leaflet could render.

Here's a taste of the DuckDB SQL I used to do it:

Notice how I'm querying data directly from the CSV files using read_csv_auto(...) and writing it out to GeoJSON using WITH (FORMAT GDAL, DRIVER 'GeoJSON'). I thought it was really cool that DuckDB lets you read and write from files as if they're DB tables.

In the example above, the census_tracts table already existed. It was created by importing geometry data defining each census tract from a "shape file" I got from the Census Bureau. I imported the data into a table so that I didn't have to read it in from the file every time I ran a query. I did the same for zip codes.

Here's an example query that creates the zip_codes table from its corresponding shape file:

/* Import Shapes: Zip Codes */
CREATE TABLE zip_codes AS SELECT 
    ZCTA5CE20,
    GEOID20,
    CLASSFP20,
    MTFCC20,
    FUNCSTAT20,
    ALAND20,
    AWATER20,
    CAST(INTPTLAT20 AS DOUBLE) AS INTPTLAT20,
    CAST(INTPTLON20 AS DOUBLE) AS INTPTLON20,
    ST_GeomFromWKB(wkb_geometry) AS geom
FROM ST_READ('/Users/dpok/code/coffee-map/data/tl_2021_us_zcta520/tl_2021_us_zcta520.shx');

Notice how this query parses the geographic data using ST_GeomFromWKB. The functions for reading and writing geospatial datatypes come from the DuckDB Spatial Extension.

I had a good time with DuckDB. Some things I enjoyed about using it:

• It's cool to be able to write a query that joins a DB table with a CSV file.
• There seems to be a lot of support for different file formats like the geospatial shape files and GeoJSON files.
• Considering how much CSV it was consuming and how much JSON it was writing out, it ran pretty quickly. I think it took a few seconds to rebuild the massive JSON blob that I used to power the map.

In Part 1, I mentioned that I made a tool that makes designing patterns easier. It's very much in alpha, but if you want to check it out, you don't need to listen to me blab, you can just click the button below (https://patterns.ifwego.co).

I'll do a quick walkthrough of the tool and then a technical deep dive at the end.

Previewing Patterns

The tool at the top of the page is for previewing patterns. Given a pattern cell, you can preview the cell swapped or tiled in 2x2, 4x4, and 16x16 arrangements. You can get a pattern cell in one of four ways:

1. The Drawable Canvas (✍️ Draw tab): An in-browser drawing canvas that supports mouse, pen, and touch.
2. The Layer Editor (🖼️ [⍺] Layer Editor tab): An editor for arranging imported images to create a pattern.
3. An Image File (📁 Import File tab): Select an image file from your device.
4. The Gallery (🗺️ Gallery tab): Select from a set of example patterns that illustrate different ways to create patterns.

Let's start with...

The Gallery (Link↗)

Here you can find some patterns created in the tool as well as other example and utility patterns.

All of the following were made using the drawable canvas:

Drawable Canvas

I made a small drawing tool, originally just as a break from doing math on the other editor (the layer editor), but it ended up being a lot of fun to play with, so I kept fleshing it out until it turned into the state it is today. Here's a video of me using several of the editing tools to create a tubular pattern.

While the editor is basic in many ways (it has the performance of an online drawing game and evokes MS Paint), it does support a few cool features:

• The main feature: moving around the canvas like it's an infinite pattern, or swapping the quadrants with a single button press.
• Blurred brushes and opacity, allowing for blending in darker/lighter shades.
• Undo/redo
• Restricting drawing to pen-only (useful for drawing on tablets)

It's not the prettiest interface right now (lots of glued-on features), but it's enough to play with. If you're unsure what any of the buttons do, I documented them all in the "Instructions" tab (https://patterns.ifwego.co/#instructions).

If you wanna play with it, here are my recommendations:

• You're not limited to just using the "Swap" button to navigate around the infinite canvas. There are buttons with arrows on them that can pan you around as well. This makes it easier to fill any gaps in your design, not just those around the edges.
• To draw a continuous line that wraps around the edges of the pattern, draw close to the edge, but not all the way, then hit "Swap" and draw in the connection between the two ends. With a bit of blending, you can make it look continuous. Alternatively, if you can draw the line or shape in smaller segments, you can draw a bit, pan the canvas with the arrow buttons, and then keep drawing.
• The editor doesn't support layers yet, so if you plan to apply shading to an object that will be underneath another one, you may want to add some shading before you start drawing the next element.
• If you want some inspiration, try doodling some simple shapes in different colors. Basic things like stars, diamonds, stick figures and the like can take on a certain charm when tiled.

Layer Editor

This editor is in an earlier stage than the drawable canvas, but I anticipate that this will be the main way I use the tool in the long run. The idea is that you probably want to draw the elements of your pattern in whatever drawing software you're most familiar with (for me, that's Procreate on iPad) and then arrange them in this tool to create your final pattern. Like the drawable canvas, the main feature of this tool is previewing how your pattern will look when tiled. If you move an element to the edge of the canvas, it'll show it wrapping around.

You can also hit the "Swap Quadrants" button to move the elements around. This works at the object level, not the pixel level, so you can continue moving, scaling, and rotating each element after you hit "Swap". That feature alone was my greatest motivation to build the tool. Every time I edited a pattern in Procreate or Affinity Photo I wished they would let me edit this way.

Here's a pattern I made using elements drawn in Procreate and arranged using the layer editor tool, all on my iPad:

I haven't written up instructions for how to use this tool like I did for the drawable canvas, but here are some key pointers:

• The canvas starts with a red square. Feel free to play with it to get a feel for the manipulation handles.
• You can delete an element by pressing the Delete key on your keyboard, or by selecting an item and then pressing the "Delete" button in the UI.
• You can scale an item symmetrically by holding Alt/Option while dragging a resize handle.
• You can add colored frames by checking the "Include Background" checkbox and clicking "Add Frame". You can also include a background color when you add an image.

That's all I've got for usage notes. Feel free to play with it if you'd like!

If you don't wanna hear about my technical kvetching, then I'll say goodbye to you here, and leave another link to the tool (https://patterns.ifwego.co):

On with the kvetching!

My Mortal Enemy: Shapes and Colors

I've never loved geometry. I still remember taking on a photo-rotating task as an intern and handing it back after a day of stumped whiteboarding trying to figure out why my trig was a little off. (...the debugger was also broken and the app took so long to build that you could take a walk while it was building, soooo.....)

Making the resize and rotate handles on the layer editor took a day or two of experimenting to get right.

The first and easiest operation was translation (that is, moving the box around the canvas). This is done with a CSS transform: translate(...) property and some pointer event handlers. Next up was scaling. Scaling is a bit more nuanced because the behavior users expect from a resize handle is a little more complicated than doing a scale(X, Y, Z) transform.

• If the user drags on the right-side handle, it should increase the width of the box while keeping the height constant and the left edge of the box constant.
• If the user drags on the left-side handle though, the origin of the box needs to move to the left to compensate for the increasing width because the user expects the box to be anchored on the right edge.
• If the user drags on one of the corner handles, they expect the box to scale proportionally.
• In all cases, the box should scale such that the anchor the user is dragging stays under their pointer if possible – the pointer could move in the wrong axis or a proportional scaling constraint could prevent the box from reaching the user's pointer.
• If the user holds down Alt/Option, then the box should scale symmetrically (e.g. twice as much, but also translate negative the amount).
• If the user holds down Shift when dragging a side handle (instead of the corner ones), the box should scale proportionally.

This isn't too hard to do, but it does require managing a few vectors:

• The pointer offset from its starting location.
• The "drag axis" of the handle (e.g. the vector representing the positive direction)
• The "scale axis" of the handle (e.g. the amount to scale the box based on how far the user dragged in the drag axis).

Math time:

So the right, bottom, and bottom-right anchors only have positive drag vectors and don't require a compensating translation (CSS coordinates, like in most graphics systems, have the origin in the top left of the screen or bounding box, and increase in the y direction from top to bottom). All the other anchors require subtracting a delta in width or height when scaling. This works in reverse too: if you're shrinking the box using the left anchor (e.g. by dragging to the right), you'll need to subtract the negative delta width which turns into a positive X translation to ensure that the right edge remains fixed.

Ok, scaling boxes makes sense. Time to enable rotation. CSS transforms can do it using: transform: rotate(...), so it should be easy, right? All you gotta do is find the pivot you're rotating around (by default in CSS, it's the center of the object) and use the inverse trig functions to find the delta in angle when you drag the rotate handle around.

I tried it, and after a bit of work to use the right inverse trig functions, rotation was working. Nice! Then I tried scaling after rotating and the boxes would translate around when scaling if they were rotated. Wups. What's up with that?

Before adding rotations, we kept the opposite edge (or point) from the scale anchor fixed in space by compensating for changes in width or height by translating the X and Y. Now with rotation, that's insufficient. When the box is scaled, its center of rotation changes even if its (x, y) position (its top-left corner, before rotating) remains the same. However, to keep the opposing edge fixed, we need to keep the box's apparent origin fixed, accounting for where its center was at the start of the scaling operation.

I spent a while trying to derive how to calculate the delta X and Y directly from the delta width and height (given a fixed rotation), but found that you need the original X and Y to find the top-left point of its bounding box.

To address this I did two things:

1. Store each object's position as a vector with two halves: a set of "committed" values for X, Y, width, height, and rotation, and a set of "delta" values for each of those. When the user finished scaling or rotating the object, the deltas would get combined into the committed values. This way, I could ensure that transforms would be correct relative to the original position.
2. I calculated the dX and dY by applying the simple algorithm for unrotated boxes to get a rotation in "box space", rotating it about its new center, finding the new bounding box, and then finding the delta needed to get the top-left of the bounding box back to the top-left of the object's bounding box before we started scaling.

Other Learnings

Enough with the shapes. Here are a handful of other things I encountered while building out this prototype:

• Use element.setPointerCapture(event.pointerId) in the pointerDown handler to ensure that all subsequent pointer events get sent to a certain element (even if the pointer leaves the element's bounds). This allows you to continue drawing even if the pointer leaves the canvas, or to keep dragging resize handles even if the pointer doesn't stay 1:1 on top of the handle element. When the pointer is captured, it can still fire onPointerLeave events if it's no longer over the element.
• To prevent extra button latency on mobile, set the CSS property touch-action to manipulation (or an even more restrictive value). This prevents the double-tap to zoom behavior in mobile browsers, which means they can fire touch events without waiting to see if it's a double tap. Avoid hover states on mobile as well: elements with hover states can eat touch actions going into their hover state. There's a media query for this: @media (hover: hover).
• You can detect light mode/dark mode with the media query @media (prefers-color-scheme: light)
• When users do long touches on the screen (such as when drawing on the canvas or doing a drag), mobile browsers may interpret that as a select and try to select the nearest text. To prevent this, use the CSS property "user-select: none" and the prefixed "-webkit-user-select: none" (WebkitUserSelect in JS). Be careful though, this prevents users from selecting whatever text this property is applied to, which could make it hard for them to copy/paste or look up some text that they ought to be able to. I'm still tweaking my approach to this, but for now, I apply this property as high up in the DOM as possible when the user is drawing, and then remove it when they stop. I also marked the control buttons as non-selectable at all times. This sorta works, but it still selects text way down the page sometimes when I'm drawing on my iPad.
• To implement editor history for the drawable canvas, I store an array containing the previous contents of the canvas. Originally, I tried using canvasCtx.getImageData() and storing the resulting array because it's the most native way to get and put image data to the canvas. However, this array is not compressed, and my canvas data is readily compressible since the brushes that users use are pretty wide and create large patches of the same color (which the PNG format should be able to exploit). I switched from canvasCtx.getImageData() to canvasElem.toDataUrl() which returns the contents of the canvas as a base64 encoded PNG. This saved a lot of space and allowed me to increase the number of saved history states to 100.
• Safari doesn't support blurs in canvas. Most other browsers do, but also all browsers on iOS are Safari/Webkit under the hood (at least for now), so iOS users are out of luck for blurs. I implemented a simulated blur using multiple strokes roughly scaled to match a Gaussian function, but I haven't tuned it correctly yet.
• I have an issue when drawing on my iPad where there's a minimum delay between strokes. It will straight up drop every other stroke if I go too fast. I'm unsure if this is a browser issue that limits the maximum speed I can detect touches (I doubt it because it feels like I can tap buttons faster), or if my rendering code is too slow on each pointerUp event and blocking the UI thread (I did some profiling and tried disabling costly operations like pushing entries to the back stack, but it didn't seem to make a difference).
• The checkerboard pattern backgrounds for the various canvases and editors are pure CSS. They're a repeating CSS conical gradient with some transparency. I figured this would be most efficient way to do it since the browser can quickly generate the texture using whatever native GPU magic it has and then repeat it to match the screen size. The magic incantation is this:

.checker {
  background-image: conic-gradient(
    #ddd3 0 0.25turn,
    #3333 0.25turn 0.5turn,
    #ddd3 0.5turn 0.75turn,
    #3333 0.75turn 1turn
  );
  background-size: 50px 50px;
}

Next Steps

To be honest, I'm not sure what I'll do next with this project. It's working well enough for doodling patterns with the drawable canvas, and the ability to pan around the infinite canvas while doodling has changed the way I approach pattern making. Namely, it's letting me play with directly illustrated patterns like "Beasts" and the variations on wires/tubes/pipes instead of just using multi-element patterns built from separately-drawn pieces. The layer editor is still rough and it could use some of the polish I added to the drawable canvas like undo/redo and the ability to pan around the infinite canvas instead of just doing a quadrant swap.

I've debated combing the two editors into a web-based drawing/layout tool or maybe reusing the drawable canvas for some browser games. It could also be a fun opportunity to learn WebGL or use WASM to further optimize some drawing and compositing operations. I've also seen some cool patterns that never repeat, and I think it could be fun to try to make a pattern generator that's compatible with them (e.g. the Penrose Tiling), but I need a break from geometry for a while.

If you end up making something with the tool or have feedback on it, let me know!

Late last year, I designed some packaging for a collection of coffee samples I gave out to some friends. I'm not much of an artist. The best I can manage are simple illustrations of geometric things, so I used a trick I learned in the one graphic design class I took in college to stretch my limited drawing abilities into a useful art asset: turning the simple illustrations into a repeating pattern.

It's an approximation of a fully illustrated background image. Take, for example, the light-mode WhatsApp background: it doesn't repeat, even though it goes off the edge. I love the way it looks. The hand-drawn, line-art style reminds me of middle-school notebooks where every available space has been filled in with doodles. They take a lot of creativity and time to create – more than I have.

Have a look for yourself:

So the value of the pattern making trick is to stretch a pattern cell into a larger asset, without making the tiling obvious. This lets us emulate a full-fat illustration while drawing fewer elements. Here's the pattern on my coffee bag:

It's not hard to spot where the pattern repeats, but I think it passes the sniff test at first glance (especially if it's incorporated into a bigger design, like on the bags). The key is to break up the outline of the pattern cell. Humans are very perceptive to outlines, even if they're implied by white space (see also: all of modern web design that uses white space instead of actual lines). The pattern cell is a square, but if the art fit neatly inside that square, then the whitespace around the edges would strongly imply a tiled grid, which would make the boundaries of the pattern cell really obvious.

Here's the pattern cell for the pattern above:

See the trick? The elements go off the edge and "wrap around", which breaks up the outline. It might not look like it, but it uses the same technique as camouflage: by breaking up the outline of the square pattern cell, we make it harder to pick it out.

Here's the pattern again, repeated in a 2x2 grid with each set of elements highlighted:

Let's try making a new pattern out of these elements. There are around 20 elements in the pattern. Here's eleven of them arranged in a pattern cell:

And now let's try that in a 2x2 pattern:

See that giant cross of white space going through the center? Even though the elements go close to the edge of the pattern cell, they never cross it, and that's enough for your brain to see the lines of white space.

Ok, "one neat trick" time: the way to easily add elements that "wrap around" is to swap the quadrants of the image such that the center is now on the sides, and then add more elements to the center. In practical terms, that means swapping the top-left quadrant with the bottom-right, and the top-right with the bottom-left. Is that hard to visualize? Let's look at some examples.

Here's the pattern cell from above, but after doing the swap I described. The cross of blank space in the center is from the blank space that used to be around the edges.

To see exactly what the swap does, I made this pattern cell with labeled quadrants. Note how after the swap, the "circle" in the center is now spread out around all four corners, and the angles in the corners are now in the center. In effect, doing this "swap" is just panning your infinite pattern from the "middle" of a pattern cell to the corner where four cells meet.

Ok, so let's try out the trick. We'll start out with the "swapped" pattern cell and then add some more elements to fill the blank space:

Let's see how that looks in a 2x2 grid:

It's definitely better. The blank cross is gone, but there are still some awkward blank spaces near the portafilter (that's the 🔎 looking thing that goes in the espresso machine). It would help even more if we adjusted the positions and rotations of the existing elements to hide the seams a bit better, but that can be hard to do if you did the swap on the pixels of the image and no longer have individual element objects to manipulate.

Good thing I didn't do this in a normal image editing tool (foreshadowing much?).

Let's tweak it a bit:

And in a 2x2 grid:

It's not perfect, but it's better. Let's take a quick look back:

1. We arranged the elements in a cell, trying to get close to the edges, but it the seams of blank space still stuck out after tiling it.
2. We "swapped" the quadrants of the pattern cell and added some more elements in the blank space to break up the outline of the pattern cell. This produced a pattern with much more subtle seams, but there was still some awkward blank space.
3. We adjusted the elements a bit to hide the blank spaces and smooth out the visual pacing.

That's the gist of it. I'm sure real artists could share some deeper knowledge about how to make visually pleasing patterns, but here are some more thoughts I had about them:

• These multi-element patterns need to start with good, consistent elements. I drew the individual elements using Procreate on my iPad using the Apple Pencil. Procreate makes it easy to achieve that hand-drawn style, but maintaining consistency between elements is up to you. Notice how some of my elements are empty and figurative while others have more detail and implied shading. Ideally, they would all be similar instead.
• Keep most elements similarly sized so that things don't stand out. When one element is a lot larger than the others, it creates a visual anchor that makes the repeating more obvious. It's nice to have a mix of sizes, but be careful when making a small handful of items a lot bigger than the others. Notice how the WhatsApp pattern uses small dots and stars as decorations, but most of the important elements are about the same size. That illustration can get away with having a few large "hero" elements because it doesn't actually repeat. The hero elements stand out, but they're unique. Similarly, watch out for elements that are darker or more colorful than others standing out too much.
• Avoid prominent parallel lines. In addition to whitespace, humans are good at spotting parallel lines. Any prominent straight line in a pattern becomes a parallel one and creates implicit outlines. Try to rotate things slightly in different directions to avoid having all straight lines in the pattern be parallel. On the other hand, leaning into the parallel lines can create some cool effects. You don't have to hide the pattern if you don't want to.

I'll leave you with a few of the patterns I've made and how I've used them:

Doing the quadrant swap manually in Procreate and other image editing tools is a pain and makes it hard to adjust things afterwards. I've wanted to make myself a better tool for this, and I finally got around to it.

In Part 2, I'll talk about that tool, how to use it, and maybe a bit about how I built it.

One of my best technical mentors, Cameron Behar (CTO of Sprinter Health), gave me this advice for working more efficiently when your project gets blocked or iteration times are slow: Have a secondary workstream that you can switch to when your primary one is blocked.

Getting blocked on work causes all sorts of issues for engineers: it's frustrating, it forces context switches, and it kills momentum. Personally, it's extremely frustrating and emotionally draining to have a high-pri task stuck in a way where I can't make progress. It feels like busy-waiting, a particularly expensive way a computer can wait for another task to finish by running in a loop constantly checking if it's done. Having a second workstream that you can jump to helps alleviate the problem by removing the question of "What should I be doing right now?" Instead of having to spend time and energy picking the next most important thing, you can pick it beforehand. I call this my "B-track". My main workstream is my "A-track" and my secondary is my "B-track". Instead of prioritizing everything I could be doing against everything else I could be doing, I only have to decide when the marginal utility of working on my A-track has dropped below the marginal utility of working on my B-track.

Here are some examples of when I might switch from my A-track to my B-track:

• Waiting for code to be reviewed. This might cause a few hours to a few days of downtime depending on how complex the changes were. A lot of that time is spent waiting in asynchronous back and forth conversations about feedback on diffs, where it's more efficient to leave your changes as they are and work on something else while you wait for your reviewers to have time to take a look. As a side-effect, it keeps the pipeline primed: if your B-track work advances enough to produce another diff, you can get that next review cooking asynchronously while you follow up on your A-track diffs.
• Waiting for a deliverable from another teammate. This could be waiting to review something with a designer, or waiting for a decision on some feature from a PM (product manager), or some other part of the process that isn't in my control. Structurally, this is similar to the code review situation, and it has the same pipeline efficiency benefits.
• Waiting for code to compile or infrastructure to spin up. Whenever something is rebuilding or compiling (looking at you, mobile apps and code generators), you could switch to your B-track. This one requires faster swapping between projects. Doing this requires that you have the ability to separate out your workspaces such that you can quickly swap between different workstreams: e.g. have two different version control branches checked out in different editors, or projects in different parts of the codebase (like frontend and backend). This works better when your B-track is simple and interruptible so you can switch back to your A-track quickly. Easy refactors fit the bill, as do certain process-management/accounting tasks. Things that have a lot of state or context wouldn't work here.

Compiling

xkcdAbout

B-track work has to be something you can easily make progress on. It has to be easy to swap back and forth to without needing a long wind-up or a costly context change. Generally, it shouldn't be anything that requires deep thought since those tasks are hard to get done in short chunks. Things that are already planned and just need execution are good candidates, as is work that is more mechanical than strategic. This kind of work can be a break that lets you relax without completely dropping out of your flow state. It keeps the momentum up and helps you feel more confident about your productivity. It can be especially helpful for more senior folks who have days where they're in and out of meetings in 30 minute chunks and don't have a long block get into a flow state. It can help you feel better about what you got done in a day because the tangible progress on the B-track work gives you something to point to while your long-term work slogs on. On the other hand, if the B-track work is too complicated and requires a huge context switch, it'll knock your A-track work out of your working memory and delay it. Pick a complexity commensurate with how often you'll be switching: if your A-track is blocked for days at a time, maybe you can afford to drop context on it in favor of your B-track when you swap. On the other hand, if you're switching for five minutes at a time, you'll need something extremely rote to do.

Good B-track work needs to be less important than your A-track work. Telling your team that a workstream is on your B-track signals that they shouldn't count on that workstream getting done by a particular time. It's explicitly there to soak up the excess resources you have while working on your A-track work, but the A-track work will always be the most important. If both things are equally important, you might still get some benefit from jumping back and forth between them when they get blocked, but you don't get the mental benefits of easy prioritization. Having your B-track be on the critical path means that it creates pressure for you instead of being a pressure release valve. On the other hand, it's a great way to get people on board with you working on something that's less urgent but more interesting. Hearing that it's strictly secondary to your primary work means that team leaders are less worried that your "side-project" will take resources away from your critical work. Instead, anything you get done on your B-track project is just extra productivity that would've otherwise been lost, and you've framed it as a win-win.

Ideally, B-track work is something that gives you energy and can recharge you. Cameron said that he likes to save "easy wins" for B-track work so that when you're discouraged by your A-track work being blocked, you can pick up small wins from your B-track work. Finding B-track work that excites you but still fits the criteria above can be challenging. I think that if we can't get to "exciting", we can settle for "satisfying". Here's a brainstorm of things that might qualify:

• Reviewing other people's code, especially when you're not a critical-path reviewer. Reading other people's diffs/pull requests can help you stay up to date on other projects, and providing effective feedback quickly can help newer folks ramp up faster.
• Fixing a small bug that bothers you, but isn't high-pri enough to be A-track.
• Improving the quality of the codebase by adding tests, improving alerting, refactoring things that have become unwieldy, fixing broken tests, or addressing build or runtime warnings that everyone has secretly learned to ignore. Alternatively, you could do non-coding things that improve technical quality like improving documentation or providing support to other teams that depend on your team’s work by answering questions in a support group.
• Trying something out. Sometimes you just wanna poke at an idea you have to see if it'll work such as a potential refactor or a new way to use an existing capability, and making it a B-track thing relieves the pressure of having to justify the risk of experimenting in case it doesn't work out.
• Getting ramped up on your next project. This could be dev environment setup work, reading documentation, sending reachouts to partners you’re gonna work with, or reading code to get familiar with the codebase.
• Catching up on “chores”. These aren’t necessarily exciting or intrinsically satisfying, but they’re things you need to get done that can get stressful if they’re allowed to build up. Things like filing expense reports, writing project update posts, and triaging tasks in the team backlog could qualify here.

I don't think there's anything too novel about the idea of having something to work on when your main work is blocked, but there's something simplifying about calling out what work is A-track vs B-track that works well for me. Internally, it helps me be efficient about prioritization. Instead of having to consult a backlog every time I have a free moment, I can instead just get something done. Externally, it's a much more succinct way to communicate a fairly nuanced set of expectations.

If you haven't been following gaming news recently, you may have missed that the coop-base-builder-exploration-game du jour is currently Palworld, which has been aptly described as "Pokémon with guns."

My friends and I have been playing too, and I've been self-hosting a server for us using Docker and Docker Compose. The Docker container image I was using is excellent (link below) and supports sending Discord webhooks whenever the server starts up or shuts down, which is surprisingly critical because the game server gets sluggish if you don't reboot it once a day or so.

GitHub - thijsvanloef/palworld-server-docker: A Docker Container to easily run a Palworld dedicated server.

A Docker Container to easily run a Palworld dedicated server. - thijsvanloef/palworld-server-docker

GitHubthijsvanloef

This is what they look like:

I wanted to expand on this to message the Discord whenever players joined or left the server, so folks could see who's online and feel tempted to hop in. I threw something together in Go that uses the linux conntrack module and Palworld's rcon server to generate join/leave events to send to Discord, and this is what they ended up looking like:

What is Conntrack?

The conntrack module tracks network connections to the system and is usually used to specify firewall rules that allow packets to reach the system if they're related to a different connection that is already allowed. For example, your firewall may be configured to not allow any incoming traffic if your computer isn't hosting anything. However, when you browse the web and connect to an HTTP server, you've gotta somehow get packets back from the server. That's where conntrack comes in: the outbound flow that your HTTP request creates is allowed by the firewall, then conntrack makes a note of that connection and records an entry saying "allow incoming packets that correspond to this connection", and finally, when the HTTP server sends a response, the inbound flow will match the expected flow that conntrack recorded and the firewall lets it through.

That's what conntrack is mostly used for, but it does have one other cool trick: it can dispatch an event every time a connection changes (e.g. a new connection is created, or an existing one closes). The events look something like this:

server-manager-1  | Event[NEW](UDP) 1.2.3.4:[55533] - localhost(192.168.240.2):[8211] ([CONFIRMED, UN-REPLIED])
server-manager-1  | Event[UPDATE](UDP) 1.2.3.4:[55533] - localhost(192.168.240.2):[8211] ([REPLIED])
server-manager-1  | Event[UPDATE](UDP) 1.2.3.4:[55533] - localhost(192.168.240.2):[8211] ([ASSURED])
server-manager-1  | Event[DETROY](UDP) 1.2.3.4:[55533] - localhost(192.168.240.2):[8211] ([ASSURED][DYING])

In the example above, we can see a connection from a client (1.2.3.4:55533) to the server (192.168.240.2:8211):

1. First we get a NEW event showing that we got a UDP packet in this flow which made it past the firewall (CONFIRMED) but the server didn't respond yet (UNREPLIED).
2. Next, we get an update event showing that the server replied (REPLIED).
3. Then, we get another update event showing that the client sent a response in reply to the server's message (ASSURED). This is analogous to TCP's handshake where the initiator sends a SYN packet, the receiver responds with a SYNACK, and then the initiator responds with an ACK and can start sending data. UDP doesn't have a handshake because it's not a stateful protocol, but conntrack provides these events anyway since they're broadly useful in determining when to count a connection as "active". Since Palworld presumably has a connection handshake between the client and the server, the ASSURED state is good for us.
4. Finally, we get a destroy event when the client has disconnected (DYING). Since UDP doesn't have an explicit "hangup" message like TCP's RST packet, conntrack marks a UDP connection as dead if it hasn't received a packet for some amount of time (on my system, it's 180 seconds).

Why does that make the networking hard?

conntrack only tracks connections to the local system, e.g. a VM or a container. It can't track connections going to a different container. This is because linux network isolation is done with namespaces (net-ns), and each Docker container, by default, has its own separate network namespace. This means that if two containers both listen on the same port (say, port 80), they can both bind to that port because they're doing it in their own namespaces. To get outside traffic to reach a container's port, it needs to be forwarded, hence why Docker supports forwarding ports from the host to a container (e.g. docker run ... -p 8000:80).

My server manager program in Go needed to be running in the same net-ns as the Palworld server, but they were running in different containers within the Docker Compose stack. I could make a new container image that ran both my server manager and the default command for the Palworld server, but that would require a more complex integration and would couple the two components together. This is roughly what the docker-compose.yaml looked like at this point:

services:
   palworld:
      image: thijsvanloef/palworld-server-docker:latest
      restart: unless-stopped
      ports:
        - 8211:8211/udp
        - 27015:27015/udp
      volumes:
         - ./data:/palworld/

   server-manager:
      image: golang:latest
      restart: unless-stopped
      depends_on:
         - palworld
      command: "/src/server-manager"
      cap_add:
         - NET_ADMIN
      volumes:
         - ./src:/src

Now, unlike in Docker Compose, when you deploy a group of containers together in Kubernetes, you can deploy them as a "pod", which puts them all in the same net-ns. Docker Compose creates a unique net-ns for each container you define and creates a new virtual private network for them, so they can communicate with each other, but they each have their own network stack. If this were a Kubernetes pod, then server-manager would be able to monitor connections to palworld:8211, but not so in Docker Compose.

The I discovered this flag: --network container:<container-name>. It's a container networking option that's a bit buried in the docs, but when you specify network: container:<container-name> in your Docker Compose service definition, Docker will put the container you're creating into the net-ns of the container you specified.

Networking overview

Learn how networking works from the container’s point of view

Docker Documentation

This kinda emulates a Kubernetes pod. Let's see the new docker-compose.yaml after this update:

services:
   palworld:
      image: thijsvanloef/palworld-server-docker:latest
      restart: unless-stopped
      ports:
        - 8211:8211/udp
        - 27015:27015/udp
      volumes:
         - ./data:/palworld/

   server-manager:
      image: golang:latest
      restart: unless-stopped
      depends_on:
         - palworld
      network: container:palworld # <-- This line right here
      command: "/src/server-manager"
      cap_add:
         - NET_ADMIN
      volumes:
         - ./src:/src

And then there were more problems...

Putting server-manager in palworld's net-ns worked well for a while: server-manager was able to use conntrack to monitor UDP connections to the Palworld game server port. However, after about a day, I'd suddenly stop getting messages when people joined and left unless I restarted server-manager manually. Suspiciously, it would also fail to connect to the rcon server the game binary exposed on 127.0.0.1:25575 even though I could still connect to it from other containers in the same stack (that I didn't include the docker-compose.yaml examples above).

Remember when I said that the server needed to be rebooted regularly? I noticed in the logs that this all started happening after it rebooted. The server status messages in the screenshot above come from the palworld container. When its scheduled restart time comes, it shuts down the server which causes the Docker container to exit. Because the service has restart: unless-stopped in its definition, Docker will then automatically recreate the container.

Turns out, when this happens, the new palworld container gets a new net-ns, but since the server-manager container hasn't restarted, it doesn't get connected to the new palworld container's net-ns: it's orphaned on the net-ns of the container that shut down. Thus, conntrack doesn't get any new connection events, and rcon can't reach the server on 127.0.0.1 (localhost).

If I wanted to keep the palworld container separate from the server-manager container so that they could be restarted or updated independently, I'd need to find a way to keep both of them in the same net-ns even if one or the other restarted.

Much ado about doing nothing.

So my galaxy-brain plan was this:

1. Add a third container to the docker-compose.yaml that would not restart.
2. Connect both the palworld container and the server-manager container to that container's net-ns.
3. Now, whenever palworld or server-manager restarts, they'd get connected back to the same net-ns.

I needed a container to do nothing, but in a reliable, easy-to-understand way. There are hacks for doing this using a shell, but it seemed like a pretty heavy way to do it. The best named shell-hack I found is named cat-abuse: you run cat, which will listen for input from stdin until it reaches an EOF marker, which will never happen if you don't attach to the container or otherwise feed it input, so it'll wait forever. I've been learning Go recently since a friend was passionate about teaching me, so I figured let's give that a try.

Enter, the world's most useless Go program:

package main

import (
	"log"
	"os"
	"os/signal"
)

func main() {
	log.Printf("Waiting forever. Ctrl + C to interrupt...\n")

	sigChan := make(chan os.Signal, 1)
	signal.Notify(sigChan, os.Interrupt)

	<-sigChan
	log.Printf("Got SIGINT, exiting.\n")
}

This program registers a handler for SIGINT, which is the signal sent to the process when you type Ctrl + C in a shell. It creates a Go channel that will receive a message when the program receives a SIGINT, then it waits until it receives that message. It blocks until it does, so unless you explicitly send a SIGINT to the container, it'll wait "forever".

Technically, the signal handler isn't even necessary. You could block forever waiting for a message on a channel that no one will ever send to. You don't need to pass it to a handler that could conceivably send a message. I just hooked up SIGINT to make it more explicit that it's not supposed to stop waiting unless the program stops. You could simplify it, but I think it's less elegant.

package main

func main() {
	sigChan := make(chan struct{})
	<-sigChan
}

Next, I added a Dockerfile to build the image, in as lean a way as possible:

FROM golang:1.22.0
COPY ./src /src
WORKDIR /src
RUN go build -o /bin/wait-forever ./main.go

FROM scratch
COPY --from=0 /bin/wait-forever /bin/wait-forever
CMD ["/bin/wait-forever"]

With that in place, I could update the docker-compose.yaml:

services:
   wait-forever:
      build:
         context: ./wait-forever
      ports:
         # Forwarding for Palworld server b/c this container owns the netns
         - 8211:8211/udp
         - 27015:27015/udp

   palworld:
      image: thijsvanloef/palworld-server-docker:latest
      restart: unless-stopped
      network: container:wait-forever # <-- Connected to wait-forever

      # Note how the port forwarding got moved to wait-forever
      # ports:
      #   - 8211:8211/udp
      #   - 27015:27015/udp
      
      volumes:
         - ./data:/palworld/

   server-manager:
      image: golang:latest
      restart: unless-stopped
      depends_on:
         - palworld
      network: container:wait-forever # <-- Connected to wait-forever
      command: "/src/server-manager"
      cap_add:
         - NET_ADMIN
      volumes:
         - ./src:/src

Notice how the the palworld container no longer contains the ports: map that forwards ports from the host to the container. Because it has network: container:wait-forever, it's not allowed to forward ports. That has to be done on the container that owns the net-ns, which would be wait-forever.

With that in place, the server has been running for about a week without issues. server-manager pings the Discord even if the palworld server restarts, and I can start and stop them separately (e.g. to update server-manager).

I'd love to dig into how server-manager works, but that will probably have to wait for another time. Similarly, I'd put the code up, but it's not mature enough to share (or to collaborate with other folks on), so for now, I hope this post helps anyone who needs to make Docker Compose act a bit more like Kubernetes.

For the first time in months, I remembered what it was like to be obsessive about my work: always trying to get in one more feature before bed and then staying up too late. It's been nice to feel that again after a long break, but even better to be able to see it with fresh eyes and think about it more clearly. I suspect that I'd grown habits around the way I approached my work (both the technical and non-technical aspects of it) that might have been local maxima.

In between interview prep stuff, I've been working on a side-project to empower players in tabletop roleplaying games like D&D to take notes that make campaigns more memorable. Here's a rough pitch:

For a start, I'm trying to empower three particular players since my friends and I have struggled to manage our one hundred forty-two page Google Doc where we keep the last three years of notes about our ongoing campaign. The loading time sucks. Searchability is surprisingly bad because no one spells the names of fantasy NPCs (non-player characters) correctly or consistently. Answering questions like "When did we last talk to this person?" or "How many days has it been since we left town?" can take a while to answer, which breaks immersion.

I've talked to these friends for years about wanting to do something about it, and this is me taking a swing at it.

I drafted this dev diary after my first week working on the notes app, and I'm sharing it now just for fun – nothing is ready for folks to play with yet. Here are my miscellaneous learnings from that week.

Flow is fun, decision making is draining.

The best part of the process is when you know exactly what you want and get to chip away at it piece by piece until it's done. Most coding problems get me into that flow state; even though coding requires making a lot of small decisions, it feels like solving a puzzle. Solving simple puzzles are more fun than work. The reward of solving it is greater than the cost of the exertion, and it makes you feel smart. However, making challenging decisions is draining for me to the point where it's demotivating.

I think what differentiates the easy decisions from the hard ones is that easy decisions have a clearer "right" answer, provide feedback sooner, and have better understood costs for correcting them.

For example, implementing a straightforward UI component can be fun because you get quick feedback and an obvious way to iterate. It's almost like sculpting in that you can get the basic shapes in quickly, then iterate until it's right. Slap some <div>'s in there, add some basic CSS, and then take a look. Looks too crowded? Add some white space. Font isn't legible? Make it bigger (or better yet: work on your visual hierarchy). Most of the time, you know what you can do to make it better, and you can do it in small chunks.

Many technical problems look this way too: Writing a parser? Make it simple then iterate on it until it's better. Need an ID service? Write one that hands out sequential numbers and wait to refactor until you need one that can shard across multiple clients. Need a client-server protocol? Bash out something naive that causes conflicting writes to clobber each other and wait until your product has n > 1 users before you pull out the CRDTs.

In the case of something harder, the impact of the decision is less well known. During the week, I ran into this a few times when trying to decide which feature to build next. There's no one else on this project that knows the user's needs better than I do for the obvious reason of "I'm the only person working on this project", so when I run out of insight into the next thing to try, I'm stuck. The first time this happened, the prototype was as hacky as it could be: The data model was basically non-existent since I just wanted to fake enough of it to get a feel for the types of journal entries I had built (which were basic text and markers, each of which was a single field that was managed locally with React state). I wanted to test adding a quote callout entry, which would support having two fields: the quote text and an optional attribution line (i.e. who said the quote). Creating that would require either improving my parser or adding some WYSIWYG authoring UI. Adding that UI would require some more refactoring to change my static text components to support editing.

I ended doing a mix of both: I refactored my UI to support editing, but didn't quite build a full WYSIWYG composer interface.

I'm reminded of Jeff Bezos' system for categorizing decisions into Type 1 (hard to reverse) vs Type 2 (easy to reverse). That framework is helpful for me since it removes the pressure of having to optimize every single decision, but even still, it's hard to know whether a decision is Type 1 or Type 2 when any decision I make requires committing hours of time to coding it up, and I might not know whether it's part of a "magic moment" until it's had days or weeks of testing.

Thinking "better" is more efficient than thinking "harder".

When I get really wrapped up in a task, I feel compelled to not stop. This gets annoying when it would be more efficient to call it a day and drop the problem from my brain instead of stewing on it. This gets especially unhelpful when it coincides with having to make a decision through some uncertainty. My desire to make progress on the problem every waking moment (or at least to keep the problem fresh in my mind so that I don't lose context) leads me to think about whatever I'm stuck on 24/7. In the shower. While taking a walk. While pretending to pay attention to a YouTube video. Always. I remember there were times as a new grad where people would walk up to me and ask me a question and I'd totally miss that they'd said something because I was still stuck in my head and hadn't taken a step back to "be a human again".

I remember that when I'd have to make these sorts of tough decisions, my brain would fog up, the way that it does when I'm shoved in front of a whiteboard coding problem after not having done one for too long. It's not that I can't solve it, but until I get over the mental block, it's slow going. I'm starting to think that this is more of a learned reaction to these sorts of problems rather than an inherent part of how I think, and maybe the culprit is trying to keep the whole problem in my head instead of using other thinking aids like writing a document or drawing a diagram.

For example, I needed to figure out what feature to build next based on how much it would inform my product hypotheses. There wasn't an obvious answer, and it was clear that whatever I tried, it would take a while to validate. I found myself impulsively turning over all the possibilities in my head: maybe option A could be justified because of this, or maybe option B ought to supersede it because of some other principle. Eventually I had to tell myself to stop thinking about it because I was draining my mental "juice" running the same thoughts over and over again in my head like a mercury delay line: spinning and repeating in an attempt to prevent the thought from decaying, but without the focused thinking needed to distill it and make forward progress.

I brainstormed some ideas for how to spot and break these cycles:

• Identify when I can't make any more forward progress, and put the problem down for a bit. It might be clearer in the morning, or some inspiration might strike from another place.
• Write things down instead of trying to keep it in my head. Don't waste valuable brain juice on keeping things remembered. Make it OK to stop thinking about the problem because you've committed it to a place where you can easily get caught back up. (And who knows, maybe the act of writing will lead to clarity.)
• Pay attention to my body and do the things I know I need to do to take care of myself, even when I don't feel like doing them because I'm hyperfocused on a problem. Basic things like "If I eat something, my brain will clear up and I'll not feel like I have to finish every single thing right now."
• Try to unload my brain before I go to bed. I enjoy falling asleep while chewing on a problem. That's probably unhealthy, but it usually works if what I'm turning over is unimportant and I can let it fade into nonsense as I fall asleep. But it really doesn't work when I'm still wound up and invested in solving the problem because instead of helping me let go and fall asleep, it keeps me wound up and anxious.

Iterative development means continuous refactoring and migration.

I never really connected the dots that iterative development necessarily implies having to refactor things constantly. I associated refactoring with bigger code bases, not greenfield solo projects, but I found myself constantly refactoring every time I implemented another set of features. In retrospect it's pretty clear why: when prototyping, you don't know what your final goal state is, so you can't make big architectural decisions that account for everything you'll need. With the exploratory prototyping I was doing, I didn't have a clearly defined product with specs or a PRD, or even a comprehensive mock in Figma. The only sane way to implement features without overthinking them was to implement them in the barest, hackiest way possible. Just trying to make something I could poke at to vibe it out and try to find where the magic moments are. So naturally, every time I needed to build a new feature, I'd have to refactor out the placeholders and hacks that were there before.

Refactoring by itself isn't an issue. It's a normal part of all software engineering work. The more challenging part is managing migrations and consistency. This, again, is something that I had only associated with big systems. So many of my and my friends' projects at work over the years have been migration related. Migrations are hard, and maintaining backwards compatibility until you're ready to cut over requires a lot of planning. Because I was refactoring the data model so much as I added new journal entry types, I started running into compatibility and migration issues even though I was only three days into developing this project.

Some changes were simple to account for: I added the ability to add titles to scenes, so I added a new title field and made it optional. Easy. All the previous samples kept passing typechecking and rendered just fine. Then I refactored the way text with entities is parsed (i.e. turning "@Abby is sus" into "Abby is sus").

Originally, I parsed it when it was rendered with a couple optimizations to make it acceptably performant for the prototype: a custom tokenizer to parse it in a single pass and some memoization. But when I wanted to implement a tag search feature, I thought it would be more efficient to parse the text when it was added to the journal and store the parsed entities with each entry. This meant that all my previous example data (both real data from testing and sample data) needed to be migrated to use the new types, which was daunting because almost every field that used to be a string was now an object with multiple properties that required parsing to accurately spit out.

On its own, this would be a trivial refactor, and all future text entries would be created in the new format without issue. However, I had tested out the app for one real session of D&D with my friends and now I had a whole session's worth of notes that I had to migrate to the new format. It was frustrating to deal with maintaining this "real" test data while iterating, but in the end I think it's worth it. Testing is the only way to really learn what's working, so I think this is going to force me to build better tools for managing these data migrations.

The new Typescript definitions didn't match the signatures of the data created with the old format, so not only would it not render, but the app wouldn't even build because the old data failed to type check. I ended up using a mix of regex and migration functions to make it work: regex to replace the plain strings with dummy objects that contained the raw strings but not the parsed entities (thus matching the type definitions but being semantically incorrect), and then a migration function that took in those dummy objects and re-parsed every string to get the data to be consistent.

VS Code's regex find and replace (⌘+F, then click the .* in the search menu) has been a useful hammer for me many times in the past. In this case, I took my JSON file and ran this regex over it:

Find:    "text": "(.*)"\n
Replace: "text": {"srcText":"$1","segments":[],"entities": []}\n

With this kludge in place, the .json file passed type checking and I could use code to continue the migration. I just needed to run the text parser on text.srcText and substitute in that result instead.

Testing is the only way to know where you stand.

Actually committing ideas into a prototype and then testing it is how dreams die. But it's also how great products are born. You can't solve the whole problem on paper without testing it out, so the only way to really focus on your problem is to not be in love with your solution. And the way you do that is by dashing your solution against the rocks as fast as possible. This is all pretty well-accepted dogma at this point, but it still hurts to do.

I was sure that my scene-based note taking would be the foundation for better D&D notes, but then I tried it out for one session and realized that when you try to take notes on a scene, half the time you're just transcribing the scene. Sure the app can give you more structure, but it's not encouraging you to take efficient notes, and all the energy and attention you're putting into the app is a direct tradeoff against being present at the table with your friends. Furthermore, it turns out that for the game I'm currently playing in, the story doesn't tend to play out in clean "scenes" that all happen at one place and time so much as it does in "sequences", or strings of events, attempts, and often short scenes that are all tied together by a common goal or story beat. So that's all gonna need some tweaking.

Similarly, I was confident that using tagged entities in the notes would lead to a much better way to organize knowledge: essentially turning your session notes into wiki articles about all the things in your world. I tried prototyping the "wiki" pages as a tag search. It turns out: when you search for the player characters, you get almost every entry in the journal because the PCs are in every scene. Not very helpful. When you search for more obscure things, it can be a bit more helpful, but it's still a lot of barely-structured text to sift through. That was a rude awakening because I was counting on this tagging and auto-organizing feature being a differentiator over a generic text editors like Google Docs or Notion. I'm glad I got this learning early: it's not enough to just dig up relevant notes, the real value-add is separating important notes from unimportant ones. I've got to start figuring out what players are looking for when they look at their notes or a wiki in the first place. Maybe it's to remember where they met a person, or to confirm if they'd ever heard a certain name before. Or maybe it's to recall the description of a city they'd been to before, to keep the world feeling real and show the DM they're invested. In those cases, it's important to separate out important info like "The city of Mithralhelm is a Dwarven city known for crafting items out of mithral." from un-interesting mentions like "Got to gates of Mithralhelm".

Have a hypothesis for what delivers value and focus on that to make decisions.

Two of the features I thought would be slam-dunk cornerstones of the experience turned out to need lots of tweaking: grouping notes into scenes wasn't as good a match for how things play out at the table as I thought, and organizing notes by tagging entities wasn't an automatic win like I had naively hoped. That said, I feel like these learnings pushed me further towards understanding why the things that work will actually work: taking more notes is not better. It's far better to be efficient at taking the most useful notes instead.

I hypothesize that there are three main ways that notes can make the game better:

1. They improve verisimilitude by recording time and place more accurately, so that the world can develop in response to what the players do.
2. They help players remember key bits of lore and clues that allow them to figure out important mysteries about the world or plot.
3. They help players remember the most dramatic, emotional, and interesting things that happened so that they can revisit or retell it later.

So while I'm still a bit sad that my first swing wasn't a home run, I think my learnings ultimately support my hypothesis. There are clearly better and worse ways to take notes, which means that there's a place for a product that nudges you towards better note taking. For my next iteration, I'll have to make sure I don't conflate "more notes" with "better notes", and learn what truly effective notes look like in practice (e.g. what new kinds of journal entries to build or how to organize the types I already have).

Technical PS: Making React components more efficient with memo(...)

I've worked with React for years now, but I just learned this week that React will re-render all child components when its parent re-renders unless you wrap that component with React.memo(...). This signals to React that your component is actually a pure function like it's supposed to be, and will not re-render your component if its props don't change. I thought this was the whole point of React, to limit the amount of re-rendering done by scoping down state updates when props don't change, but I guess it's not automatic. I've always written React components to minimize un-necessary re-rendering with thrashy state changes, or subtle reference changes (e.g. recreating arrays or objects using spreading when they haven't changed), or lists without keys, but I didn't realize I had to use React.memo too.

I found it by using the profiler. This isn't the first time I've prototyped a text editing experience, so I knew going into this that typing needed to feel smooth for the UX to be acceptable. After looking at the profiler results on a small data set with fewer than 20 journal entries, I tried it on a larger one with hundreds of entries to see if render times for each keystroke were scaling with the number of entries. Turns out, yes. Each entry only took a fraction of a millisecond to render, but with hundreds of them, that added up to 10+ms for a state update on every keystroke. Totally unacceptable. After adding in memoization, I saw most entries not re-render on each keystroke, taking the state update time down to <1ms. More importantly, it no longer scales with the number of journal entries (at least not significantly – technically the underlying data model manipulation does require O(n) scans of the journal's underlying data to update. This too can be easily fixed in a future refactor.)

A few months after I started working on my first team, my product manager sat me down and asked, "Are you burning hot or burning out?". It was a week or two before Thanksgiving, and more importantly for our team, Black Friday. We were juggling a lot of projects at the time since our team had formed only a few months ago, and Black Friday would be our highest traffic period for months. This presented us with a unique opportunity to test a bunch of hypotheses about our product's purchase funnel and learn how to optimize each step from awareness to checkout. I was a newly minted engineer and the first engineer my manager recruited for the team, so I was an integral part of the juggling act too.

My product manager continued,

"I recently learned that there's a fine line between burning hot and burning out. There's nothing wrong with burning hot, but you have to be really careful to know which side of that line you're on."

I burned hot on that team for a while, pushing out experiment after experiment for months. We had a great half. Our team grew, and my role grew with it. Suddenly, instead of just juggling features and experiments, I was juggling projects, managing interns, and advocating for new initiatives. I was pushing myself hard, to the detriment of my health, but I was learning a lot, our team was getting recognition, and I felt like I was burning hot. In retrospect, it wasn't sustainable. I was slowly sliding down the path from burning hot to burning out, but it's hard to notice it happening when you're in the thick of it.

Three years later I was still on that team, and Fall was rolling around once again. It had been a thrashy 18 months for the team, and I was feeling it acutely as it compounded with other things going on in my life. By the time summer ended, I was working on projects on my own team and another team at the same time, mentoring an intern, and ramping up new folks. All of a sudden, I couldn't deny that I was starting to burn out, so I took some time off. Less than a week after I got back, I started feeling the burnout again.

My engineering director offered to chat with me about it, and when I explained the situation to him, he said:

"If you take a vacation and immediately start feeling burnt out when you get back, there are probably systemic things about the work you've taken on and the expectations you're under that are causing you to burn out. No matter how many vacations you take, you'll always keep burning out if you don't address it. I'd rather you declare bankruptcy on some of the projects you're working on now and find a more sustainable workload than have you burn out trying to do too many things at once."

It took me a while to accept it, but it was good advice. I dropped some projects, sequenced projects from both teams instead of trying to do both in parallel, and eventually transitioned to work on the other team full time. The switch worked out really well for me and I managed to do better work without immediately burning out again. It made me wonder why I took so long to make a switch.

In retrospect, here are some of the reasons:

• I was working towards a promotion, and switching teams can be risky. I had been trying to get promoted on my old team for a while, and was building up to it by taking on more and bigger projects. I had a track record of mentoring interns and new engineers on my old team, and I had built the first version of many of the surfaces that the team owned, so I had a lot of institutional knowledge about what we had tried in the past. Switching teams meant potentially complicating that story or having to prove myself to new teammates. Fortunately for me, I'd already been working with my new team for a while before I switched, and my old team vouched for my work.
• My friends were on the old team. I had friends on the new team too, and I knew when I met them that it would be a solid team, but it's hard to let go of seeing people you've gotten really close to every day. The way the company worked, you spent a lot of time working with your team, and the kinds of teams I like to work on are especially collaborative (and chatty), so changing teams would be a big shift in my day to day routine.
• It felt like I was giving up on my old team and abandoning my friends who were still there. Our team was experiencing a lot of thrash then, and had been for over a year by the time I left. Thrash like that causes a lot of stress for everyone in the org, and it can be a big impediment to the growth (and career advancement) of more junior engineers like I was at the time. It felt like maybe if we could launch a few good projects, we could get the team back to a happier place. Of course, it was never my problem to solve. As a junior engineer and a junior person lacking both the technical and organizational experience to navigate these sorts of issues, no amount of effort on my part would have "fixed" it. Addressing the team's problems required skills I lacked and triggered my anxiety in a way that put me at a disadvantage to contribute to a solution. Far more senior folks were already working to right the ship, but such change is slow and not obvious to a junior person.
• I was nostalgic for the "good old days" from the team's first 18 months, when we were riding high and having a lot of fun working together. That was the carrot dangling perpetually beyond the current period of thrash. Of course, things could never go back to the way they were. The world doesn't stay still for three years, and especially not in tech. The way the company worked was different, our product's place in the market was different, and leadership's expectations of our team were different too. If I'd had the maturity to try to create something good for the moment instead of pining for the past, I might've had a clearer idea of what was possible.
• I was pushing myself close to (and often beyond) my limits. There were many weeks where I felt like I was barely above water, and every moment spent outside of work was just recovering enough mental and emotional energy to drag myself through the work day. That situation made it hard to really rationally reflect. I was dependent on my routine and support from my friends on the team just to stay sane, so I was having a hard time compartmentalizing work, and I was too emotionally drained and anxious to take risks.

Some of these lessons I had to learn the hard way, but as I reflect on them, I'm very grateful that the people I worked with chose to mentor me through burn out instead of coming down on me for it. I value the culture that the company had of trusting that they hired the right people and making it easy to try out different teams. A culture that avoids blame views burn out as a sign of systemic failure instead of personal failure, and I think that gave me the mental space I needed to recover and learn from the experience.

Last year, some friends were planning to visit Taipei and asked me for advice, so I slapped together some tips on how to get around from my trip there in May 2023. This post was sitting around collecting dust for so long that it's probably out of date, so I figured I'd just post it. I'm not really qualified to give advice because I'm not local nor do I go there often, but I wrote down what I figured out, and now I pass it along to you.

The Basics

You can expand each section for more details.

USD/TWD Currency Exchange Rate & News - Google Finance

Get the latest United States Dollar to New Taiwan dollar (USD / TWD) real-time quote, historical performance, charts, and other financial information to help you make more informed trading and investment decisions.

Google Finance

Things To Do

Honestly I'm not a great guide for what to do in Taipei as I usually have other obligations to attend to when I'm there, so any free time I have is spent shopping and trying new food.

National Palace Museum

If there's one cultural thing I'd recommend, it's seeing the National Palace Museum. It's one of the world's largest collections of Chinese historical art and artifacts. But also, it's Taiwan so their most famous items are two pieces of jade that look like food. Be warned, it's a bit far from the city center, so it'll take a while to get to and from, but it's reachable by public transit.

National Palace Museum · No. 221, Sec 2, Zhi Shan Rd, Shilin District, Taipei City, Taiwan 111

★★★★★ · History museum

National Palace Museum · No. 221, Sec 2, Zhi Shan Rd, Shilin District, Taipei City, Taiwan 111

Taipei 101

The area around Taipei 101 is a shopping and office district. There are restaurants and shops around it, and it's a decent place to walk around for a bit, but I'm not sure what else to do around there besides eat and shop. There's probably an observation deck you can visit too but it's not really my thing. I feel like I pop by when I visit Taipei just out of obligation, but it's not that memorable.

Ximen (西門)

Ximen · No. 32-1, Baoqing Rd, Zhongzheng District, Taipei City, Taiwan 100

★★★★☆ · Subway station

Ximen · No. 32-1, Baoqing Rd, Zhongzheng District, Taipei City, Taiwan 100

The shopping area around Ximen station is probably more touristy/hip than the bigger stores by Taipei 101. There's a lot of food, clothing, and some lifestyle stuff like stationary and arcades (?). It's a decent place to walk around.

Getting Around

Overview

• Public transit in Taipei is really good. You can get almost everywhere efficiently using the subway (called MRT) and bus system. The city also has a bike-sharing program called YouBike that’s easy and cheap to use (once you set up the app), with good Google Maps integration.
• Uber works in Taipei and integrates with the local taxi system. Getting around via taxis/Uber is cheap and efficient, and is a good way to move around the city in ways that cut across the MRT routes.

Getting an EasyCard (the local metro card)

• The local metro card is called EasyCard. It's a stored-value card that holds a balance of NTD that gets deducted when you tap in and out of public transit. Like Tokyo’s transit cards (Suica/Pasmo), you can also use them to pay at certain shops, like 7-Eleven, McDonalds, etc.
• The easiest way to get an EasyCard is to buy one in an MRT station. There’s a separate machine for getting a card vs adding value. You’ll need cash for this, and a new card usually costs 100 NTD. This only covers the cost of the card and doesn’t include any stored value, so you’ll want to add some more value after that (e.g. 100-200 NTD at a time depending on how long you’re staying).
• You can also buy an EasyCard at 7-Eleven and other convenience stores. You can buy the EasyCard itself with a credit card if you buy it at a convenience store, but you’ll still need cash to add value to the card, even in a convenience store.

7-Eleven sells EasyCards in cooler/cuter forms than the usual credit-card form factor that the MRT station vending machines sell:

• There are keychains and pendants
• Novelty items like miniature bottles, coffee cups, and candy boxes.
• My personal favorite, a miniature version of the Taipei MRT trains that lights up and plays the door-closing chime when you scan it (using NFC power – there’s no battery, and you can trigger it with your phone).

Call A Car: Ubers and Taxis

• Hailing taxis on the street is safe and convenient… if you know how to describe where you’re going in Chinese. Otherwise, just use Uber so that the driver gets the address without you having to explain it in Chinese. If you do try to hail a taxi, look for ones with a lit up red sign that says “空車” (empty car).
  • I don’t know how you pay for taxis these days. IIRC, they prefer cash but you can pay for most with a credit card or EasyCard.
  • Uber doesn’t seem to cost much more than calling a taxi directly, so I recommend doing that.
• A 5-10 minute taxi ride can save you 30 minutes getting around on public transit if your origin or destination aren’t close to a good MRT route. A ride of that length will cost you around 100-200 NTD (~$3-6 USD).
• Often times, taxi drivers will confirm your destination (in Chinese) by checking the street and section with you. For example, you might be going to a location near Fuxing South Road, Section 2. I have no idea where my destinations are in terms of streets and sections, so I just use Uber and then nod when they ask. Dunno if that’s the best advice, but I've managed to get to my destination every time so far.

How to Use the YouBike Bike Sharing System

• There are YouBike docks stationed all over Taipei. You have to check out a bike from a dock and return it to one to complete your ride.
• Google Maps knows where they are and integrates with the YouBike app to tell you how many bikes are docked at each station in real time.
• Taipei has dedicated bike lanes on the sidewalks which makes it safer and more comfortable to get around by bike. It’s a bad idea to bike on the road (unless it’s down a small alley – I wouldn’t do it on major streets). The sidewalks along major streets are usually very wide, with a covered walkway extending out from the storefronts and an uncovered part on the road side. Typically, pedestrians walk in the covered part, and bikes go along the uncovered bit, but people weave all over the sidewalks, so be alert.
• Locals usually register their local phone number and EasyCard so they can just tap to unlock a bike. Tourists can’t do this without a local phone number, but they can still unlock bikes using the app.

The workaround is to get the YouBike app and use an alternate setup to allow you to unlock bikes with the app for 5 days at a time (after which you’ll have to re-register):

‎YouBike微笑單車2.0 官方版

‎【 YouBike微笑單車2.0 官方版】 開啟你的YouBike 2.0 旅程 方便且快速租賃的24小時公共自行車服務系統， 無論通勤通學、觀光旅遊、運動休閒隨時都能享受騎乘樂趣！ 下載YouBike 2.0 APP讓您即時掌握完整功能：快速註冊會員、交易紀錄查詢、會員卡片管理、即時場站動態查詢、公共自行車傷害險資料編輯…等等。 【服務地區】 臺北市、新北市、新竹縣、新竹市(含新竹科學園區)、苗栗縣、臺中市、嘉義市、台南市、高雄市、屏東縣 ※提醒您此為YouBike 2.0 專屬APP，欲查詢YouBike 1.0資訊，請下載YouBike 1.0 專屬APP。 【租借步驟】…

App StoreYouBike Co., Ltd

YouBike微笑單車2.0 官方版 - Apps on Google Play

YouBike Smile Bike 2.0 Official App

Apps on Google Play微笑單車股份有限公司

1. Download the app (you can pick English somewhere, I forget where).
2. Go to the registration page. On the bottom, there’s a link that says “Single Rental”.
3. Confirm your email address and add a credit card. They’ll put a ~$100 USD hold on your card as a deposit, which is refunded after the 5 days ends.
4. You can use the app to scan the QR code on the bike (or enter the 4 digit bike number) to unlock. On a YouBike 2.0 (the yellow ones?) there are two buttons – a green one for unlocking with an EasyCard, and an orange one for unlocking via QR code/number. Hit the orange one and scan the QR code (or type in the 4 digit number) in the app.
5. Once the bike is unlocked, pull the bike back away from the dock.
6. Remember to re-dock the bike when you’re done. This locks the bike and stops charging you. There’s a metal lock block on the bike that slides into a slot in the dock.
7. Bike use is charged in 30 minute increments. The marginal rate goes up the longer you rent it (it’s meant for short term rentals). The first 30 minutes costs something like $0.33 USD.
8. After 5 days, you may need to go through this process again.

Quality of Life Tips

Dealing with the heat and humidity

• When it’s hot, walk slower and carry less. This sounds pretty obvious, but I tend to be a pack mule when I travel, and this doesn't work out well in the heat and humidity of Asia.
• There are 7-Elevens and Family Marts everywhere, so it’s usually easy to get a drink during the day.
• Wear face sunscreen. The Biore UV sunscreen is readily available and pretty good.

Download some apps beforehand

• Google Translate (iOS, Android): Download the Chinese (Traditional) offline data. The camera translation is really nice.
• YouBike 2.0 (iOS, Android): you need this to unlock bikes, and it’s like a 100MB download.
• I recommend downloading a map of the Taipei Metro as a photo on your phone for easy no-internet access. You can download a copy here.

Route Map & Timetables

Taipei Rapid Transit Corporation ─ Metro Service

Know where things connect underground (and via covered walkways above ground).

• For example, there’s an underground mall linking the Zhongxiao Fuxing station and the Zhongxiao Dunhua station.

東區地下街 · No. 77號, Section 1, Da’an Rd, Da’an District, Taipei City, Taiwan 106

★★★★☆ · Shopping mall

東區地下街 · No. 77號, Section 1, Da'an Rd, Da’an District, Taipei City, Taiwan 106

• There’s a way to get from City Hall Station to Taipei 101 through indoor, underground, and elevated walkways.

The non-standard EasyCard form factors are really cool.

• Every 7-Eleven seems to have a different selection of them, so I popped into them sometimes to check for anything new or unique. They tend to be near the register. The fun ones don’t look like cards, so it might not look the way you expect. Look for the EasyCard (or iPASS or iCash) logos on the top right of the packaging to see if something is a transit card, even if it looks like a stuffed toy.
• If you get something that’s not a credit card form factor, you can hang it on something for extra convenience. For example, if you get a keychain, you can hang it off your bag, or if you get a mini oolong tea bottle like I did, you can get a small retractable clip for it from a 7-Eleven or stationary store and clip it to your waist.
• I got the mini-MRT train EasyCards in the Metro Shop inside the fare area of the Zhongxiao Fuxing MRT station. It’s not on Google Maps as far as I know, but it’s inside the fare area, immediately before the escalator going up to the Brown line, on the right side. It’s immediately behind the Cremia (a Hokkaido ice cream shop that’s pretty decent, and is on Google Maps), but inside the fare area, so you’ll need to go through the gate and go around.

CREMIA北海道冰淇淋之神-忠孝復興店 · No. 302號, Section 3, Zhongxiao E Rd, Da’an District, Taipei City, Taiwan 106

★★★★☆ · Ice cream shop

CREMIA北海道冰淇淋之神-忠孝復興店 · No. 302號, Section 3, Zhongxiao E Rd, Da’an District, Taipei City, Taiwan 106

Bring your passport with you when shopping to get a tax refund.

• You can get a tax refund of about 4% on certain items you purchase that you intend to export from Taiwan.
• Technically, the refund amount is higher (5%), but most department stores take a 20% processing fee, so you net out to ~4% of the purchase price refunded.
• This usually only works at department stores and malls. For example, a Uniqlo or Muji in a mall will usually participate in the mall's tax refund scheme.
• Most places require you to spend at least 2000 NTD (~$60) in combined receipts at that department store or mall within a single day. You can reach that amount by shopping in different shops (so individual transactions can be less than 2000 NTD), but it usually has to be on the same day.
• You can only get a tax refund on items you’re exporting (or feasibly could export). Most importantly, this means you can’t get refunds on things like food that are consumed in Taiwan (though I think you can still get some food items refunded if you export it instead of consuming it). Things like clothes, electronics, and souvenirs are prime candidates.

The process is:

1. Bring your passport when you go shopping.
2. When you check out, ask if they have a tax refund. They need to prep the receipt for you to get you the refund, so let each store know when you check out. Also, they may need to split your cart into multiple transactions if some items qualify for a tax refund but others do not.
3. Ask where the tax refund counter is. Usually they’ll tell you what floor and you just go find the customer service area on that floor.
4. Take all your receipts and the items you bought to the service counter (usually take a number, or if there’s no line, say “Tax Refund” and they’ll direct you to the correct station). Give them your passport and receipts.
5. They may inspect your items to make sure that you purchased what was listed and that items qualify for a tax refund.
6. You may get a refund in one of two forms:

• Cash: they’ll hand you cash on the spot
• A voucher that you need to take to the tax refund counter at the airport to collect your refund when you leave.
• Either way, you need to keep your documentation with you and the items that you claimed the refund on. The government does random inspections of tax refund claims at the airport to make sure people actually exported the items they claimed a tax refund for.

I got into tech because I enjoy the feeling of being able to solve problems myself, without needing to wait for other people to shrink-wrap and sell a solution to me. When it actually works out that way, it feels validating: I have a problem, I write a program, and now I have two problems I have the tool I needed to solve the problem. It's nice when it's a technical problem, but it's even better when it's something I can use "in real-life" – my own small contribution to a world that feels right.

Last summer, when I was doing coffee training at Boot Coffee, I got frustrated by the process of totaling up scores when grading coffee. The process is called "cupping", and I have a more detailed description of the how and why of cupping in my posts about the class. The short version is that cupping is the process of grading the quality of a coffee, and it requires adding up ten sub-scores that include qualitative assessments of the coffee across seven dimensions and technical assessments of the coffee against three sets of criteria. When cupping formally like you do for the class, you have to use the traditional paper form, which captures qualitative descriptions of the coffee in addition to the scores. However, to get certified at the end of course, you have to demonstrate that you can cup coffee accurately within time constraints. The process of adding up all ten sub-scores under pressure, while you think about and adjust them, was stressful for me. It's too easy to make an arithmetic mistake, and you really don't want to get dinged for clerical errors.

Clear goals and hard time constraints are an excellent way to get minimum viable products (MVPs). I had two weeks of courses: week one was more introductory, week two was advanced. There wasn't much room for error in the second week; I'd have to have my tools and approach dialed in by the end of the first week. So by Thursday of week one, I realized that if I wanted to build something, I'd have to do it that night and test it the next day.

When I got back to my hotel, I got to work. I built a prototype with Typescript, React Native, and React Native Web – a combo that's worked well for me for prior web/native projects. For ease of distribution, I wanted to put it on the web so my classmates could try it, but for future-proofing, I used React Native in case I wanted to convert it to a native mobile app in the future.

If you want to play with it for yourself, you can do so here:

Note that it's designed for mobile, so it'll look weird on desktop.

Walkthrough

Here's a walkthrough:

1. Each of the categories is listed in order.
2. Scores in the qualitative categories go in increments of 0.25 from 6.00 to 9.75, so to pick a score, select a major digit (6, 7, 8, or 9) and then select a fractional component (.00, .25, .50, or .75). As a shortcut, you can double tap the major digit to set it to .00 (e.g. Tap 8 and then 8 again to set it to 8.00).
3. Each time you finish entering in a sub-score, that section will collapse to help you focus on the ones you still need to enter, but you can tap on a section at any time to re-open it.
4. For the technical categories, a coffee starts with full points (10 in each) and loses 2pts for each cup in the set of five that fails to meet the criteria for that category. These categories start off collapsed by default since most high quality coffees will not have any failing cups. If you do need to mark a failing cup, tap on a category to expand it, and then tap on the "✅" corresponding to the cup that failed to change it to a "❌" (noting which cups had defects is important in cupping).
5. If there are defects (cups failing in any technical category are defective), tap the "Defects" section to expand it, select the number of cups exhibiting defects, and then select the severity of those defects (i.e. "Taint (-2)" or "Fault (-4)").
6. The bottom sheet labeled "Total" keeps track of your score so far and includes a "⚠️" if there are sub-scores that haven't been filled in. Tap on the bottom sheet to expand it. The expanded view includes the subtotal and defect penalty, matching the way the paper form expects you to show your work.
7. There's a "Reset" button at the bottom of the "Total" bottom-sheet to quickly reset the form. You can use this between samples during a cupping session instead of having to refresh the page.
8. If you need a refresher on this, there's a "Usage Tips" section right under the header that you can tap to show some help text.

What It Doesn't Do

• It doesn't store any data persistently. Once you refresh the page or hit "Reset", all data is lost. It's a calculator, not a cupping data platform. There's no backend. This is intentional since I wanted to keep it as simple as possible to get the MVP done in time for me to use, and to reduce the risk of errors during the high-stakes second week of classes.
• It doesn't store qualitative descriptors about the coffee (e.g. flavor notes). It's just meant to replace a traditional calculator for summing up the sub-scores on the sheet. It isn't meant to replace the actual cupping form the way that some digital cupping tools do. This is because it was built for my needs as a coffee student, where we were tested on using the paper cupping form.
• Teach you how to cup coffee. I put in a couple tips in the "Totals" bottom-sheet based on the most common feedback we got in class, but other than that, it's not meant to explain how cupping works. It assumes that you're learning from someone qualified, and are just using the app to add numbers.

Design & Iteration

While the app looks really rough, I'm proud of getting it done fast enough to not only use, but iterate on and share with my classmates. Here are some of the considerations and changes I made throughout that process.

• "Brutalist" design. I didn't have time to make it pretty, so I indexed on usability. The visual style I went with is simple and closely reflects the underlying components. I did it out of necessity, but I think it's in the vein of "brutalist" web design, where a website's UI components stick closely to their raw HTML elements. I suck at picking good colors, so there are very few colors. I used brightness and size to indicate hierarchy: major digit selectors are brighter white since they're more important, decimal part selectors are a darker share to de-emphasize them, and the contrast between them provides a rhythm to the page that makes it easier to scan. The scores have a larger font size and more space around them to make them jump out. Color mostly comes from emojis, and they have very straightforward meanings: green is good ("✅"), red is bad ("❌", Reset button), and yellow is warnings ("⚠️").
• Polishing the score selector. My thought process went like this: the most naive score selector is a textbox that limits inputs to numbers, but we know that there are only sixteen possible values so it'd be better to show them visually for the user to tap instead of having to type it in ("recognition vs recall"). The sixteen possibilities could be laid out as a grid so it only takes one tap to pick a value, but a 4x4 grid has too many options – giving each a suitably large tap target would make the component too big, which would make it harder to scan the page and keep context on the task. The major and minor axes of that grid (major digits vs decimal parts) are independent, so we could compromise and create a solution that takes two taps instead: one for the major digit, and one for the decimal part. It's one more tap, but since the user is already thinking of the score as "seven plus zero-point-five", the second tap has minimal mental cost, and overall improves the usability over a big grid.
• Double-tap to select .00. After a day of testing the app in class, I realized that keying in round numbers like 8.00 was un-ergonomic because the .00 option was all the way on the left edge of the screen, requiring me to move my thumb horizontally (and shifting my grip) to do so. I tried making it so that when you select a major digit, it defaults to .00, but this interrupted the flow in two ways: first, the section wouldn't auto-collapse if you didn't explicitly pick .00 again since it didn't know if you were done keying in that score, and second, it meant that some scores now took one tap and others took two. When keying in ten scores, you want to make sure you didn't miss any, so the rhythm of each score taking exactly two taps provided important feedback which this change would break. I went home that night and tried something else: if you tap the major digit twice, it selects .00 for you. This felt good in testing. It solved the ergonomic issue of having to move my finger across the screen, but preserved the rhythm of having exactly two taps per score. Usability testing FTW!
• Keeping things in the same order as the paper form. In my first iteration, I put the three technical categories ("Uniformity", "Clean Cup", and "Sweetness") at the end of the list, after the final qualitative category, "Overall". I put them at the end because most coffees don't have issues that require docking points on the technical categories whereas every cup must be scored in the "Overall" category. I thought it would be more streamlined to keep the less-used categories further down and collapsed by default. However, when I tested it, I found it confusing. When I keyed in the scores from my sheet, I'd do it in the same order as I saw it on the form, so having the app in a different order broke my flow. The core emotional pain-point the app solves is alleviating the fear and stress of adding up my sub-scores incorrectly or too slowly, so I was very concerned about accuracy. I'm likely to go box-by-box on the paper form to ensure that all those numbers match what I keyed into the app, and if they're in a different order it causes cognitive dissonance. I solved this problem by putting the technical categories in their normal spot, before the "Overall" category, but collapsing them by default. That way, a user can visually see that those categories are accounted for, but without it taking up any more space than necessary. Finally, I applied that principle to the "Totals" bottom-sheet by putting "Subtotal" above "Defects" to match how the "Subtotal" box is vertically above the "Defects" box on the paper form.
• Tips and reminders. I knew I didn't want to put too much text into the app because the physical environment of a cupping lab is already quite busy, and the app needed to be as simple and predictable as possible. I included text in a few places that I thought aligned with the goals of the app:
  • Small encouragements at the top of the app to remind me to break out of stress-mode, take a deep breath, and do my best. They include emojis to add a bit more playfulness to a stressful environment. The three snippets on top were quotes from our instructor, Valerian, and meant to project his earnest support while he was busy administering the test. You get a random one each time you refresh, and I leave it to you to go find them all if you'd like.
  • Reminders of common pitfalls in the "Totals" bottom-sheet so that folks would see them when they're done adding up their sub-scores. These are things are that you should double-check before you consider the form complete for that coffee, so it makes sense to have them there from a workflow perspective.
  • Help text in a collapsed section under the header. I shared this app with my classmates and I wanted them to know about some of the flow-optimizing tricks I added to the app like double-tapping to key in a round number and the "Reset" button in the "Totals" bottom-sheet.

How It Was Received

By the end of the second week, half the class was using my app to total their scores. I asked for feedback and as I recall, everyone who tried it figured out how to use it, no one found any major bugs, and several folks had feature suggestions for future iterations. It was the tool we needed, and not much more. I love the feeling of having a tool that's designed specifically for you, with your needs and quirks in mind. Even more so when it works for a community you care for, and reflects their needs and quirks too.

Some folks suggested that I expand on it to build a full-fledged cupping data platform. That would entail things like logging descriptors and flavor notes, saving data across sessions, and facilitating multiple people cupping the same coffees in a given session (e.g. aggregating their scores, etc.). I thought about it, but didn't end up pursuing it because I didn't think the market need matched what I was well-positioned to create. The main people who cup coffee are coffee roasters and coffee buyers (people who go to farms and source green coffee, not consumers buying coffee). The biggest challenge for these folks isn't adding up numbers while under time pressure. I'd guess that their pain points are things like tracking which samples they're tasting given that they may have storerooms full of green coffee samples from farms, roasted samples for QC, etc. Addressing these pain points would be better handled by people with more domain knowledge of those particular roles. Sure, I could acquire that knowledge through user research and hands-on experience, but I'm unsure that a better cupping interface would be a good wedge into that market anyway.

Ultimately, I feel like I spent the right amount of time on it. If I had spent a month building it, I would be bummed if it didn't turn into a full platform product, but instead I spent about half a day on it in total before calling a feature freeze to ensure it'd be stable, and I feel like I got really good returns for that investment.

I don't have plans to keep working on it, but if you cup coffee and want some help doing arithmetic, feel free to use it.

It was Friday, the last day of SCA Sensory Intermediate.

Ok, no more essays. Today, let's talk about some of the exercises we did to develop our sensory acuity. Most of these exercises are easiest to do at a coffee lab that has plenty of supplies and different coffees available to play with, but I added some notes about how you might be able to do some of these at home (ideally with a few friends to help set up and clean up).

Smell With Your Feelings

I said before that if my brain isn't working, my nose isn't working. There's a big mental component to our ability to smell. I think that's good news: training your brain is easier than changing your cells. Through practice and intentional exposure to different smells, you can increase the range and depth of smells you can perceive.

We used a tool called Le Nez du Café to practice remembering smells. This kit contains 36 labeled scent vials, each representing one of the aromas found in coffee. Each vial has a number on it, and there's a booklet telling you the names of the aromas that correspond to each of the numbers. Just a quick semantic note: I'm using the term "aroma" here to mean "smell" generically since that's the term Le Nez uses. Some of these smells are found in the dry coffee grounds ("fragrance") and some in the wet coffee ("aroma"), and some are defects that you wouldn't want to find in any coffee. It's meant to be a training and calibration tool: having a lot of different aromas to practice with trains you to distinguish them, and having the smells in a distilled form instead of a natural one reduces variance so that we can use it as a point of reference.

That doesn't mean that the vials in the Le Nez kit evoke the most specific and accurate versions of a given aroma. Some aromas smelled more realistic, and others more "fake". Aromas in real life are blends of many complex molecules, some of which don't last long, and particular mixtures of these molecules allow us to differentiate many variations of a given aroma. For example, the flavor of chocolate is common and recognizable, but we've all encountered many different kinds of chocolates: even without going into the flavors of different cacao, Hershey's Kisses taste very different from a dark chocolate bar. We could identify them both as chocolately, but they have a very different quality both in flavor and aroma. The Le Nez kit includes a "dark chocolate" (#26), but it's not the best smelling chocolate you've ever had. It's kinda generic. Ditto with the apple (#17).

Some of the aromas don't smell quite right at first, like lemon (#15). I thought that one would be straightforward: it seems like everyone in California grows lemons in their backyards, but Californians tend to grow Meyer lemons, which have a slightly different fragrance than, say, an Italian lemon variety. I'm unsure what variety the Le Nez lemon (#15) is meant to resemble, but it took me a couple tries to recognize the lemon in the scent.

That's a lot of setup to say that the way you practice with the Le Nez kit is to sniff each of the bottles one at a time to learn their scent and associate them with their labels. Once you've done that a few times, you can blindly open a bottle, sniff it, and try to identify which one it is. It trains your ability to recall aromas and notice the difference between similar ones. It's much more useful for developing the general skill of remembering and analyzing smells than making sure you know exactly what a hazelnut (#29) smells like vs a walnut (#30) or a peanut (#28).

The main method that we learned for memorizing the smells was to sniff a bottle and write down what impressions and memories it evoked, even (especially) if the impression was different from what the label said. For example, almond (#27) smells Christmas-y to me. It reminds me of what I imagine an almond tart from The Great British Bake-off to smell like. It smells sweet. As another example, straw (#5) reminds me strongly of grass jelly. It reminded one of my classmates of a hay bale. I grew up drinking grass jelly. He had been on a lot of farms with hay bales. Different routes to the same place, and all individual and valid.

I'd recommend trying this method out if you can get your hands on some scents. It doesn't have to be a Le Nez set (unless you're prepping for the Q). An essential oils set could work, as could a handful of jelly beans. The key is to think about and write down how that smell (or flavor, if you're doing jelly beans) presents itself to you. Don't look at what the label says. Get in touch with your own senses and familiarize yourself with how it feels when you smell something. Identifying something from scratch is very different than matching it to a label. Pay attention to where and how you sense it: Is the smell strong or faint? Does you feel it in the front or back of your nose? Does it feel sweet or salty (or bitter or sour or umami)? Does a metaphor spring to mind, like "high notes" vs "low notes"? Does it have a color?

Once you've written down your impressions, check the label and see what you think. Smell it again and see if you can interpret it the same way as the label. Maybe you can form the same aroma object as the label with some prompting. Maybe you see where they're coming from, but there are elements of the smell that remind you more strongly of something else instead. Maybe you completely disagree with the perfumers and flavorists. That's fine too. You want to get into the practice of bringing all your aroma sensing tools to bear: your memories of other aromas, your subconscious feelings and associations, and your ability to describe the sensations happening in your nose and mouth.

Once you start doing this with some friends, things get even more interesting. We noticed that how a smell was perceived varied between people, between kits, and between days. For example, I perceive the Le Nez almond (#27) and walnut (#30) aromas as sweet and the peanut aroma (#28) as salty. One of my friends felt the opposite: he perceived peanut as sweet and almond as salty. Of course, you can't smell sweetness or saltiness. This bit about smelling taste modalities is literally all in our heads. My association with almonds was marzipan and baked goods, so I thought it was sweet. The walnut scent reminded me of my grandma's favorite ice cream, butter pecan. My association with peanuts was a snack can of salted peanuts, so I perceived it as salty. My friend might have been picturing salted almonds and peanut brittle, which would make for salty almonds and sweet peanuts. There's nothing right or wrong about it. It can be hard to differentiate certain clusters of aromas  in the Le Nez kit (like the nuts, #27-30), so you use whatever trick works for you. If you remember one nut as sweet and one as salty, it doesn't matter how other people perceive it as long as you perceive them that way consistently.

Another weird thing: some aromas took a few days to appear. Valerian mentioned in class that sometimes we can be "asleep" to some aromas that need some time to "wake up". The Flavor book also talked about this: if you encounter a situation where your brain needs to detect or differentiate smells that it didn't have to before, you'll sometimes develop the ability to do so after repeated exposure. When I first smelled the kit, some aromas didn't smell like anything to me. I could faintly detect something, but it came and went and was always so faint that I couldn't really pin it. When I first opened the kit, earth (#1), tea rose (#11), blackcurrant (#14), and butter (#18) all smelled like nothing. For a while I was trying to figure out whether my kit was a dud or if my nose was. I reviewed them a few times, taking them out once every day or two to smell through each one. After a couple tries, I could smell tea rose (#11) easily, earth (#1) most of the time, and even butter (#18) very faintly, but blackcurrant (#14) eluded me for over a week. After a while, I could smell something in the blackcurrant (#14), but I couldn't place the smell or associate any impressions or memories with it. We discussed it in class for a while (a lot of folks struggled with this one). Most memorably, someone said it smelled like dried beer. After looking for each of the things people mentioned in it, I managed to identify it most of the time. It even started to take on the scent of the leaves of a berry bush. Moral of the story is that if you don't smell something the first time, don't panic. Sometimes your brain will adapt to identify it after repeated exposure.

But sometimes, it's spotty. Some days, bottles that I could smell the day before would suddenly go dark. Sometimes, I'd spend an hour drilling on similar aromas and identify differentiating features about each only for things to jumble up again the next day. It got even more uneven between kits. Between our classmates, we had several different kits made at different times. Different production runs can create slightly different scents for the same aroma name, and they degrade faster or slower over time depending on how they're used and stored. Since the Q includes tests where you have to match bottles between two sets, our instructors had to get two kits from the same batch to ensure that they'd smell the same. Sometimes an aroma would smell one way on one kit and then be totally different on another. Other times, an aroma would be perceptible in one kit but be too faint in the other or start smelling like a different aroma. The general takeaway is that even with practice, smell can be finicky. If you're not taking a test on it, then no worries, just know that you don't need to panic if something smells one way one day and then a bit different the next. If you are taking the Q, I'd recommend calibrating on the test kits if you're able to. Even if you know your own kit by heart, the test kits may be different from yours (or even from each other, despite the same-batch protocol).

I feel like the Le Nez kit is a better training tool than an evaluation one. Practicing with it was eye-opening, but being able to recite the names, numbers, and categories of each aroma in the kit and identifying them by smell is just a cool party trick. It's really useful for exercising your sense of smell, but I wouldn't over-index on it unless you're taking the Q, in which case practicing with the kit at home is one of the easier things you can work on prior to taking the class.

Hello Coffee, Nice to Meet You

We cupped more coffee, of course. Going through the ritual of the full SCA cupping procedure over and over again made it easier. As the motions of it got less distracting, I had more time and mental energy to focus on the flavors of the coffee instead. As with the Le Nez kit, I found that the more samples you try, the more things jump out at you. Getting to try a bunch of different coffees is important for learning how to differentiate coffees, and it's one of the benefits of taking a training at a proper coffee lab.

In this cupping, I was super thrown because there was a spiked sample (phenol) but I didn't spot it even though I tasted every cup. This was the first time I'd encountered a spiked sample. I hadn't calibrated on defects (e.g. tasted them) before; I'd only heard their flavors described ("kinda like pool water or drinking from a garden hose"). Afterwards, I was so paranoid that for days I wrote "phenol" every time I tasted something weird, even when it was mold, some other defect, or not a defect at all.

We also calibrated on taste modalities by identifying sweet, sour, and salty solutions at varying intensities. It sounds like it should be easy to tell them apart (and at high intensities they are), but it can be tricky to tell if something is very slightly sweet or very slightly sour, for example.

Welcome to the Red Room

The next set of exercises involved comparing unidentified samples of coffee side-by-side. Because the goal was to differentiate the coffees based on their fragrance and flavor, we did these in a room that was illuminated by a dim red light to make it harder to tell the coffees apart by color. This adds its own twist to things by forcing everyone to be in the same small room together, juggling our various accouterment. By now we each had a spittoon, a cupping spoon, a small cup (for COVID protocol), a bottle of water, a pencil, and a clipboard. Every stool in the lab was recruited to create temporary work stations in the red room since none of those items were allowed on the tables with the coffee.

Let's start with the simpler exercise: targeted comparisons. In this exercise, we had trays with two coffees each. For each pair, there was a different question: "Which of these is sweeter?", "Which of these has a more pleasing acidity?", "Which of these tastes cleaner?". It's similar to what we did with taste modalities, but instead of ranking which citric acid solution was more sour, we did it with real coffees. I like how this exercise helps you break down a coffee's flavor into smaller components that are easier to analyze. It helps develop your ability to focus on one attribute at a time, and to remember flavor from one cup to the next, which is critical for scoring each of the ten categories on the SCA cupping form.

I think this is probably the easiest exercise to do at home. Just get a handful of coffees (maybe 2-4) and brew them up. Throw in a non-specialty coffee from the supermarket just to make the contrast starker if you can. Mix them up so that you don't know which is which, and then pick some axes to evaluate them on. Sweetness, acidity, and elements of mouthfeel like thickness and drying-ness could be fun to start with.

Next up were the triangulation exercises. Triangulation is a sensory test where there are sets of three cups. Two out of the three are the same coffee and one is different. Your job is to figure out for each set which is the odd one out. It sounds like it should be easy to tell two coffees apart. After all, the whole premise of specialty coffee is that different coffees taste different and that they are not just a fungible commodity. You can smell the difference between a non-specialty coffee and a good Gesha from a mile away, however, when you put similar coffees on the table it can get surprisingly tricky. The order in which you taste can amplify differences that exist or create ones that don't. When it's obvious, it's obvious, but when no obvious difference jumps out at you, it takes a lot of focus to zoom in on every little detail and taste things back and forth enough times to spot the difference. Especially under test conditions, this exercise is stressful.

In this exercise you usually want to analyze the coffees one axis at a time instead of trying to describe their flavor. We brewed each of these coffees using the SCA cupping protocol in the red room, so we got to see the coffee at many different stages of brewing to consider its fragrance, aroma, flavor, aftertaste, acidity, and body. At least for me, I had to make an intentional effort to take in the overall effect of the coffee to see if one axis or another would be easiest to compare. Advice from Valerian: do the easy thing. If the fragrance is clearly different, trust it. If the acidity is clearly different, trust it. If your achilles heel is describing the "body" and mouthfeel, try to examine every other factor first before relying on those. The more you taste the coffee, the more fatigued your palate gets, and the harder it is to spot the differences. The coffee also changes as it cools, and some differences are easier to spot at certain temperatures. You have to be vigilant about noting any differences you find right away and be confident to not second guess yourself later when the signal gets weaker.

Of the exercises we did, triangulation is probably the second most applicable (after cupping) when actually working on flavor development. It's used across the industry to experimentally determine if a difference is perceptible. Roasters use it when developing blends to make sure a blend tastes consistent as the input coffees change, or to evaluate if new equipment or operators are creating consistent results. Brewers use it to evaluate whether their brewing techniques are making a difference in the cup.

The test can work two ways: evaluating the tasters or evaluating the coffee. When you're taking a test, the coffees are known to be different and you're the one being judged. When you do this in practice, you don't know beforehand if there will be a perceptible difference between the samples, and you're judging the coffee. Note that this isn't a qualitative test: it's not about whether the odd one out tastes better or worse. It just determines if there's a perceptible difference. That difference can be a starting point to determine why they're different and which people prefer. Half the time, your goal is for there to not be a difference (e.g. making sure the latest version of your blend tastes the same as the previous one).

I'm not sure I'd recommend doing this at home unless you're practicing for the test or some other professional purpose. Specifically for the test, I think it takes some time to acclimate to the red room environment and get used to triangulating under pressure when there are a lot of people around you.

Week One Epilogue: Problem Student

Thus ended the first week of classes. The week was hard work, but it was fun. I'd discovered that I wasn't hopeless even if I still felt like I had a ways to go in developing my abilities to taste and describe coffee. Learning was fulfilling, meeting new coffees was exciting. Being able to taste and smell intentionally added a new dimension to everyday things like taking a walk and smelling a jasmine bush from a block away or trying a mango tembleque and having the flavor just explode in my mouth.

Since we only had one day off between SCA Sensory Intermediate and the start of the Q, I took advantage of the downtime to eat food that might be too flavorful to eat during the test. My friend Arnav came over to visit, and we settled on some (mildly) spicy Burmese food for dinner and relished in the intense flavors.

I'm writing this after both weeks of classes ended, but I wanted to capture some of the moments and feelings I had from day 4 (the 2nd day of SCA Sensory Intermediate) because I feel like it was a turning point where I started to understand how to walk down the path to refining my senses of taste and smell. It's a bit all over the place with bits I learned all throughout both weeks and some info from the books Flavor: The Science of Our Most Neglected Sense by Bob Holmes and Sip'n' Slurp by Freda Yuan.

We can start off with some info about papillae because in my last post I promised I'd cover it.

It was Day 4, the second day of SCA Sensory Intermediate.

Unless you're taking the course, you're probably not dying to know the details of papillae. The tl;dr is that they are the bumps on your tongue that contain most of your taste buds. Different kinds of papillae are more sensitive to different taste modalities and tend to group around certain areas of your tongue. It's not as clear cut as the "tongue maps" we saw in school imply; you're tasting all modalities in every part of your tongue (just to different degrees).

There are four main kinds:

• Fungiform: Mostly sense sweet. Make up ~50% of your gustatory papillae. Tend to be on the tip of your tongue. Mnemonic: "Fungiform sounds like fungus. Fungus grows in sugar. Sugar = sweet." Fungiform means "mushroom shaped", so that's not too far off.
• Foliate: Mostly sense salty and sour. Make up ~25% of your gustatory papillae. Tend to be on the sides of your tongue. Mnemonic: "The fo- in foliate kinda sounds like pho. Pho is sour and salty."
• Circumvallate: Mostly sense bitterness. Make up ~25% of your gustatory papillae. Tend to be in the back of your tongue to trigger your gag reflex, since bitterness usually indicates something you shouldn't eat (e.g. poison). I don't have a mnemonic for this, but it's the only one that doesn't start with "F", and humans are way more sensitive to bitterness than the other taste modalities.
• Filiform: These papillae don't sense a taste modality, but instead they sense tactile sensation (i.e. mouthfeel). They aren't counted as gustatory papillae (0%). Mnemonic: "Filiform sounds like feel-i-form, and filiform detects touch."

An Imposter in Coffeeland

Here's one of the moments that I kept jumping back to and made me wonder if I was crazy to attempt to take the Q:

I've always had to work harder than my friends to taste things, I just didn't realize until relatively recently that I could eat something and completely not think about how it tastes or smells. I grew up with bad allergies that meant I couldn't smell for large parts of the year. I enjoy food and I enjoy flavor – I just didn't realize that what I was tasting wasn't quite the same as everyone else.

It wasn't until I started to get into coffee that I realized that my ability to perceive flavor was different from my friends'. I helped organize events for the coffee club at work, and I put together tastings at home with my friends, but almost every time, when other people perceived a huge difference, I'd only perceive a slight one.

Feeling like you're different is a great way to trigger your imposter syndrome. You can't in good conscience claim that coffee should be respected because different coffees taste different and then be unable to taste that difference consistently. Instead I found that there's a lot to hide behind in coffee: everyone perceives taste differently, different brew methods and equipment can produce very different cups from the same beans, and the perception of flavor can be heavily influenced by what you ate recently. It's pretty easy to regurgitate talking points from coffee YouTube in lofty prose without being sure that you've experienced it yourself.

Flavor Isn't Really About Taste (Mostly)

One of the big "aha!" moments for me was grokking that "flavor" involves your tongue, your nose, and your brain. Flavor is a combination of what we taste (sweet, salty, sour, bitter, and umami) and what we smell. Sources disagree as to exactly how much taste and smell individually contribute to the overall experience of flavor, but smell appears to be the lion's share: if you pinch your nose and try to guess what flavor is in your mouth (e.g. from a jelly bean of unknown color), you're going to have a hard time. When you "taste" the flavor of a blueberry, it's your nose that gets all the floral, fruity sensations that make that berry unique. Your tongue is only sensing the basic taste modalities: the flesh is sweet and sour, and the skin is a little bitter and a little sweet or sour. Those same tastes could just as well describe any number of other berries: raspberries, blackberries, strawberries, and so on.

Our model of taste is simpler than our model of smell: we can enumerate basic taste modalities (even if there are debates on whether more exist), we have a somewhat intuitive model for how it's detected (papillae contain taste buds that are more sensitive to one modality or another), and we have substances that can evoke them in an almost "pure" form (e.g. sugar for sweetness, salt for saltiness, or citric acid for sourness).

By contrast, smells are more complicated: we don't have basic building blocks for smells or named receptors for them. Smell is more innate and primal in a way: the olfactory epithelium in our nose contains receptors for (we think) 400 or so odor molecules. These are wired into the olfactory bulb, a disco ball of sensory neurons that helps us interpret smells and plugs directly into the limbic system, which processes emotions and memories, bypassing the cerebral cortex. We name smells by comparing them to what we've already smelled, basically by pattern matching. We're taking readings off of a chemical analyzer (our olfactory bulb) and trying to fit our readings to a model of what we've encountered before in the world.

It's unstructured, kinda like a Rorschach test or cloud gazing, and it's hard to consciously think about. Usually, when we smell something we recognize, it triggers a snap association in our brains without us having to think too hard about it. But when we smell something like coffee, which can have a bouquet of interesting chemical signatures that don't cleanly match our model of any specific thing we've encountered (except, maybe, "it tastes like coffee"), we're left with something amorphous and hard to describe. If it's hard to describe, it's hard to remember, and if it's hard to remember, it's hard to compare from cup to cup or from day to day. So it can be frustrating and hard work to decipher if a coffee tastes like blueberries because it probably doesn't contain all of the markers that signal "blueberries" in our memory.

If we compare flavor notes to musical notes, it's like my memory of blueberries is a complex, jazzy chord with four or five notes stacked on top of each other, each representing a different odor sensation: e.g. a high grassy note, a tense floral note, a low berry tone, etc. A coffee that tastes like blueberries is like a moving melody that hits a couple distinctive notes in that chord, but not all of them. Analyzing music requires an understanding of music theory, a memory of chords and shapes, and then a lot of guessing-and-checking to come up with a hypothesis for what chord a handful of notes belongs to. Even then, it's often unclear and open to interpretation, both in music and in flavor.

All of this makes "Does this smell like blueberries?" a much harder question to answer than "Is this sweet?". It's a much more cerebral process with an unclear answer, and you have to arrive at a conclusion before the aroma fades.

In a way, this is also freeing: if a bag of coffee has "blueberry" written as a flavor note on it, it doesn't mean that it will smell or taste like a bucket of fresh blueberries. It only means that the particular bouquet of aromas and tastes in that coffee created the impression of blueberries in the mind of whoever wrote that flavor descriptor. It may very well create that impression in your mind as well when you drink it, but it very well might not, and that's totally fine too. Whether you get blueberries, a different fruit, or no fruit at all depends on your memory of those foods and the way your flavor sensing system interacts with that coffee.

More Structured Ways to Smell

So what was I doing when I was actively trying to look for a flavor note in the coffee outside Equator with Eugene? Turns out that all that slurping, swishing, and concentrating are pretty useful ways to actively smell.

Air goes two ways through your nose: you can breathe in, and you can breathe out. (Unless you're me in elementary school, in which case you can't do either of those things most of the year. Thanks, hay fever!) As air passes through your nose in either direction, you perceive smells. However, the smells you perceive breathing in are not the same as the ones you perceive breathing out. When you breathe in or actively sniff something, we call that "orthonasal olfaction". However, when you have something in your mouth (say, a strawberry or a sip of coffee) you perceive its aromas as you breathe out. We call this "retronasal olfaction" because the air flows in from the back of your nose. It's a big part of how both flavor and aftertaste work.

The Flavor book explains that these two forms of smelling work differently in two big ways:

1. What we're smelling is different. We smell the "outside world" with orthonasal olfaction (e.g. sniffing or breathing in), while we smell what's inside our mouths with retronasal olfaction (breathing out, aftertaste). When we breathe in, the current of air going in acts as a curtain, keeping the odor particles from inside our mouths from reaching the olfactory epithelium in our noses. This lets us get an accurate measurement of our environment or evaluate something that we're about to put in our mouths. When we breathe out, it works the opposite way: we're sending odor particles from inside our mouths up and onto the olfactory epithelium from the back.
2. Which smells we're sensitive to is different. The receptors for the 400+ different odor molecules we can perceive are not uniformly spaced out in our nose. It's a bit less clear how they're arranged (even compared to the already-inaccurate tongue map), but we think that some sensors tend to group in the front or back of our olfactory epithelium (and I'd bet that like the arrangement of papillae on the tongue, it's different for each individual). This acts as a filter over what we smell, sorta like how in audio you can have a high-pass filter (which ignores all the low frequencies) or low-pass filter (which ignores the high frequencies). Mechanically, this is because odor particles need to physically reach their matching receptor cells to contribute to the smell, which means they have to stay airborne long enough to reach them. Many molecules are heavy and will get caught in our mucosal lining before reaching their receptor, which filters them out of the smell. If a type of receptor is in the front, then we might get more signal from it during orthonasal breathing where the air comes in from the front, and less signal from it during retronasal breathing where the air comes in from the back and the molecules have a greater chance of being trapped before they can activate the receptor. That's probably one of the many reasons why coffee grounds smell very different from the flavor of the final drink.

When I slurped the coffee, it aerated the fluid, helping more volatile odor molecules to fly free of the liquid and get suspended in the air, where it could flow over my olfactory epithelium during retronasal breathing and get detected as flavor. It also ensured that the coffee fluid got all over my tongue so that each of the different types of papillae had a chance to measure how sweet, salty, sour, bitter, or umami it was. It's a similar story for swishing, gargling, holding the fluid in my mouth for a bit before swallowing, and doing that lip-smacking thing where you tap your tongue to the back of your teeth (and alveolar ridge). When I focused on searching for the flavor, I breathed more slowly and evenly, which might have helped optimize how far the odor molecules made it on my olfactory epithelium in both orthonasal and retronasal olfaction.

It's clear that I looked pretty silly (and maybe obnoxious) trying to enhance my experience of the flavor, but that's what it takes for me to maximize the opportunity for my senses to capture and analyze as much of the flavor as I could.

Maybe it's fair for Eugene to laugh at all this. That's a lot of work, just to drink coffee.

Theory, Meet Practice.

We did a few practice cuppings to get us used to the procedure of setting up and conducting a cupping. This also kicked off the process of getting calibrated in the way we assessed and scored the coffee, a process that would continue through the next week for those of us sticking around for week two to take the Q. The highest and lowest rated coffees quickly made themselves known; when you put that many coffees next to each other side by side, the differences stand out.

The best thing on the table was La Mula, a Panama Gesha developed, grown, processed, and roasted by Willem Boot, the leader of the coffee lab (his name is on the building) and our instructor for the Q. The sweetness and floral notes were bursting out of the cup from the fragrance of the ground coffee to the aftertaste of the brewed coffee. I was floored by how much flavor I was tasting consistently in every slurp and surprised at how quickly words, opinionated words, jumped to mind: the citrus-like acidity reminded me of yuzu, the body and tangy sweetness of Yakult, and the lingering finish like a milky oolong tea.

La Mula Gesha Lot 25 – La Mula Coffee

Sweet citrus acidity, aromatics of lemon, orange blossom, but also berries like blueberry. This coffee is shade grown under the canopy of local native trees in the tropical cloud forest of Panama. ORIGIN: Panama FARM: Finca La Mula ELEVATION: 5,906 feet (1800 meters) PROCESS: Natural

La Mula CoffeeName *

The other thing that was surprising was how quickly the class started to converge on a set of scores. There were some inconsistencies between different people, and I had one or two samples that I rated way too high or too low due to scoring issues, but after we discussed each coffee, it was surprising how many of us found similar flavors using slightly different descriptors, and how our cumulative scores could be similar despite different ratings for each individual attribute.

Over the course of two or three cuppings, almost everyone was binning each coffee into similar ranges. Even if there was a couple point spread, we were consistently putting the highest grade coffees in the high-specialty range (around 87+), and the lowest grade coffees in the non-specialty range (around 80 points, which is the cutoff for specialty grade).

Armed with the theoretical knowledge of how flavor works, I started to make adjustments to the way I tasted and smelled:

• I discovered that when my brain wasn't awake, my nose wasn't awake. I needed to eat a bit and drink some coffee to wake myself up before I could start analyzing coffee. Before I'm warmed up, everything just tastes like coffee.
• I realized that my glasses were sinking down on my face over time and when they got too low, they'd pinch my nose, making it harder to smell. I started to clean my glasses more or even take them off when I was going to smell a lot of samples in a row.
• I figured out how close I needed to get to the cupping bowls to smell the fragrance and aroma of the coffee (turns out: pretty close). I also discovered a trick where sniffing while moving my nose slowly back and forth above the lip of the bowl would create some contrast and help me find the spot where the fragrance was strongest.
• I settled on a breathing exercise where I'd breathe in slowly through my nose at around the rate that helped me smell the best and then breathe out slowly, first through my mouth, then through my nose. I think it was one part mental preparation, one part practicing the motion of smelling, and one part priming my body to open my airways.
• I picked a few different ways to move the coffee liquid around in my mouth to aerate the aromatics and feel the texture. My slurping got a bit more confident too – there's a bit of aim involved to get it all over your tongue without getting it into your throat, which will make you choke.
• I got better at knowing when my sense of taste was saturated and how to take a break and rinse out my mouth. Similarly, I picked up a trick whereby I would sniff my clothes when my sense of smell was getting saturated, the theory being that your own scent is neutral.

With all that in place, I was starting to feel more consistent, and since my inconsistency was my greatest fear going into the class, I was finally starting to feel more confident. After a couple sessions I thought, Ok, maybe I can actually do this.

Break Your Brain

A week of nonstop coffee drinking and coffee talk will fry your brain in addition to your palate, but sitting in the lab after class on day four, as I watched Valerian roast coffee for the next few days of classes, I realized that I had experienced a deeper paradigm shift.

It reminded me of when I saw people learn computer programming for the first time. On the surface, writing code looks similar to the way we humans teach and instruct each other to do things: if this is true, then do that. We talk this way all the time. But when you start to write code, you realize that computers work in a much more rigid, much more literal way. They don't assume things because they don't have a model of the world besides what some programmer has explicitly spelled out for them. They can't generalize, and they don't handle edge cases that are "close enough", because they don't know what "close enough" means until you tell them. (Machine learning and LLMs like ChatGPT are changing some of these assumptions, but let's set that aside for now.)

Many of the first-time learners I've seen go through this journey where at first it seems to make sense ("If the number is even, then do this thing."), then they hit the point where the abstraction breaks down and they need to express concepts in the computer's terms instead of in the human terms they're used to ("What do you mean I have to define what 'even' means? Isn't that obvious?"). Then, they struggle for a bit as they learn the structure of how a computer "thinks" and the basic building blocks they have to express their logic ("An even number is a number that can be divided by two with no remainder. We can use the modulus operator to do this test."). Finally, there's a moment when something shifts and you can see that they've internalized the structure and limitations of computer programs, and they're no longer trying to bend the syntax of a programming language to match their human experience of reality, but engaging the computer on its own terms.

It's the moment where they go from "this makes no sense" to "this is hard, but I can do this". It's a hopeful and intimidating moment: like you can hear the machinery inside their head shear, rotate, tumble a bit, and finally settle somewhere a bit lower to the ground but much more stable than the cliff they were holding on to. It's both the moment where they realize "my experience instructing other humans isn't going to help me program computers", but also the moment when they realize the monumental power of what they've just unlocked: even though the primitives are simple and it feels like you're sitting on the ground playing with Lincoln Logs, you truly believe that you will be able to apply powerful concepts to these primitive building blocks over and over again until you've built a skyscraper.

That's how I felt after I started to internalize what I was learning about flavor. Generally speaking, it's not a matter of hardware: to paraphrase the Flavor book, if you can taste the difference between a blueberry and a raspberry, you have what it takes to taste the notes in coffee. It just takes practice and an awareness of what to look for and how to build your memory of aromas. Some people might do this innately, but others (like me) need some coaching and coaxing to start down this path. It requires familiarizing yourself with your instruments and discovering how your senses respond to different tastes and smells. It helps to explore how the way you experience something differs from how someone else experiences it. Sometimes, you have to commit to looking ridiculous and putting your nose to your plate of food or some fresh fruit in the produce aisle. For me, it means being conscientious of what conditions my body needs to taste and smell, and being intentional about stopping to taste and smell everything I encounter–coffee or otherwise.

Further Reading

Flavor: The Science of Our Most Neglected Sense

A journey into the surprising science behind our flavor senses. Can you describe how the flavor of halibut differs from that of red snapper? How the taste of a Fuji apple differs from a Spartan? For most of us, this is a difficult task: flavor remains a vague, undeveloped concept that we don’t know…

Google Books

Flavor: The Science of Our Most Neglected Sense by Bob Holmes, has a bunch more info on how we perceive flavor. Valerian recommended it in class, and there's a bunch of the cool tidbits in here (e.g. did you know that you have taste buds in your lungs and intestines?).

I consumed it as an audiobook, and it was a fun listen. The content in it is about flavor generally, and he tells stories about coffee, wine, whisky, tomatoes, hot peppers, and other foods to illuminate his (rather scientific) exploration into flavor. Coming out of the book, I'm even more convinced that flavor is something we invent in our brains. He lays out some of the concepts I mentioned in this post early on in much greater technical detail, but then goes on to explore how other factors besides smell, taste, and mouthfeel can affect our perception of flavor. Things like placebos and expectations (e.g. people don't show a preference for organic produce in a blind taste test, but may genuinely perceive it to taste better when they know that it's organic), how aromatics can trick our brain into thinking something is sweeter than it actually is, and so on. Definitely a fun book to nerd out on.

Sip’n’ Slurp: A Guide to Expert Coffee Tasting | Freda Yuan Offical

About Sip ‘n’ Slurp: A Guide to Coffee Expert Tasting Sip ‘n’ Slurp is the first self-published coffee sensory book by Freda Yuan. This book provides unique insight into using tasting coffee to embrace life and find a sense of joy in the pleasure of drinking coffee. Inspired by the author’s own per…

Freda Yuan Offical

Sip'n' Slurp by Freda Yuan, is about how to taste coffee. It briefly covers her journey of how she immigrated from Taiwan to London, dealt with her insecurities and mental health issues, and became a competition winning cupper (professional coffee taster). The majority of the book is about how to perceive flavor generally. A lot of what she said lined up with what I learned in SCA Sensory as well as what was said in the Flavor book, but she presents it in a concise way accompanied by very stylish photos that look straight out of Instagram. She also includes some exercises for familiarizing yourself with your sensory instruments, examples of words you can use to describe a coffee's flavor and mouthfeel, and some techniques she uses to visualize a coffee when she tastes it. It's a quick read and clearly a very personal project, and I think it's worth picking up.

It's Wednesday, the first day of the SCA Sensory Intermediate course.

Let's talk about papillae some other time because today it's getting too late for me to properly review them and do a writeup. I was promised I'd get to lick paper tomorrow to see how bad it tastes, and somehow I'm looking forward to that. Even though our class today was the first day of the SCA Sensory Intermediate module, it felt like a continuation of the things we started learning yesterday in SCA Sensory Foundations. Yesterday, we examined how to use the SCA flavor wheel as an aide for describing flavors, and today we spent most of the lecture segment talking about how to score coffees on the SCA cupping form.

A Bit More About Sensory Analysis

If you're not calibrated, you won't provide objective measurements.

There are four steps:

1. Evoke: design experiments to best evaluate a sensory experience
2. Measure: Collect data, e.g. using a scoring sheet or digital tools like Tastify
3. Analyze: Use statistical methods to analyze the results
4. Interpret: Understand your results in the context of decisions to be made

Review: What Is Cupping?

Cupping is a procedure for evaluating the attributes of a coffee while controlling as many variables as possible. This is where sensory analysis meets practical applications in the production, roasting, and brewing of coffee. The form of cupping we use in this class (and for the Q) follows the SCA Cupping Protocol, which is designed to evaluate the potential of a sample of green coffee by keeping the roasting and brewing methods constant to reduce their impact. It's a very prescriptive protocol that's meant to give each coffee a fair shot at evaluation since the results of cupping determine a coffee's quality score and, indirectly, price.

You can check out the SCA's website for the exact details, or you can watch some of these YouTube videos to get the gist of it:

What Cupping Is And Is Not

The course highlights the important role that cupping has for buyers of green coffee specifically:

• It was originally created solely to detect defects in shipments of coffee, but has expanded to include identifying and describing positive qualities of a coffee.
• It facilitates communications between buyers and sellers about the quality and value of a lot of coffee.
• It allows buyers to evaluate the coffee they receive against contract agreements and mitigate rejections.

The Setup for Cupping

When cupping coffees, we need to assess both quality and uniformity. Therefore, we need to taste multiple examples of the same coffee in order to evaluate whether it is consistent and free of defects. In order to do this, we brew each coffee (called a "sample") five times in parallel. Each of these is one cup, and there are five cups per sample (which, again, is one coffee). If multiple coffees are being cupped, then there are five times as many cups of brewed coffee being evaluated. For example, if there are six coffees being cupped, that means we have six "samples". Each sample has five cups, so we will brew and evaluate 30 cups of coffee total. As you can imagine, you have to be pretty fast to do this before the coffee cools down and its flavor changes.

It can be handy to put all five cups in a sample on a tray with labels designating each cup from 1 to 5. This is important because if a sample contains a defect, the cuppers need to note which specific cups they found the defect in.

• Everyone shares all of the trays. They are not individual.
• It's not 1 cup per person. Everyone must try every cup.
• All of the cups on the tray (e.g. in the sample) are of the same coffee. They are supposed to taste identical, but they might not if there are uniformity issues.

This tripped me up at first, and I noticed it confused some folks in the class too. Here's an infographic showing how the 5 cups in a sample are arranged in an "M" shaped formation.

Here's a wider shot of the cupping table from the image at the top of this post. There are six samples on the table. Each sample is on a tray that's arranged like the graphic above.

The Results of Cupping (Other Than The Score)

The Scores

• Coffee is scored on a 100 point scale.
• The bar for specialty coffee is 80+ points.
• A coffee's score only counts if it's determined by at least 2 independent Q graders.

There are ten categories, each worth ten points. They are broken down as follows:

An 80 point coffee might be inoffensive (it "tastes like coffee") but lack unique flavors that make it more special than most other coffees. It might be improved with some cream and sugar. It's probably not too memorable. Its main flavors are probably those most common to coffee: chocolate, caramel, nutty, etc.

An 84 point coffee has a story to tell. It's the kind of coffee that has "notes", and you probably won't have to work that hard to find them. Maybe it has a bit of sweetness and dark fruit notes. Maybe it's exceptionally chocolatey with a good body and hints of spice. There are many different flavor profiles that a coffee could have to score in this range. If you've had a solid pour-over from a specialty cafe, it's probably at least this good. Assuming it has a flavor profile that's suitable for espresso, you could use it as the base for a small milk drink where the coffee's flavor shows through to bring something extra to the cup that elevates it above a good quality non-specialty coffee.

An 88 point coffee is exceptional. Expect something that's both coherent (notes are clear and play well with each other) and complex. It makes you think "how can coffee taste like this?" It smells good, it tastes good, and it takes you on a journey that you remember when you're done. It likely exhibits rarer notes like florals and complex fruits in a way that blends sweetness with a pleasing acidity. Often, the notes are more specific and strongly evoke a particular, refined flavor (e.g. instead of tasting like "black tea" it has notes of "milk oolong", or instead of "citrus-like", it's "mandarin orange" or "yuzu", and instead of "floral" it's "jasmine and honeysuckle"). You'd probably want to drink this coffee brewed fresh without adding anything to it (unless you really know what you're doing).

A 90+ point coffee will almost certainly be one of the best coffees you've ever tasted in your life.

It's been really eye opening to encounter so many coffees of varying origins and qualities. I feel like I have a better reference now for what great (and terrible) coffee tastes like, and it helps me contextualize what I'm experiencing when I try a new coffee for the first time.