Watch a few episodes of Anthony Bourdain’s Parts Unknown, and you’ll notice a pattern: the master chefs care more about the ingredients than the recipes.

Masa Takayama, the legendary Japanese sushi chef, spent years apprenticing in Tokyo. The first two were spent wiping toilets, washing dishes, and cleaning fish. Only in his third year was he trusted with the rice. Eventually, he sliced fish and prepared nigiri. He respected the rice and fish so much that he was willing to spend seven years learning how to combine them well.

Another sushi master, Naomichi Yasuda, has spent nearly three decades running one of New York’s best sushi bars. Yet he still has a reverence for simple, quality ingredients. When Bourdain asks what the most important part of his cooking is, he says the rice.

BOURDAIN: Which is more important, the rice or the fish? Or what percentage? Rice. More important?

YASUDA: About 90 percent.

BOURDAIN: Wow.

YASUDA: Fish is the second ingredient. The main ingredient is rice. So my sushi is rice.

Even Masa’s mother understands the primacy of ingredients. When Bourdain visits, she sets out a pile of uni and fatty tuna brought up from that morning. She serves it plain, without attempting to cut it as masterfully as her son might. “This is better than Masa’s sushi,” she jokes. Masa smiles and concedes that she might be right.

We consumers instinctively value the ingredients more than the chef, too. It’s why sushi itself is internationally beloved; #sushi was the most popular dish on IG in 2021, appearing in over 3.2 million posts. A well-prepared, two-ingredient dish satisfies eyes and bellies better than a complicated one that tastes as if a committee made it.

Good ingredients are enough. The chef’s job is to let them be.

If software engineers are digital chefs, what are our ingredients?

Data.

All we do is show users data and help them change it. It’s not about algorithms, architecture, models, features, or P90 metrics. It’s the data, silly.

Rich Hickey understood this. He became so sick of complex programs that he quit his job and created Clojure. Instead of tempting devs to obsess about class hierarchies or frameworks, the language helps them work with the data directly by limiting itself to a handful of simple structures: maps, vectors, lists, and sets. Rich proved how powerful this simple language could be by building a successful database company upon it. A few basic building blocks, masterfully combined. Rice and fish.

I think about how beautiful Rich’s old approach is every time a new startup sends me a changelog that reads like a Walgreens receipt. New dashboard! New integrations! New collaboration features! New mobile app! New settings for the settings!

They’re shipping, all right. But for whom?

Nobody opens a calendar to admire its architecture. They want to see what’s happening this week. Nobody opens a notes app to celebrate its block editor. They want to remember something. Nobody opens a budgeting app because they’re excited about its AI integration. They want to know where their money went.

These are simple needs. But instead of getting better at meeting them, we keep adding more features, more configuration, and more complexity. Somewhere along the way, we confuse improving the software with increasing the amount of software.

Those sushi masters remind me that mastery doesn’t mean addition. Sometimes it means spending years getting better at using what we already have.

Maybe we software engineers should take the hint.

Get the data.

Present it clearly.

Make it easy to change.

Then get out of the way.

More

• Parts Unknown, Tokyo (hbomax.com)

• Rich Hickey Clojure documentary (clojure.org)

• My calendar app (compasscalendar.com)

You’ve probably mastered a craft by now — coding, shooting a basketball, lifting weights, playing cello, cooking sourdough, editing videos, writing short stories — and doing so required years of consistency while you learned the basics. Eventually, you got comfortable enough with the standard building blocks to add another layer: the advanced techniques. You started to impress your friends and peers, so you kept developing. More difficult shots, faster times, more ingredients, more configs.

Eventually, adding more started to feel draining. The more layers you added, the less you loved the craft. You yearned for those early days when you only knew a few chords, a few ingredients, or a few data structures, when you didn’t need a meeting or an SOP to make a change.

You still remembered the purity of those early days, how freeing it felt to just create. The yearning for the joy that came from within you then overpowered the validation you got from others now.

So you stopped going down the path of advancement and turned around to where you started — to the basics.

That turnaround was uncomfortable. The people who used to shower you with praise started to ignore you. Your retreat made those you passed on the way back question whether they, too, were on the wrong path. Unprepared to change, they quietly mocked you as you passed.

If you ignored them long enough, you finally got back to basics.

And it was awesome. You rediscovered the joy of your craft and its fundamentals. You felt like a kid again, but more mature and grateful. (Love on your first day of school feels like a rollercoaster. Love on your 20th anniversary feels like peace.)

You looked around and saw something surprising: the GOATs were there also, and they felt the same appreciation.

• Linus was writing a for loop in C

• MJ was working on his midrange

• Chris Bumstead was squatting

• Yo-Yo Ma was practicing scales

• Paul Hollywood was making a rustic loaf

• Hillier-Smith was exporting a video that has two tracks

• Hemingway was writing dialog at a third-grade reading level

In good spirits and company, you resolved to stay with the basics as long as possible, and to venture back down the path of advancement only if necessary

… in that one domain.

The trap is that, even after going through that journey and discovering the superiority of simplicity, we think it only pertains to that particular craft.

We’ll resist complexity with monastic discipline during our evenings, while welcoming it like a heathen during the workday. We’ll build a stable monolith for our lifelong side project while insisting on a sprawling microservice architecture for a skunkworks project at work. We’ll cook a five-ingredient salad for ourselves because it tastes great, but insist on a twenty-ingredient one when company is over because it looks great.

Simplicity isn’t relative. It’s not an advantage in one craft and a disadvantage in another. The superiority of simplicity is universal. I don’t have to convince you of that, just like I don’t have to convince you that gravity is real. Just jump, and you’ll see how futile it is to defy gravity. If you ever doubt whether the basics are enough, just make things complicated and see if you enjoy it. You’ll see how futile it is to defy the power of simplicity.

I can’t stop thinking about the middle of Proverbs 4, “A Father’s Wise Instruction”:

The beginning of wisdom is this: Get wisdom,

and whatever you get, get insight.

Leading up to this line, the father begs his sons to pay attention to what he’s about to say. After this line, the father implores his sons to appreciate wisdom and avoid wickedness.

The first time I read it, I got angry at its simplicity. “Get wisdom”? That’s it? That’s your special advice? “Get insight”? That’s the enduring message you’re going to leave your kids? How, though? How do I get wisdom and insight?

Imagine paying VIP tickets for an entrepreneur conference. You grab your front-row seat and pull out your notebook ahead of the keynote, The Secret to Financial Independence. Then all the speaker says is:

The beginning of wealth is this: Get wealth,

and whatever you get, get cash.

How do I get wealth? How do I build cash flow?

Countless books, courses, podcasts, and events answer those how questions.

• “How to Win With AI in 2026.”

• “How to Use Claude Fable To Build Your Own Software Factory to Print Cash.”

• “How to Automate a Faceless YouTube Channel Using AI.”

• “Father of AI Tells Developers How to Stay Relevant Before It’s Too Late.”

We’re a generation addicted to implementation details, to click-worthy headlines that promise the world, yet deliver nothing more than a 20-point hollow listicle divided by a banner ad. We’ve been running on the sugar high of a thousand Hows for so long that we forgot the sustenance of a few Whats.

Maybe that father was onto something after all.

His kids didn’t need a list to chaperone them from point A to point B. They were probably resourceful enough to get those things and smart enough to keep them. A nudge was all they needed, a reason to keep their gaze on the narrow path ahead of them and avoid the temptations in the periphery.

Wisdom.

Insight.

Wealth.

Cash.

Peace.

Gratitude.

Connection.

Autonomous Software Factory.

All worthy pursuits.

But let me suggest just one How, one timeless method that I believe will serve you.

Whatever you pursue, pursue it with simplicity.

I’ll never forget this bomb Jensen Huang dropped in 2023:

The leader of the most valuable company in the world isn’t stressed out about his schedule. As someone who built a calendar and frantically checked it, I felt attacked. Jensen has infinitely more demands on his time than I do, yet he’s the one who is present, while I’m skipping bathroom breaks so I can go to back-to-back meetings where we talk in circles for hours.

Then I found out that this wasn’t a one-time thing for Jensen. It’s not like he decided to be more chill that day after getting a good pumpkin spice latte. He’s usually this zen. Sarah Guo, who's worked closely with Jensen for years as an investor, was also caught off guard when she watched him hand-deliver Nvidia’s first DGX Station to Andrej Karpathy.

Huang stayed five hours, talking about the future, giving advice, and never looked at his phone once. Guo remembers looking at hers three or four times. “Jensen has this wisdom,” she told me, “that if you know what your priorities are and you’re working on the right one, you have all the time in the world. That’s something I aspire to.”

These ideas — that most stress is a choice, and that you don’t need to be in an endless state of hurry — will keep showing up if you look for them. It’s like seeing dozens of white Corollas on your commute the day after you buy your own.

Here are a few more examples that each rhyme with Jensen’s message.

• I’ve talked to a lot of recent retirees over the last few months. They all express regret about how much they stressed themselves out.

• Martha tattle-told on her sister to Jesus for leaving her to do all the work while hosting a gathering. Jesus replied: “Martha, Martha, you are anxious and troubled about many things, but one thing is necessary” (Luke 10).

• Buffet told his pilot to write down his top 25 career goals. Then he told him to circle the top 5 and avoid the bottom 20 at all costs.

The principle applies to software, of course. I’m sure you’ve been on a team that insists on shipping 10 new features at the same time. Maybe while watching the PM do timeline calculus to make that work, you thought, “Do users really need all this stuff?”

I’m sure you have your own list, examples of people who have somehow found success without carrying around a heavy aura.

How you react to those people says a lot about your own prioritization skills.

Does it infuriate you to think that someone could be successful yet chill? Does it feel wrong that some teams work 80-hour weeks, while others get more done in 30? Does Eskil Steenberg’s idea of finishing a software project feel blasphemous?

I’ve come to believe that the people who are unusually calm aren’t better at “managing” their time…they’re just better at deciding what deserves it.

Maybe we don’t need more time or more ways to count it.

Maybe we just need fewer priorities.

MORE

Jensen interview (acquire.fm)

Eskil talk (youtube.com)

Sarah Guo profile (colossus.com)

My calendar app (compasscalendar.com)

While their peers tolerate clumsiness under the guise of pragmatism, they’re prepared to jeopardize their whole careers to prove that it doesn’t have to be so complicated. They’ll bushwhack their way into the jungle of complexity so that they can prove to themselves that nature always provided a simple path through it.

DIRAC’S EXAMPLE

Let’s take Paul Dirac, the electrical engineer turned theoretical physicist who helped found quantum mechanics.

In 1926, Schrödinger pulled up with a quantum mechanics equation that explained the hydrogen atom and made chemistry computable. But it broke down for particles moving at the speed of light.

The obvious fix was to build relativity in, which the Klein-Gordon equation did. It was relativistic, but clumsy for electrons because it was second-order in time. Most physicists were willing to move on. Not Dirac.

“Most physicists were quite happy... but I was very unhappy about it.”
— Dirac, Basic Beliefs and Prejudices in Physics, 1976

Relativity put space and time on similar footing; why shouldn’t the relativistic quantum equation also be first-order in both?

So he spent two years figuring it out.

The breakthrough was to factor Einstein’s energy equation using matrices instead of ordinary numbers. The result was the Dirac equation:

Relativity was built in. The electron’s spin and antimatter emerged naturally. Dirac’s equation described the world more accurately with fewer assumptions. It wasn’t simpler in the naive sense, however. It introduced four-component wave functions and matrices instead of ordinary numbers, after all. But it was more beautiful.

THE TENSION OF SIMPLICITY

I love Dirac’s example because it resolves an inherent tension in my emerging religion of simplicity: In the pursuit of first-order simplicity, one has to accept second-order complexity.

For example, say you’re building an API. You make it simple; it covers 95% of use cases effortlessly. If your customers have a 5% use case, however, using your simple API will be painfully complex. (See my Google Calendar case study). Simplicity for one party often means complexity for another.

Dirac found a way out of this bind through addition, not subtraction. He added the requirement of mathematical beauty to the solution. The pursuit of beauty led him down a path that no one else was willing to take, one where the math was deeper, but the application wider.

We now see that we have to change the principle of simplicity into a principle of mathematical beauty. The research worker, in his efforts to express the fundamental laws of Nature in mathematical form, should strive mainly for mathematical beauty. He should still take simplicity into consideration in a subordinate way to beauty. (For example Einstein, in choosing a law of gravitation, took the simplest one compatible with his space-time continuum, and was successful.). It often happens that the requirements of simplicity and of beauty are the same, but where they clash the latter must take precedence.
— Dirac, The Relation between Mathematics and Physics, 1939

That commitment to beauty is why Dirac’s equation became a foundation of quantum field theory, earned him the Nobel Prize, and still has physicists making memes about it today.

WHAT’S THE POINT?

Whether you’re architecting your morning routine, a fleet of AI agents, or the new primitives of quantum mechanics, I think Dirac’s playbook applies:

1. You don’t have to tolerate complexity

2. Finding a simple yet acceptable alternative is hard

3. When stuck, add a requirement (e.g., beauty)

MORE

The Relation between Mathematics and Physics (Dirac’s transcript)

• Try brute-forcing the solution → No luck

• Go to StackOverflow → Nothing

• Find a 7-year old blog post from a guy named Dimitri → Helpful, but outdated

• Read the docs → Nothing

• Open an issue on the doc repo asking for clarification → Nothing

• Sit through an hour-long YouTube lecture from the maintainer hoping for a clue → Nothing

Eventually you came to the fateful conclusion:

It’s just me and this problem.

No one is coming to save me.

You went for a walk, considered joining a construction crew, remembered that time you hit your thumb with a hammer, and decided to stick to software. You returned ready to roll up your mental sleeves and do some work. The only thing that was going to get you out of this situation was thinking deeply, tearing the problem apart, and putting it back together differently.

I thought I hated this part of the job. It frustrated me to spend an entire week making no progress. I remember spending six days on a Redux problem. A week fighting with an Electron about file-permissions. Five weeks on a refactor.

That struggle is now the part I miss the most. I miss how those problems forced me to think deeply and slowly. They revealed the gap between my model of the world and reality. I had to seek out new information, to learn. I left scared that I’d fail and jeopardize my career. When I eventually returned with a solution, I felt empowered to tackle even harder ones. I was the hero who returned from a grueling adventure that tested me, and I won.

That mental journey doesn’t happen any more in non-frontier software.

Deep thought isn’t the bottleneck.

It’s QA, strategy, marketing.

If the software sucks, it probably doesn’t need deeper thought; it just needs more prompts.

My desire to keep thinking deeply has led me away from software recently. I’m reading math and physics papers. It’s a struggle. I’m not good enough to derive the answers myself. I don’t even know half the symbols they’re using. I feel fraudulent telling real scientists that I’m trying to read them. But it’s scratching that itch that I used to get while in the depths of a software problem. It’s making me think deeply, learn, and understand the world differently.

I’m not going to become a physicist. I’m not going to stop building software anytime soon, either. But I’m also not going to stop thinking deeply. If I can’t find a way to think deep while solving software problems, I’ll find other problems to ponder.

Building software was a bundle of activities, some of which really interested you.

• Understanding the interaction between bits and hardware

• Turning user feedback into improvements quickly

• Building something you could use on your own

• Thinking deeply

• Minimizing clicks, latency, CI build times

• And 100 other things

Now that the bundle has changed, I think this is a good time to identify what elements of it you care about the most. For me, it’s deep thought.

What is it for you?

» What’s element of building software is most important to you?

Answering that might help you get more clarity about your current role. It might inspire you to go into a new field entirely. Or it might just give you permission to stroll down a different section of the library and read something unfamiliar.

The job of building software has changed a lot, so why not take the time to revisit the JD?

[ MAIN IDEA ]

“Beauty is in the eye of the beholder,” they say.

Yet there are qualities that all beholders find beautiful, like symmetry and contrast.

Same with simplicity.

A truly simple idea or solution has these four properties.

1. Economic. Nothing extra. Every bit in a simple program plays a crucial role. Every dependency is weight-bearing. Every word moves the story forward.

2. Destructive. It eliminates unnecessary assumptions, abstractions, and lines of code.

3. Generative. It gives birth to new features and ways of understanding the world.

4. Deep. Simple ideas support long chains of logic. Simple apps allow for endless workflows.

Let’s look at some examples.

Shannon’s Information Theory

• Reduced communication to a few primitives: source, message, channel, noise, receiver, destination (economy).

• Threw out semantics. Whether a message was Shakespeare quote or a movie is irrelevant to the problem of transmitting it (destructive).

• Compression, error-correction, digital communication, storage theory, cryptography, networking were natural outcomes of the theory (generative).

• Defining “information” as a measure of certainty supports entire chains of reasoning about the limits of compression and communication (depth).

Unix pipes

• Programs read input, transform it, and emit output (economic)

• The graph doesn’t have to define every possible combination anymore (destructive)

• Composition can be achieved using just a few commands: grep, sort, awk, head (generative).

• Tiny utilities chained together can solve surprisingly sophisticated problems (depth)

Pure functions

• Outputs depend only on inputs (economic)

• No more hidden state or ordering assumptions (destructive)

• Easy testing, caching, parallelism, memoizing, composition (generative)

• You can reason locally about a function and then compose that reasoning as deep as you want (depth)

So, how do we apply this new understanding of simplicity to our own lives?

Here’s a simple, yet humbling exercise.

Instead of hunting for new problems, improve of your existing solutions.

Say you’ve built an app that syncs calendar state between Microsoft, Google, and your own data. Figure out a way to do that in a way that requires fewer services and dependencies, that makes it easy to sync state across n-providers (Apple, etc), and works independent of whether the data is a calendar event or a class note.

It’s humbling to see how difficult it is to simplify something that “works.”

It goes against our sensibilities to just keep moving fast.

But if you keep amassing unnecessary weight and complexity, it’s only a matter of time before you and your product becomes too bloated to move at all.

[ INSPO ]

Engineer History

Was Claude Shannon TOO Curious?

Claude’s curiosity is often praised…

Read more

a month ago · Tyler Dane

[ MAIN IDEA ]

Three years ago I was teaching web development at a bootcamp. ChatGPT was generating kludgey code and writing SQL. My students kept asking me questions that they could’ve easily gotten from ChatGPT during my lecture. After polling them, only about 10% of them had an account. I stopped the lecture to share my screen and ask ChatGPT the question they just asked me. They were amazed, and the rest of the class stopped paying attention to me as they created an account and played around with it.

Then I quit.

Shortly after, I made a YouTube video encouraging people to just open-source 95% of their code, arguing that code’s inherent value is going to plummet anyway. Some people agreed, some got offended. Either way, it happened.

I’m not always right about these things, but I’ve found that if you put in the work and read between the lines, you can’t help but build convictions.

After delegating daily coding to agents and 5Xing PR velocity the last few months, I have a new conviction.

Code won’t be a thing for long.

Sure, our sites and apps will run on code. Those who learned to code by hand will have a deeper understanding and more nuanced prompts, just like those who went to trade school to become a mechanic will know how to diagnose a squeak faster. But code won’t be something we think about as valuable on its own. Code won’t be something we think about at all. Syntax, algorithms, frameworks, languages, who cares.

Identifying as a coder of JavaScript will be like identifying as a coder of Assembly: silly. There won’t be ‘${LANGUAGE} Engineer’ jobs, there’ll just be Engineers. Going to ${LANGUAGE} conferences will seem weird.

PRODUCT IS THE NEW CODE

Instead of the language or framework we use to make the thing, we’ll identify by the thing we make.

“I’m Bob, I make budgeting apps for SMBs.”

“I’m Jill, I make calendar apps for remote workers.”

“I’m Hillary, I make tools to help lawyers get leads for workers comp cases.”

The time we used to spend learning a new API version or performance tuning will be spent talking to customers or marketing.

Instead of owning one small module, one engineer will own the entire repo.

Instead of having to raise VC to pay for 5 SWE salaries, an ambitious guy with an idea will spend $1,000 in tokens and create the MVP overnight.

WHAT THIS MEANS

I’m still wrapping my head around how this changes the world and our psychology. However, the spirit of this newsletter is to share my notes as I go, so here’s what I’ve got so far.

• Products become living entities. Many versions of a product will exist at a time and we will be able to adapt it with a grumble. Making apps will be more like playing with play-dough than laboring at the keyboard.

• Humans become the scarce resource. There are only so many eyeballs, credit cards, and human time available. As long as humans are the ones who gate-keep their wallets and attention, they will be the ones people compete for.

• Reputation will be the GTM. A digital trail of undeniable proof and a lack of scandal will do more to convince people than a campaign or a glossy sans-serif landing page.

What do you think? How will the abstraction of code impact our lives and work in the near-future?

[ INSPO ]

If you liked this post, consider sharing it on Hacker News so others can find it.

What a time to be alive.

Despite using AI daily for a while, I wasn't comfortable with letting agents do most of the work until 60 days ago. Since handing over the nitty-gritty details, I've merged over 900 PRs in two months.

Flooding GitHub with more LOC isn't a flex. In fact, I resisted doing volume because I didn't want Compass Calendar to turn into a mountain of slop.

However, it's finally possible for agents to do work without messing everything up along the way.

What I'm most proud of from the last two months isn't the PR count, but how the product has actually become SIMPLER.

It takes a lot of restraint to keep refining an existing UX instead of rushing into more features. But man, it feels good to go fast and not break things.

If you're a developer who's been considering handing over more of the work to your agents, this is your sign.

Here’s a simple way to get started that doesn’t require any extra tools.

1. Tell the LLM to plan a feature by creating well-groomed issues under a single milestone in GitHub

2. Tell the coding agent to work through each of the issues on their own until the milestone is done (use “/goal”).

3. Repeat

[ INSPO ]

If you liked this post, consider sharing it on Hacker News so others can find it.

Richard Hamming was a 20th-century mathematician who surrounded himself with greatness: Feynman, Oppenheimer, Shannon, and his colleagues at Bell Labs. He started wondering why some of his smart colleagues did significant work, while others, although smart, only did mediocre work.

In an incredible essay, he gives his answer. The ones who achieved great work had:

1. The courage to seek the significant problems

2. The humility to resist their egos

3. The mental preparation to pounce upon a “lucky” opportunity

The first point surprised me the most.

“Of course you have to work on the significant problems to make a significant contribution,” I thought indignantly.

But then I reflected on my own project choices, and realized much of my work was small-minded and inconsequential to others.

I’m not alone. Most of the people Hamming worked with at Bell Labs, although top 1% thinkers, never stopped to identify the most pressing problems in their field. Hamming would go to the Chemistry or Physics tables at lunch and play the fool, asking them what the top problems were. Then he’d find out what each of them was working on. Finally, he’d ask why they were all wasting their time on problems that — by their own admission — weren’t significant. (He then had to find a new lunch table.)

[ THE TRAP ]

The trap for us who aren’t working with the top 1% is to pretend like we’re at the modern Bell Labs. You and I are going to be massively impacted by AI, but we’re not going to contribute to AI chip architecture like an Nvidia engineer might. We’re not going to become a Shannon, Hamming, or Sutskever. But that doesn’t mean we can’t do significant work.

[ THE WAY OUT]

How to have top 1% significance without having top 1% intellect.

1. Niche. Instead of trying to compete with frontier labs on LLM engineering, combine AI with other domains and become an expert on the combination. For example: AI engineering for solo bootstrap founders with 10k in savings, 2+ years of coding experience, and building B2C iOS apps for US-based marketing firms with $500k+ ad budgets. That’s a lot easier than competing on just AI.

2. Leverage your work style. Your interests can help you pick a niche, yes. But you can work in a way that complements your natural way of consuming and producing. For example, I love to read, write, and watch ASMR cooking videos. I take what I’ve learned from my readings to write things like this. Then I record ASMR-style videos, add a voice-over track, and turn it into a quick YouTube video. Whereas my old YouTube videos were complicated and draining, this approach actually gives me energy and makes it easy to stay consistent.

3. Leverage your experience. There’s an epidemic of brain-fried iPad kids who’ve spent a decade of their youth scrolling. But young CEO Roy Lee points out how that’s their advantage, because they know what’s good. They know what type of video makes them stop scrolling. It’s become a deep-seated intuition, enough so that they can make these types of videos themselves and sell them to marketing firms. Millennials or Gen X could do the same, but we don’t have the same intuition for the vertical medium that a 16-year-old kid who's spent 4 hours a day for the last ten years scrolling does.

All of these tips are variations on the same thing: If you can’t do significant work in one single domain, keep stacking domains until you can.

• AI + consumer + indies + marketing + US

• Reading + writing + ASMR + YouTube

• Shortform + marketing + Gen Z

[ INSPO ]

The 3 Hidden AI Gold Rushes | Roy Lee x Jack Neel Podcast (youtube.com)

New software releases? Who cares. Learning new CS concepts? Whatever. Studying for the next interview? Job probably won’t even exist in a year. Working on that side project? No one will care because it’s just another addition to the mountain of slop, and the guy bagging your groceries can do it. Everything is done and cooked with AI now.

It’s exactly like that feeling once you enable cheats in a game; sure you can do anything, but everything is meaningless now. Our entire purpose and joy in life has been taken from us.

[ MAIN IDEA ]

I sometimes feel this way, too. It’s natural. Unfortunately, it’s not an empowering mindset. It positions us as victims being crushed under a technological wave, rather than leaders riding it.

So here are a few things that can counteract this mentality:

1. Recognize that it was never ours to begin with. Nothing was “taken from us.” Just because we know how to code by hand doesn’t mean we’re entitled to an infinite stream of validation. We learned the skill of coding by hand and were compensated for it handsomely because it was scarce. Now that this is no longer the case, we’ll have to learn new skills.

2. Writing code by hand was never the point. The point is helping people. It’s not about us; it’s about them.

Founder Patrick O’Shaughnessy explains in an interview how surrendering to helping others helped him find purpose during a time of seeking. I love the simplicity of it. It’s simple yet flexible enough to adapt to the rapid changes AI is ushering in.

I’ve been considering what’s next after my recent launch. It’s scary to try to come up with an answer, but asking questions that embody the spirit of helpfulness is much easier. Here are a few that I like:

1. Who can I help the most?

2. Who are the easiest people for me to help?

3. What skills of mine are the most useful to them?

4. What skills do I need to learn to be more helpful?

Answering these will lead to a short list of things to do: services to offer, products to create, things to learn, places to go. Then you can narrow the scope and ask again.

1. Who can I help the most this week?

2. Who are the easiest people for me to help this week?

3. What skills of mine are the most useful to them this week?

4. What skills do I need to learn to be more helpful this week?

The hard part, of course, is taking action, validating assumptions, and iterating based on feedback. But doing this has helped me flip the mindset from “I’m cooked” to “I think I could still be helpful.”

That’s a good place to start.

[ INSPO ]

[ MORE ]

DHH: How to Build a Profitable Company Without Losing Control (youtube.com)

How it went - by the numbers

PH Stats

• Daily Rank: #17

• Upvotes: 81 points

• PH followers gained: 50

• Comments: 2

Marketing stats

I promoted the launch on my socials and the app’s email list. I also hosted two YouTube livestreams, where I answered questions and showed the launch progress.

• Followers gained: 0

• YT Live views: 86

• Peak concurrent viewers: 17

Conversions

Basically, more casuals. Of the 256 visitors, three went through the full onboarding and then connected their Google accounts.

How it went - vibes

Spam. The product went live at 12:01 AM. By 12:02, I had a dozen LinkedIn connection requests, cold emails, and new PH followers. They all said they loved the product and would be happy to promote it to their audience … if I paid them a fee.

PH disengagement. I was encouraged after seeing a thoughtful comment from a fellow maker, until realizing it was ChatGPT. He went through all the products of the day, posting generic messages to draw more traffic to his launch. I got one comment from a real human, an old friend.

Direct engagement. I got some congratulatory emails, texts, and messages on the livestream. People were more willing to share their support directly, rather than from a PH account.

Recommendations

Of my four PH launches, this one had the best product and marketing. Yet I got the least amount of PH engagement and the most spam. Something just felt off about the PH experience. Then I found that PH is actually dead and has been for a while. It’s sad to see another site I used to frequent be consumed by the dead internet black hole. But it’s not all for naught. I didn’t get the same launch day zeal from the old days, but I got traffic, feedback, and identified a few areas where the product could improve.

So, if you have a product and are thinking of launching on PH, here’s what I recommend.

1. Keep it simple. Don’t overthink the marketing or launch mechanics. 80/20 it by making the page presentable, but focus most of your efforts on the product. The only way you’ll get organic growth on this day is if real people reshare it, and there are so few real people on the site now that it’s tougher to get them to do that than before.

2. Don’t try to become product of the day. Doing this would violate the first rule. Instead, just think about the site as a free source of traffic for a day and a bump to your SEO.

3. Harden your LinkedIn by enabling the setting that requires people to enter your email before making a connection request.

4. Host a livestream. This is much more natural and fun than trying to get people to sign up for a dead platform and have fake convo in the comments

5. Set up auto-fixing PRs. Error happens → AI fixes bug → AI merges and deploys to staging→ AI notifies you → you verify and deploy to prod. This will allow you to get some sleep on launch day while also fixing critical bugs quickly. I didn’t do this, but I wish I did, because most of my day was just watching logs.

My PH experience may have been underwhelming, but I’m still a fan of official launches. It allows you and others to celebrate progress. In a field where our projects never really end, having these milestones is good for the psyche.

Good luck.

The second requirement for Edison's 1870 contract for an autographic telegraph: simplicity.

The sixth requirement says the same in different words: "Have no elaborate preparation..."

If Edison could invent new ways to communicate in the 19th century with simplicity...we should be able to build CRUD apps in 2026 with simplicity.

For anyone else who didn’t know what an automatic telegraph was: Think of it like a pre-internet fax machine. They’d transmit exact copies of handwritten writing or line drawings over electrical wires twice as fast as Morse code operators could.

[ INSPO ]

[ MORE ]

Naval’s advice on simple sales (substack.com). TL;DR - Make it good, then tell the truth.

[ MAIN IDEA ]

Occasionally I’ll run into a fellow unemployed indie dev who is actually focused on a single project. Once I find this out, I always ask this question excitedly:

”What’s your runway?”

So far, I’ve never gotten a straight answer. Instead, what follows is a ramble about how their wife is supporting them for “a little bit,” how they can sell some crypto, and how they can probably go back to their old job and moonlight if things flop.

I used to get so frustrated that I’d jump in --

“No, I mean how long until you run out of money??”

That only elicited even longer rambles, this time about their 401k rollover, their history as a consultant, their HSA, their father-in-law’s welding business, Airbnb, and property taxes.

I finally realized this:

Bootstrappers don’t know their runway.

“Runway is for those YC companies,” they think.

No, runway is for us way more than it is for them.

That’s because if you don’t know your runway, your financial decisions are driven by your emotions, which is bad.

So here’s how to figure out your runway as a bootstrapper.

Part I: Get your numbers

1. How much are you losing? Add up last month’s expenses (business + personal) so that you have one number.

2. How much is coming in? Add up last month’s income after taxes. One number.

3. What’s the gap? Expenses - Income.

4. How much do you have? Add up the cash and assets you’re willing to part with.

Part II: Divide

1. Cash (#4) ÷ Gap (#3). That’s how many months you have.

2. Multiply that by 30 if you want it in days.

Now you know your runway.

This’ll help you see how big of an impact your lifestyle has on your startup’s success. Let’s look at a few scenarios; you’ll see what I mean.

Founder A is confident, because he’s sittin’ on $100k cash from an IPO. But he spends $15k each month, and has nothing coming in.

100,000 / 15,000 = 6.6 

Hotshot has less than 7 months of runway.

Founder B is young and broke, but frugal. He set aside $3,000 before getting laid off. He’s spending $1,500 and makes $800 from landscaping on the side. His gap is $700.

$3,000 / $700 = 4.3

The hotshot founder with a hotshot lifestyle only has two months more runway than a broke kid with a landscaping job!

Founder C got things off the ground before quitting her job. She’s spending $4,000 but earning $3,000. Her gap is $1,000. She’s got $20,000 stashed away.

$20,000 / $1,000 = 20

20 months of runway! 600 days to figure out how to earn an extra $1,000 and become ramen profitable. Founder C has 1/5 of the cash of Founder A, but over 3X the runway.

It’s wild to see all the gibberish in your head reduced to one number, isn’t it?

Clarity is king.

Although it’s initially scary, I find that tracking this number is empowering.

It reminds you that you always have two levers: make more money, or spend less money. Hotshot Founder A could triple his runway by making $5k recurring revenue more next month. Or he could make $0 and triple his runway by downsizing to a smaller apartment.

If you don’t like your runway, you can cut expenses, pick up consulting work, charge more, or pivot. These are all rational responses to a financial reality.

It also keeps your emotions in check. Bumping into a high school friend who got a Big 4 Job and just bought their second Audi doesn’t spike your FOMO anymore; you already confronted the reality of your decisions in a spreadsheet that morning.

So whether you’re sitting on a mountain of cash or scavenging for change, please calculate your runway, if only to make our conversation more enjoyable for me when we bump into each other.

[ INSPO ]

[ MAIN IDEA: SIMPLE PAYMENTS ]

In 2004, Howard Wein started selling Philly cheesesteaks for $100 each.

In 2013, Nipsey Hussle sold 1,000 mixtapes for $100 each.

In 2014, he sold 100 for $1,000 each.

In 2023, MSCHF sold a microscopic 3D-printed handbag for $63,750.

This blew my mind.

But after thinking about it, it started making sense.

They may have been offering similar products to their peers, but they were playing an entirely different game.

Howard was challenging your perspective on classic food.

Nipsey was using music as a funding mechanism to uplift his community.

MSCHF was leveraging clout to highlight our insatiable appetite for status and small handbags.

These creators knew they were doing things differently, so they refused to market and price themselves like commodities.

We devs should take notice, because our traditional funding sources are empty at their core.

• Deal sites like AppSumo enroll you in a race to the bottom, where you’re selling lifetime deals for $29

• Launching an NFT involves a lot of education and convincing people you won’t rug pull

• VC often requires you to trade your soul and control for time.

• Raising from friends & family exposes the wholesomeness of your relationships to the brutality of the marketplace.

But what if, like those creatives above, we took a different path?

What if we found a few people who valued our stuff so much that they’d be willing to pay 100X what a normal user would?

That’d change things, a lot.

You could make it insanely useful for them.

Suddenly you have daily users who really care.

They’re emotionally invested, so they give better feedback and are less demanding.

With that extra profit, you can reinvest in improving the product, support, and your local community … while also having enough left over to feel stable enough to shoo away those VCs who tempt you with a quick flip.

Your perception of yourself improves. Most importantly, you keep your soul — the pure essence that gave you the courage to start in the first place.

It sounds too good to be true.

Well, I figured I’d find out for myself if this theory holds weight.

[ THE STACK ]

So today my goal was to create a high-ticket offer — the simplest way I could.

No fancy landing page, no pipeline of automations, no ads, no images, no analytics, no funnels.

Just a blog post and Calendly.

Here’s how it works:

• The blog post explains the offer. Here it is for reference: https://www.compasscalendar.com/blog/crew

• There are two CTA links in the post that redirect to Calendly. Part of the offer is a call with me, so I wanted people to book it directly without adding a delay or another step.

• Calendly requires payment before finalizing the meeting. I connected Calendly with Stripe, so payments get tracked there. I didn’t even have to create a new Stripe product to set this up.

• When someone books, I get an email from Calendly and the money. Calendly handles the reminders, and then I just have to worry about fulfillment, which requires me to send a physical CD in the mail.

This whole project took fourteen hours, but eleven of those were crafting the offer and refining the copy. So if you already know what you’re selling, you could copy-paste this approach and be live in three hours.

I didn’t have to fuss with ads, product demos, screenshots, or high-res pictures. Just words, a link, a $12 subscription, and a few integrations.

That’s not bad!

Will the offer work? I guess we’ll see. Either way, it’s pretty cool that you can go from having an idea to having a way to monetize it in one day.

[ INSPO ]

In the last seventeen days, I’ve merged 266 Compass Calendar PRs. That’s 16 per day, a 14X increase since June.

One reason why I feel comfortable pushing so much code is that I enforce simplicity in each PR. Here’s how:

• A “/simplify” skill runs on every PR, which creates a commit that reduces complexity. Since this is a new commit, I can review it to ensure that we’re preventing sloppy abstractions.

• A PR template has a “Simplicity” heading, where the agent has to explain what was simplified or why the implementation is already minimal.

• My system prompt explains the supreme value of simplicity.

• I do a manual sweep of the code and keep a list of things I want simplified, and then kick off another session

Basically, I’m letting the agent do the first implementation. Then I’m nagging it to simplify things without breaking tests. Then I’m nagging it again to simplify it further.

It’s the equivalent of Henry Kissinger repeatedly asking his assistant, “Is this the best you can do?” before reading a draft. After a few rounds of revisions, the assistant eventually spats back, “Damn it, yes, it’s the best I can do!” Kissinger replies, smugly, “Fine, then I guess I’ll read it this time.”

When your assistants’ tokens are less expensive than your time, why not set a high bar before reviewing yourself?

If you’ve found a clever way to keep things simply, reply here to LMK.

[ INSPO ]

[ MORE ]

Kissinger: a biography (archive.org)

https://berkshirehathaway.com/ — the conglomerate that has enough money to buy half the internet hasn’t veered from its 90s aesthetic of blue font and direct links.

https://telegram.org/ — A consumer messaging app that doesn’t try too hard. The combination of simple text and whimsical rubber ducks is eye-catching without being try-hard. If one of the top 5 most-downloaded apps in the world can get away with this, so can you.

https://yaml.org/ — A site that’s structured to mirror a real YAML document. A great example of how to break out of the generic WordPress or technical doc site layouts.

https://www.barebones.com — a 34-year-old text editor that “(still) doesn’t suck.” The site is clearly written by a cowboy indie developer who doesn’t care what the cool kids in the valley think.

https://news.ycombinator.com/ — it’s amazing how much use they’ve gotten out of this simple hyperlink + feed concept. Their commitment to the chronological feed is what keeps me coming back.

https://www.space150.com — an agency that proves that simplicity doesn’t need to be old-fashioned. A lot is going on, but it’s controlled and well-structured. They redo their website very frequently, so revisit this site in a few months for another variation of elegant simplicity.

Whenever I’m tempted to restyle a landing page (again), I revisit these. Before long, I usually conclude, “Ya know what, I kinda like it how it is.”

More

Rich Siegel interview (substack)

Rich Siegel explains how he works (usethis.com)

This idea originates from Lambda calculus, a mathematical system developed by Alonzo Church in the 1930s. Its impact didn’t extend beyond formal math until the late 1950s, when John McCarthy created Lisp, which treated functions as first-class objects. Soon after, linguistics applied lambda calculus to the semantics of natural language.

Now that functions are inextricable in programming, we rarely have to consider their origins. But think about it, whatever programming language you use treats functions as entities with the same status as other data types like integers, strings, or arrays. Treating functions as first-class citizens is what allows us to

• Assign them to variables

• Pass them as arguments

• Return other functions (func-ception)

• Store them in objects, lists, or tables

Without the ability to treat functions as data, we couldn’t have:

• Higher-order functions (.map, .filter, .reduce)

• Callbacks that run when an event (like a button click) occurs

• Asynchronous programming (async/await)

• Closures

• TypeScript

Programming at its best is building complex systems by combining simpler building blocks in a disciplined manner. It’s easy to glorify the builder or complain about the system’s complexity. But let’s also appreciate the simple building blocks that our predecessors gave us. Without them, modern software would be unthinkable.

BTW - Isn’t it amazing that we’re still coming up with new math concepts? Your great-grandpa lived in a world that couldn’t reason about functions and integers at the same level of abstraction.

AFK primitives

If “treat functions as data” is a simple building block that empowers programmers to tackle computer problems, what are some simple ideas that could empower programmers to tackle problems AFK?

Here are a few.

Move in a way that you enjoy. Box, run, lift, power walk, swim — as long as you’re moving, you’ll avoid the traps of this sedentary profession. Hunched posture, processed food, sleepless nights, chronic distraction, and social anxiety are enemies of movement.

Do something you believe in. Main characters have points of view and fight for them. NPCs believe whatever they’re told and accept submissive positions. Changing your character doesn’t require you to quit, relocate, buzz your head, or get another degree, though. You already possess one of the highest-leverage skills available (building robots), anyway. If you apply your skills to your beliefs, your aura will grow. As your aura grows, so does your ability to handle hardship.

Think with simple tools. You don’t need an LLM, a second brain, or Spotify Premium to clarify your thinking. A pocket notebook is enough. Take a walk to organize your thoughts, then write down the important stuff. The more you outsource your higher-order thinking to artificial tools, the less competitive your ideas. If you combine your unique perspective, experiences, and voice, then your thoughts become more singular. Thinking differently is differentiating in a world where everyone is asking the same two apps the same questions.

Got a building block you swear by? Reply here to LMK.

More

Lambda Calculus (wikipedia.org)

Ergo: a case study in approachable invention (keepsoftwaresimple.com)

minimal bullet journal setup guide (youtube.com)

Brian Beckman: Don’t fear the Monad (youtube.com)

The first lecture of my college English class taught me to survive as a software engineer.

The professor asked everyone to open their notebook and write down the following class guidelines:

1. Bring books to class

2. Late work is not accepted

3. Submit hard copies only (no emails)

4. If you come late, don’t come

5. Hold your pee

6. One person talks at a time

7. No neighbor idle talk

8. Don’t sleep

9. Take notes during movies

10. No cell phones

11. No texting

12. No computers

13. Sign in

14. No food (drinks OK)

15. Paper grades are based on 70% content, 30% editing

16. Grades will be returned promptly

17. Discussions & lectures are mandatory

18. No hoodies (see #8)

19. No extra credit

20. No absences

21. No cheating

My high school teachers warned us that college would be different. I assumed they were exaggerating to scare us into being quiet. I quickly realized they were just telling the truth. I glanced across the room and saw dozens of other wet-behind-the-ear students having the same realization.

Some scoffed indignantly, as if the professor’s standard was unreasonable.

Some looked defeated, as if they had already received a C-.

But a few lit up.

These were the future A-students. They came to college hungry for knowledge. They were excited that an authority figure challenged them, rather than admired their intelligence. They appreciated that he was also holding himself to a high standard (#15, #16).

The high standard offended the C students and inspired the A students.

You probably know where I’m going with this:

This phenomenon doesn’t stop after college.

Show me an engineer who reads a job description and complains, and I’ll show you a C-player.

High expectations threaten these people because they expect to coast without consequence.

The same expectations excite the A-players because they recognize that they need to get to improve.

What to do with this info day-to-day?

Depends what kind of student you want to be.

Are you good with modest improvements in skill, income, and influence? Do competition, candor, and performance metrics drain you? Do you need work-life balance? Then you can expect to get a C or B.

All good, I won’t shame you or try to convince you to go for an A. Just don’t fool yourself.

If you aspire for As, on the other hand, don’t let the C players bring you down. You might be in the same company as them, but the rules are different. They just need to show up and do the minimum. You need to do the most.

Practically, this means doing the functions listed on your job description and then doing part of another person’s job.

^ That seems crazy, but it works. Instead of trying to explain it here, I’ll just point you to my deep dive on YouTube.

I was hesitant to share this harsh message until I realized that silence comes at the expense of the aspiring A-Players. Every scoff from someone who doesn’t aspire towards greatness has the potential to discourage someone who does.

We need more A-Players in this field, especially now.

If you’re on the fence, it might help to know this last detail:

Although I was initially terrified by my English professor’s expectations, I decided to give it my all anyway. It was hard work, but I got an A. But this is the best part: We stayed in touch after the class ended. We initially chatted about books, then music, then life. It’s been fourteen years since that first lecture, and I’m so proud to say that my professor is now my best friend.

Takeaway:

A-Players attract one another.

If you want to surround yourself with exceptional people, you need to become one yourself.

While prepping to launch Compass Calendar v1.0.0 this week, I dug up my early designs from 2021.

(Yes, it took 5 years.)

(Yes, that’s insane.)

I couldn’t help but chuckle at what I saw.

I envisioned a superapp that’d support a plethora of data types: events, tasks, habits, reminders, tags, and routines. I wanted it to be as powerful as Notion, but less heavy-handed.

So I started coding.

Then I made every first-time founder mistake in the book:

• Stuffing it w/ features

• Ignoring feedback

• Using Electron

• Chasing VCs

• Wearing fleece vests

I built a bloated app that no one used.

Eventually, I looked in the digital mirror and thought:

“I gotta lose some weight.”

I spent the last seven months deleting, consolidating, uninstalling, and refining.

As a result, v1 does a lot less than v0:

• It only has events and tasks

• It only works on the web (not desktop, not mobile)

• It only syncs w/ GCal (not Outlook, not iCal)

• It only has two views (initially it had five)

But what it does, it does well.

In 2021, shipping something so lean would’ve embarrassed me.

In 2026, the product’s minimalism is what makes me proud.

That’s because along the way, I learned a priceless lesson:

Simple !== easy