Samantha John

Are you Elon Musk or a garbage truck titan?

2024-04-11T09:57:00+00:00

Ideas may be free, but coming up with an actually good one is not so easy. Here are some categories that can help you to organize the idea space and zero in on your next business.

The Passion Project

Be the change you want to see in the world: this is the most comon place to start when ideating your new business. Passion projects are ideas that come from the problems you’ve experienced personally and are issues that you’re fired up to to solve. Hopscotch was that type of idea. I was mad that I never discovered programming as a kid and set out to make something that would have inspired 10-year-old me. The good thing is that if you work on a problem that you care about, you’re more likely to stick to it. The flip side is that you may stick to this startup for far too long even if it turns out to not be a great business.

The Remix

What did people once spend time and money on that they no longer do? I saw a tweet recently about how, with the rise of streaming, gifting music is no longer a thing. It’s true. Nobody has given me a CD since high school. If you’re a 90’s kid you resonate. Human nature doesn’t change; you can make money finding a way to bring back behaviors that have been lost in the digital transformation. There are lots of industries that have been decimated by the internet, but maybe you can restore what was lost in a new form.

The Boring Problem

Waste management is a big business. Driving a garbage truck is super profitable because nobody wants to do it. You can and should charge a premium for wading into the smelly muck that everyone wants to avoid.

These ideas come from the boring problems that nobody is excited to work on. They tend to be under-developed because they are nobody’s passion. Vanta is one of my favorites in this space. SOC2 compliance is a burden that many companies face and nobody wants to deal with. And it turns out, people will pay a lot of money for you to solve it for them.

The Elon Musk

Read some science fiction novels. Choose your favorite features from the futuristic world. Then find an engineer who’s willing to try and build it. Some large categories that fit well here: human body augmentation, unexpected sources of energy, and novel ways to move from point A to point B. These types of ideas will require a lot of capital. If you succeed, you will be hailed as a visionary. Until then, most people will think you’re an idiot.

The AGI

Ask Chat GPT to come up with an idea for you; then ask it to execute as well. Profit.

The product doc that powered Hopscotch

2024-04-04T16:15:00+00:00

At Hopscotch we were rigorous with our product. We had to be. A small team, and over 10 years of features meant that the product could easily become bloated and confusing—the opposite of our goal.

How did we keep shipping a great product over such a long time period? We developed a process based on the scientific method. Any project, whether it be a community initiative, a new feature in Hopscotch, or changing the way something worked, had to begin with a product doc that included a hypothesis, success metrics, and a plan for failure.

Answering the questions in the doc helped us approach each change in the spirit of inquiry. It made the project an experiment, not an improvement, until proven otherwise.

The Product Document

Project name

It’s nice to have a fun codename for your project, but you also want something descriptive, maybe as the subtitle. A real example was “WavingCoffeeCake: Account Creation Optimization”.

Overview

The overview is a summary of your changes. It’s analogous to the abstract of a scientific paper. You might write this last, but it’s useful to put first for the readers (who might be you three months in the future). We would come back and add to this part a few weeks later to add the experiment’s results as well.

Company goal

This is where we started writing the actual document. It’s important to ensure that you are always working towards your company’s big goal. The easiest way to do this is to refer back to it constantly. Having it be the first thing in the product doc makes sure that all the other goals support this.

The next three sections are related, and are usually the most challenging part to get right. We’d often go through many iterations and discussions to get to something we liked.

Hypothesis

The hypothesis always had the format: If we take X action/build Y feature etc. Then some good things will happen to the company. Stating these expectations up front keeps you honest. If you start going on side quests or building things that deviate from your hypothesis, your team is going to know and call you out. A couple of examples:

If we improve the account creation flow Then more people will get through the onboarding process to make their first project.

If we limit the number of hashtags you can add Then there will be more distinct and relevant projects under each hashtag.

Success State

The success criteria is probably the single most difficult section. I hate trying to figure this out. It breaks your brain because you don’t know yet what your numbers will be, so how can you predict them? But if you don’t define your success criteria before you ship the feature and start getting data, you will inevitably find one metric that has changed for the better and call that success. You need to be realistic with yourself about what metrics would actually convince you that you’re moving the product toward its goals and aim for those. Giving a time frame and using numbers is important. Example: After three weeks, there will be 30% more plays per project for each hashtag for that week than there were in the weeks before the feature was released.

Plan for Failure

The success state tells you what metrics you want to hit, the failure state tells you what to do if you don’t hit those metrics. I like to list out the ways we could fail and what we will do in those specific cases. Do you try again and do something else to hit those metrics? Do you roll back the changes? Maybe you just move on and let everything be. It’s your choice what to do, but making a plan for failure forces you to be deliberate about your changes and make sure you don’t overload your product with a million features that didn’t work. It also makes the failure much easier to handle. At least now you have a gameplan!

Iteration and design

This is the thing you will actually do. It doesn’t have to be highly detailed and specified here, though of course, it does need to be highly specified somewhere (probably your project tracker). I often use this section to write out in prose what we’ll do before transferring it to my project management tool. It’s also nice to put images from your design file if you have one. The goal is that someone reading this doc has a high-level overview of what you’re doing. And pictures are always nice.

Background

This is analogous to the references section of a scientific paper. It’s the research you’ve done to figure out the answers to all the questions above. Think data, graphs, links to your analytics, etc.

Conclusion

And there you have it. The Hopscotch Certified Product Doc. We’ve used this for years at Hopscotch, and I’ve started implementing it for my consulting clients as well with a lot of success. I would love to see more teams adopt a scientific process for their product development, so please reach out if you have any questions about how this could work for you!

Lastly, if all this has made you curious about Hopscotch check it out for web, iPad and iPhone here.

A love letter to personal software

2021-09-07T08:28:00+00:00

I’ve been using a screenshotting tool called Annotate (and its predecessor, Glui) for almost ten years.

It’s much better than the built-in mac screenshot software. I can keep multiple screenshots available to drag wherever I want. And it has the perfect selection of the markup tools I need with none that I don’t.

A typical set of screenshots I keep around. Note: it’s kind of hard to take a screenshot of your screenshotting tool.

But the latest OS update broke blur, one of my favorite tools. I searched for an update and realized Annotate is no longer available.

The company that made Annotate, Drift, has pivoted. They’re a very successful B2B startup that recently achieved unicorn status. They’re great product designers. I’m sure their software is helping sales and marketing teams deliver smooth experiences to their customers.

But, as a user of Annotate in particular and software in general, the demise of this small productivity tool saddens me.

The market for making corporations’ computer experiences more productive is thriving. But what about me as a human? Someone made a tool that made my and countless others’ computing experience better and more efficient. Now that tool and UI live on only as legacy software but cannot be installed anew.

How can we expect to make progress in computing when innovations are so easily lost? Most of human history is a story of tools getting better, faster, and easier to use. But software doesn’t feel that way to me.

Yesterday, I edited a large pull request on Github that slowed my browser to a crawl. My 2018 model computer has barely an hour of battery life. My text editor doesn’t know that a close parenthesis is my most important word delimiter when coding.

These feel like small gripes, but they add up to a mental tax that I wish I didn’t have to pay.

I wish we measured and optimized human happiness and productivity. And that we rewarded tools that put humans first and corporations second. Maybe then small but valuable software wouldn’t be lost. And I would have a sense of delight rather than dread when I opened my laptop.

Churcha Chironja

2021-07-28T11:26:00+00:00

During the pandemic of 2020, we all got some weird hobbies. Some of us learned how to bake bread. Others discovered a foreign language.

I took strange hobbies to another level by starting a “church.”

Starting a church sounds crazy, but it’s been an incredibly impactful experience that I want to share.

Churcha Chironja is a practice where you, your friends, and your community come together in a secular setting to ask and ponder questions that are usually the province of religion. You step back from your day-to-day problems and think longer-term and bigger picture. At its best, the church is a magic seed that grows into deep connections with strangers and friends alike.

How it works

Every Sunday, we gather over a meal followed by a “sermon,” a short talk about a life topic that has challenged the speaker. Personal stories are encouraged. Then we have a conversation where folks react to the sermon and share their own stories on the same theme. We end with a poem that we co-create.

A typical Sunday night in Puerto Rico

The meal: The meals have ranged from quick leftover stir-fries to elaborate pasta-making endeavors. We were lucky to have a large kitchen. The joy of banding together to roll out six pounds of pasta with water bottles was matched only by the daunting task of cleaning all that flour from the crevices of the kitchen. The logistics of large group meal preparation was a challenge and delight. Much pasta was made and eaten. We had to get creative finding the right surface to dry it on.

The sermon: Every week, someone new would give the sermon. The best ones brought in a question centered around stories from the speaker’s life. Usually, the sermon is a talk, but in a memorable “sermon,” the speaker played songs (post-vaccination). Afterward, some of us ended up sitting on the porch singing along to karaoke favorites. Another night, a usually light-hearted friend talked about losing his father to Alzheimer’s. His sermon sparked a conversation about the unreliability of memory. One person had multiple sources disagreeing on whether or not she had a pet donkey as a child!

The conversation: After the sermon, folks would share their reactions and experiences. Sometimes it took a while for the first person to speak as everyone digested what they had just heard. The best comments were personal, specific, and humble. Less good ones were treatises on philosophy or stories where the speaker was the hero. As we refined the practice, we started sharing guidelines to move the conversation in the direction we wanted. And it worked. (See below for a guide to church).

The ending poem: Because every good event needs a good ending, we end church with a poem. The speaker starts with the first word, and then the poem travels around the circle, with each person adding one word or punctuation mark. We read the entire poem out loud and send it out to the group as a souvenir.

Existence supports all of the quandries that we share.

How it started

In November, after dealing with lockdown alone in NYC, I decided to move to a community house in Puerto Rico. We had seven bedrooms and tons of amazing people. I was meeting new friends all the time, but I wasn’t learning about their essence or making as deep of connections as I wanted.

One Sunday, as Wren and I waited in line for Costco to open, I broached the idea of doing a community version of church minus the God aspect. We began brainstorming enthusiastically. Our community was already close. It was just a matter of inviting them over for Sunday dinner and sneaking in a sermon. Wren led the first one, kicking off the invite with this note:

At Casa Chironja House dinner tonight, inspired by Samantha, I’ll be delivering a short agnostic Sunday Sermon on Anna Karenina. We’re experimenting with the format with the hope of continuing at waterfalls on future Sundays :). No prior knowledge of Tolstoy required!

She spoke about her journey from religion to philosophy. We followed up with a conversation about our own religious experiences and how they had led us to that day. It was one of the best conversations I’d had since arriving nearly a month before.

We continued church each week and had some wonderful conversations with smaller groups of 4-5 people. It was easy to be vulnerable, and our friendships deepened.

Growing

As we continued the tradition, challenges began to arise. Each week a new person would present the sermon, and some topics worked better than others. People began including PowerPoints. And while their talks were interesting, they felt more informational than spiritual.

And the group began to grow. We began to have 10, 15, or even 25 people. One week a former governor of Puerto Rico gave the sermon. The challenges began to mount. With so many people, you didn’t feel as secure and close to everyone. The temptation to show off your smarts would arise while being vulnerable felt farther away. And it was challenging to get that many people to sit still and listen!

What worked

To get people to focus on the sermon, we separated it from the meal, both in space and time. Before starting, we would finish dinner and rearrange the seating area so that folks could put their energy and attention towards the sermon.

To improve the sermons, we wrote guidelines for the speakers. Powerpoints were banned. Sermons questioning rather than teaching were better (and had the advantage of being easier to do). Having a text was not necessary. Starting with a personal struggle rather than a book led to more authentic and honest sermons.

We gave more structure to the conversation. We’d begin with a short history of churcha chironja so that folks could understand why they were there. And we added conversational guidelines to keep it from veering into a philosophy club or humblebrag session.

At their best, the sermons taught us things about ourselves and each other. Sometimes in small and unexpected ways.

One Sunday, I bonded with a newcomer over our hate for food waste and willingness to eat questionable leftovers rather than throw them out. In another, I had a realization that rearranging furniture, even just a little, is the first step to my feeling at home in a place. A friend felt incredibly uncomfortable during the musical sermon but was inspired to write her own songs by the end of it. I loved how we got something different and surprising from church each week.

What the future holds

This July, I left my community in Puerto Rico. As the world opened up, I had to attend to some travel and family commitments that I could no longer ignore. But the church lives on. It turns out I was not the most critical ingredient to its success. Others have taken over the Puerto Rico branch, and the sermons are going strong.

Even better, Church is something that can live in many places. A friend began their own tradition at the Radish in Oakland. And I’ve joined or hosted Sunday sermons in New York, Boston, and Palo Alto. I plan to continue the tradition with whatever community I find in my travels. While I miss my Puerto Rican home, I am excited to bring in new friends to the practice and see my friends who have left the island do the same.

Post Script: How to run a church

Hosting: We’ve successfully run Churcha Chironja with up to 25 people, but if it’s your first time hosting, six or fewer will be much easier to manage. In Puerto Rico, we would invite people over to help cook at 6, plan to eat at 7, and start the sermon at 8. We’d usually wrap up by 9:30. If you’re not much of a cook ordering food or doing a potluck is a very reasonable option! Everyone sitting at a table to eat isn’t super important, but make sure you have a comfy, non-dinner-table spot to do the actual sermon. Note: I’ve always done church as a dinner event, but a daytime event would probably work just as well.

Choosing the speaker: The host does not have to give the sermon. When choosing a speaker, optimize for someone comfortable being vulnerable and going deep in conversation. In our experience, this was more important than public speaking skills.

Here’s a guide you can send the speaker:

Thank you for giving the sermon! A Chironja church sermon is a short talk about a life topic that is meaningful to you. You can bring in a text, but the most important part is to bring in a personal story about why this matters to YOU. A good topic will inspire others to be vulnerable and share their stories too.

The sermon can be as short as 5 minutes and as long as 15. But if you feel confident that you have something great to say, break the rules and talk longer! After the sermon, we’ll have a conversation. Keep in mind that the conversation, not the sermon, is often the essential part of the evening. Hopefully not needing to be the star of the show takes off the pressure.

Starting church: After the meal, make sure everyone moves to a new location. If needed, you can just move the chairs to a new spot. Ideally, there should not be a table in the middle, and you should be out of the meal context. If you’ve brought dessert, now is the time to serve it. People can eat on their laps during the sermon.

Introducing the speaker and event: The host should introduce the speaker and church. Here’s a sample script:

Welcome to church. For those of you who are new, this is not a typical church, we aren’t going to worship any gods, and we’re not going to give you all the answers. Instead, we’ll take some time to ponder life’s mysteries and talk through our challenges together. We’ll start with a short sermon, followed by a conversation. Then we’ll conclude the evening with the closing ceremony. Here are some guidelines for the conversation:

Concrete stories are better than abstract facts or theories. The goal is not to share platitudes but rather to bring your whole life and experience to the table so that others can learn from it. Tell the story and let people come to the philosophy themselves.

Keep your stories personal. Your friend’s struggle is less interesting than your own. If everyone follows this rule, you’ll leave knowing something new about the people here and even more about yourself.

Be humble. This conversation isn’t about things you think you’ve figured out. Remember, the more awesome you sound, the harder it is for others to share their own challenging moments.

Concluding: Once everyone has had a chance to talk, or if it’s getting late, start to wrap up the conversation. Ask if anyone who hasn’t spoken wants to say anything. Once that’s done, move on to the closing ritual, the poem. Find a scribe who will write down the poem as it is created.

Here’s a sample script for introducing the poem:

We are going to close with a poem in which each person says one word or punctuation mark. The speaker will start and they choose whether to go clockwise or counterclockwise. When we get to the last person, we’ll read the poem and send it to the group. Some people find this part stressful. If you don’t know what to say, use a short, concrete word. Remember, the poem can’t be bad. Weird, definitely, but never bad.

When the poem is complete, the scribe will read it aloud. Sometimes we’ll play a gong sound to conclude. Then everyone can disperse, help clean up or continue the conversation more informally. Congratulations, you’ve just run your first Chironja church!

Fixing your retain cycles for fun and profit

2019-01-29T06:53:00+00:00

I’m spending this week and next at Apple Entrepreneur Camp. It’s a fantastic opportunity to learn from Apple engineers. So far, it’s been WWDC on steroids. The least I can do is to spread some of the knowledge I’ve gotten.

Retain Cycles in Arrays

When you have two objects that have a reference to one another, you become in danger of creating a strong reference cycle. It’s easy to mitigate: in Swift, you would make one of the references either weak or unowned. In Objective-C, you would make one of the references weak.

But, what happens if both objects have a reference to one another through an array?

Here’s an example in Hopscotch:

HSControl refers to any block that wraps around another block.
HSScript refers to a list of blocks inside an HSControl or a rainbow block such as “Spin”.
HSControl can have multiple HSScripts as you see in the check once if/else block.
HSScript also needs a reference to a list of parent HSControls. So both HSScript and HSControl require a reference to an array of the other.

You can’t have an array of weak or unowned references so it may seem that we are doomed to a strong reference cycle. Never fear! There is a solution, both for Swift and Objective-C.

Objective-C

There’s a little known (to me) class called NSPointerArray. It can hold nil values and therefore can accept weak pointers. If you switch your NSArray to an NSPointerArray, you can solve your reference problems.

Note that you need to bridge your object to add it to the pointer array. In Xcode 10, I was able to use a fixit to get this syntax.

@implementation HSControl
@synthesize _scripts;
- (NSPointerArray *)scripts
{
	if (_scripts) { return _scripts; }

	HSScript *script = [[HSScript alloc] init];
	script.controls = @[self];
	_scripts = [NSPointerArray weakObjectsPointerArray];
	[_scripts addPointer:(__bridge void * _Nullable)(script)];
	return _scripts;
}

- (void)setScripts:(NSPointerArray *)scripts
{
	_scripts = [NSPointerArray weakObjectsPointerArray];
	for (HSScript *script in scripts) {
		[_scripts addPointer:(__bridge void * _Nullable)(script)];
		script.controls = [script.controls arrayByAddingObject:self];
	}
}

@end

Swift

In the Hopscotch code, one side of the retain cycle was in an Objective-C class (HSControl) and the other side in a Swift class, HSScript. We decided to look for a fix in Swift as well so we could explore solutions from both sides.

So how do you create a weakly referenced list in Swift? One option is to use an NSPointerArray. However, this requires that the items in the array be of type UnsafeMutableRawPointer. Yuck. Anytime I see a class called Unsafe I try to stay away.

A better solution is to wrap your object in a struct with an unowned reference.

@objc public class HSScript : NSObject {
  @objc public var controls: [HSControl] {
    set {
      self.unownedControls = newValue.map { UnownedControl(control: $0) }
    }
     get {
      return self.unownedControls.compactMap { $0.control }
    }
  }

  private var unownedControls: [UnownedControl] = []

  private struct UnownedControl {
    unowned let control: HSControl
  }
}

In this instance, we create a private struct that keeps a reference to the HSControl. It’s the same principle as creating an array of pointers, just this time we made the pointers ourselves.

Conclusion

A many-to-many reference cycle may seem like a rare occurrence, but if it does happen, now you know what to do. Use this as an excuse to run the Leaks tool in instruments and see what you have. Even if you are not experiencing this memory leak, I hope you enjoyed learning about a new class and a new design pattern. You never know when they may come in handy.

Lastly, if you were intrigued by that snippet of Hopscotch code, we’re hiring!

The Tao Te Ching

2018-03-12T20:53:00+00:00

I found this Ursula Le Guin translation of the Tao Te Ching on the bookshelf at an airbnb. I liked it so much that I bought my own copy.

There are a lot of best parts. One is that Le Guin doesn’t even speak Chinese! I also love how perfectly it captures the essence of the negative.

Where the pot’s not // is where it’s useful.

Thoughts on mastery in programming

2018-02-11T13:11:00+00:00

I recently met Ivan, a high schooler who is interested in both programming and self-improvement — two of my favorite topics. He taught himself to program and created several iPhone apps. He wanted to improve his programming skills but was feeling stuck. He eagerly listed the technologies he had mastered, but wasn’t sure what he should tackle next.

He also asked question that I’ve heard many times before: Is it better to go in depth on one programming language or learn a whole bunch of them? I wasn’t very articulate in answering him then, but the question stuck in my mind. Here’s what I wish I’d said.

The sure sign of a beginner programmer is that you measure progress in quantity of frameworks, technologies and APIs learned. You’re always wondering which stack to learn next. At this stage, you get stuck as you continually learn new things but their utility remains unclear.

The next step is when you focus on one programming language and grok it deeply. You’re informed about the choices and tradeoffs the designer made. You know what abstractions you can use. You also understand how the language patterns influence the form and type of programs you write. Now you’re ready to build a career in software.

An expert, however, must circle back to the novice’s quest. You find new theories, languages and frameworks, and incorporate them into your worldview. This time, armed with a depth of knowledge, you compare and contrast different ways of accomplishing your goals. You gain an arsenal of tools for thinking. You can change your frame of reference to find simple solutions to old questions and discover new classes of problems altogether.

The great thing is, you can replace “programming” above with any field and it still holds. In his Nobel Prize speech, Richard Feynman discusses the importance of knowing many different perspectives. Some of his greatest contributions to science came when he used the math from one area of physics to drastically simplify problems in another. In the words of Alan Kay:

“A change of perspective is worth 80 IQ points.” I’m going to send this to Ivan, but I hope this will be useful to others as well. To achieve proficiency you need to learn one way of thinking well. True expertise comes when you can view your field from multiple angles. It’s easier said than done. Good luck Ivan!

My mom, the scientist

2013-05-01T13:48:00+00:00

When we were kids, my brother and I knew that our mom was the scientist of the family. She had finished the better part of a PhD in chemistry before deciding to become a doctor. She also the one who knew how to fix things. From busted remotes to leaky faucets to putting together new toys, she always had the solution.

My favorite story about my mom is a family legend. When she was 12 she left China to immigrate to Hong Kong with her mother. At the border the officer informed her that my mom was too old to leave China without a visa. Thinking quickly, my grandmother said: “Oh, she’s actually still 11, her birthday’s next month and we just call her 12 because she’s so close.” That was how my mom left China and got to have two birthdays.

I grew up thinking that mothers were good at math and science. They had to be clever and think on their feet. They held high powered jobs to support their families. That has been a huge influence on me throughout my life–I knew that I had to be all of these things so that I could be like my mom.

At my company Hopscotch we spend a lot of time thinking about how to get more girls interested in STEM fields. Part of the problem is a lack of female role models in these disciplines. First at engineering school and later while working as a programmer I found myself in a predominantly male landscape. For most kids, the scientist parent is their father. I realize now how lucky I was to have my mother as a role model.