Rohit Garg — Writing

Redesigning rohitgarrg.com with AI

Wed, 22 Apr 2026 00:00:00 GMT

A weekend redesign using Claude Design, Claude.ai, and Claude Code. Notes on what each tool did well, where the chain broke, and what manual review still needs to catch.

Project Hail Mary: A Book Review

Thu, 16 Apr 2026 00:00:00 GMT

I watched the movie first. Loved it. Ryan Gosling was charming, the visuals were great, and I walked out of the theater thinking I'd gotten the full story.

Then I listened to the audiobook. Sixteen hours. And I realized the movie had given me the highlights reel of something much bigger.

What the book is (no spoilers)

Project Hail Mary is a science fiction novel by Andy Weir. A middle school science teacher wakes up alone on a spaceship. He doesn't know why he's there. He doesn't remember how he got there. Two crew members are dead beside him. And Earth has a problem that he was apparently sent to solve.

That's all the plot I am going to share in the spoiler free version.

What makes the book work is the way it handles science. Weir doesn't skip over the problem-solving. When the protagonist needs to measure gravity, he doesn't just "check the instruments." He ties a thread to a weight, makes a pendulum, and uses the swing period to calculate gravitational acceleration.

This pendulum scene is the book in miniature. A problem, a physics-based solution, the satisfaction of watching someone think through it properly. The whole novel runs on this engine.

The audiobook question

There's a character in this book who doesn't speak English. Or any human language. The audiobook renders their speech as actual musical tones. Chords. Notes. You hear what this character sounds like. I don't know how the print version conveys this, but hearing it was something else entirely.

The audiobook also has one frustration. There's a notation system in the book where characters are represented by Greek letters. Alpha, beta, delta, pi. In print, you'd see these as symbols and map them to their meanings. In audio, you're hearing someone read out letter names in sequence, and I couldn't track what corresponded to what. Probably not a problem on paper.

On balance, audio was the right format for this book.

Should you read it?

If you love science fiction, this should be in your top three or four books to pick up. I'd put it alongside Liu Cixin's Three-Body Problem trilogy as science fiction that takes its science seriously without sacrificing story.

Do you need a physics background to enjoy it? Not really but you would enjoy it more if you do. The characters carry the story on their own, and the friendship at the center of the book is special regardless of what you know about orbital mechanics. But if you understand basic Newtonian physics and a bit about how relativity works, the book rewards you for it. You stop listening a character solve problems and start solving them alongside him. That's a different experience. A better one, if you can access it.

If you watched the movie and thought you got the full experience, you didn't (movie is great, by the way). The patient buildup, the tension, the explanation, the science given the space to work. All of that lives in the book.

Full spoilers from here. Come back after you've read the book.

The book says Ryland is a coward. I don't buy it.

The book establishes early on that Ryland Grace wasn't one of the original astronauts slated to go on the Hail Mary mission. Later, it was revealed that Dr. Stratt had to send him involuntarily. The framing is clear: he's brilliant but not brave. A scientist, not a hero.

However, I never felt that while listening.

A coward would not have kept going after waking up alone on a spaceship with two dead crew members. A coward would not have continued a mission he couldn't even remember. That's not cowardice. That's someone whose scientific curiosity is stronger than his fear.

When Ryland first encounters Rocky's ship, he doesn't hesitate. He grabs an artifact Rocky sends over. He goes on a spacewalk to retrieve something from Rocky's vessel. He tries to open an alien object without knowing what's inside. None of this is cowardly behavior.

On Earth, sure. He said no to going to space. That's self-preservation. But once he was in space, I never saw a hint of the coward the book kept telling me he was. His scientific brain kept overriding whatever fear he might have felt.

So when the Stratt flashback scene arrived, the one where he refuses the mission, it felt anti-climactic. Not because it was badly written. Because by that point, I'd already spent hours with a version of Ryland who didn't match the label.

Rocky

Rocky grew on me slowly. When he first appeared, he was interesting but not much more. An alien engineer. A plot device with a personality.

Then the relationship started building. The banter. The sarcasm. Rocky calling Ryland "stupid, stupid, stupid" when he couldn't figure something out. The worry in his voice when things went wrong. The constant, anxious concern about his home planet Erid.

What made Rocky feel real, and not like a human in an alien costume, was the specificity. He's an engineer, not a scientist. He builds things. Ryland thinks through problems theoretically. Rocky builds solutions. The mission would have failed without both of them, and the book never lets you forget that. Two people from different species, needing each other equally.

And then Rocky comes out of his pressurized environment to save Ryland's life. An Eridian, in an atmosphere that could kill him, because his friend was in danger. That's when Rocky stopped being a great character and became one of my favorite characters in anything I've read.

The scene

Ryland jumps out of his spaceship into open space to reach Rocky's vessel. No guarantee he'll make it. A few hundred feet of nothing between him and his friend.

This is the guy the book calls a coward.

When Rocky's voice comes through from inside the ship, a couple of octaves higher than normal, his excitement unmistakable, and Ryland says "I am here, buddy." Listening to this emotions, I welled up. Genuinely.

It works because the book earned it. Twelve hours of a friendship building across a language barrier, across species, across every possible difference. All of that compressed into one line.

The forest and the tennis balls

This is the moment that sold me on Weir as a writer of science, not just science fiction.

Ryland finally makes nitrogen-resistant Taumoeba. The mission is going to work. And then he discovers the Taumoeba have also become xenonite-resistant. They're escaping through the walls of the container designed to hold them.

Ryland's theory for how this happened is an analogy.

Imagine a forest. If you shoot tennis balls into the forest, the balls travel in straight lines and stop wherever they hit a tree. None of them reach the other side. But a human walking through the same forest can weave around the trees, take detours, find a path through. The Taumoeba had been sitting in that xenonite container long enough to evolve the biological version of that zigzag. They learned how to hide inside the atoms of xenonite itself.

I don't know if this is defensible molecular biology. That's not the point. The analogy works as an analogy, and watching a character reason through a problem using this kind of lateral thinking feels like watching a scientist actually think. That's what the book keeps doing. Giving characters problems, then letting them work through the problems the way people would. Not the way a plot demands.

The part I didn't buy

The global cooperation.

I can accept astrophage. I can accept close-to-light-speed travel. I can accept an alien species that communicates in musical chords. Science fiction asks you to accept premises, and I'm fine with that.

But every government on Earth setting aside politics to work together seamlessly? Covering the entire Sahara Desert with astrophage material in months? That's where the book lost me.

Here's the test. Humanity has decades of evidence that climate change is real. Scientists have been screaming about it since I was in school. Temperatures are literally measurable. And we still can't agree on whether it's happening, let alone agree on a coordinated response. If we can't align on something that boring and slow, the idea that astrophage would cause every nation to hand its authority to one Dutch woman with a clipboard feels generous.

Weir knew this was a problem. That's why he invented Stratt. Giving one person absolute authority is the mechanism that makes the rest of the story possible. The book needed humanity to move fast, so he wrote a character who could force humanity to move fast. But political leaders from powerful countries don't just step aside when something important happens. They want their names on the letterhead. They want influence over the direction. The smoothness of the Hail Mary project, the absence of anyone trying to claim the spotlight, the speed of the Sahara rollout. None of that felt real.

I went along with it because the rest of the story was good enough to carry me past it. But it was the one premise I couldn't quite swallow.

The ending, and what's missing

I was satisfied with the ending. We learn that Earth was saved. Ryland gets closure, even if it means he can't go home. There's a completeness to it.

But I wanted one more chapter.

The entire book is told from Ryland's perspective. That works. It's the right choice for the story. But it means we never see what happens on Earth when Taumoeba arrives. We never see Stratt's reaction.

Stratt is the most interesting character in the book besides Rocky. She has absolute power and she uses it without flinching. She sends Ryland to space without his consent and she knows she'll answer for it. She says at one point that she's going to hell. She has a hard exterior that the book never lets us see behind.

An epilogue from her perspective would have answered questions the main narrative can't. What did she feel when Ryland's solution arrived? Did she feel vindicated? Relieved? Did all the ruthless decisions feel worth it in the end? Twenty-six years passed on Earth while Ryland was gone. What happened to her and more importantly, Earth in that time?

The book doesn't owe me this. But I would have loved to read it.

How I Actually Use Claude

Wed, 15 Apr 2026 00:00:00 GMT

Most people use Claude like a search engine with better grammar. Type a question, get an answer, move on. That works for quick tasks. But it's about 20% of what Claude can actually do, and it's the least interesting 20%.

In one of my previous posts, I wrote about how I got started building with AI. The deleted apps, the Udemy courses, the first project that actually shipped. A few people asked the same follow-up: okay, but what's the actual workflow?

This is that post.

I've been building with Claude for several months now. A personal website, a browser game, an iPad app on the App Store, internal tools at work. Along the way I settled into a system. It isn't perfect. But it works, and I want to share it so you can skip some of the dead ends I went through.

The one habit that changed everything else

Here's a prompt I wrote when I wanted to analyze six months of bank and credit card statements.

"I want to analyze my personal finances. I want to figure out where I spend more, where I spend less. Most spending happens via my primary credit card. I also have a home loan EMI and some monthly investment SIPs. I want you to look at my statements and figure out patterns. Act like a personal finance planner. Take a deep breath and work on this step by step."

Before running it, I asked Claude to improve the prompt itself.

Its response was blunt. "Your prompt is solid on context but weak on instructions for how Claude should actually process the data." It caught five problems. "Take a deep breath" is wasted tokens. "Figure out patterns" is vague. I hadn't told it how to categorize transactions. I hadn't specified what deliverables I wanted. And the big one: credit card payments from my bank account aren't expenses. They're transfers. The actual expenses are on the credit card statement. If Claude double-counts these, the entire analysis is garbage.

The rewritten prompt had explicit double-counting prevention, structured deliverables, and a two-step process where Claude proposes categories first before doing the full analysis.

Two minutes of work. Completely different output.

Most people iterate on the output. They generate something, tweak it, regenerate, tweak again. I iterate on the input. By the time I hit execute, most of the thinking is already done. That one shift made everything else in this post possible.

Three levels of effort

Not every task needs the same amount of setup. I match effort to stakes.

Ask. For quick tasks, I just type and go. Validating a data point. Rephrasing an email. Explaining a concept I half-understand. No special setup, no prompt engineering. Most of my daily usage is this.

Refine. For anything where vague input would produce vague output, I invest two minutes upfront. I write my prompt, then add: "Before running this, review my prompt. What's vague? What's missing? What assumptions am I making that could produce bad output?" That's what caught the double-counting problem above.

Build. For anything that leaves the chat and becomes a real thing, I run the full system. Structured specs, adversarial review, phased execution with quality gates. Thirty to sixty minutes of setup before a single line of code. It sounds like a lot. It's nothing compared to the cost of building the wrong thing.

Most of my daily Claude usage is Ask. Maybe 70%. Refine is another 20%. The full Build system is 10% of the time but produces 90% of the value.

If you only use Claude for quick tasks, the Ask and Refine habits are enough to make a real difference. If you're building things, keep going.

Building: plan, break, build

This is where Claude stops being a tool and starts being a workflow. It runs on three surfaces working together.

Claude.ai is where I think. Brainstorming, planning, writing, strategy. I use Projects to keep related conversations together with shared context files. Claude Code is where I build. It works directly in my codebase, reads files, runs commands, commits to git. Cowork is where I delegate. File processing, QC checks, batch operations, spreadsheet analysis.

Each surface gets its own instructions. They share about 70% of the same DNA (writing style, don't be sycophantic, challenge bad ideas) but are tailored for what each one does. You wouldn't give the same brief to a strategist, a developer, and an operations coordinator.

Plan

Every build starts with a Claude.ai Project. Not a one-off chat. A Project.

I give it the problem statement. Not the solution. "Here's the problem I'm trying to solve. Here's who it's for. Here are my constraints." I define what "done" looks like. Not "analyze this" but "produce these four specific deliverables in this format."

I keep going back and forth until we're both satisfied. Three exchanges or fifteen. Then I ask Claude.ai to produce four files: a handoff spec (problem, approach, success criteria, constraints, risks), a CLAUDE.md file (project-specific instructions and architecture context), an implementation checklist (phases with QC gates), and a prompts file (exact prompts to paste into Claude Code for each phase).

But I don't take them as-is.

Break

I open a fresh chat in the same Project and run an adversarial review. Fresh chat matters. If I review in the same conversation where the files were created, Claude is anchored to its own reasoning.

I ask it to behave like a senior staff engineer doing a critical review. The key instruction is a structural constraint: find specific problems, don't rubber-stamp. After the review, I ask Claude to rebuild the files from scratch, fixing every issue.

Here's why this matters. I was building a solar system explorer for my kids, an early prototype that later became Planetia. I'd written a detailed spec. Planets, orbits, textures, interactivity, the whole thing. It felt thorough. The adversarial review found 30 issues across four severity levels. Eight were critical.

Two examples. The spec said the Sun should be "roughly 5-8x the size of Jupiter." That's a 60% range on the most important visual parameter in the entire project. No concrete numbers anywhere. Claude Code would have invented values. They would have looked wrong. I would have spent four rounds going "make Jupiter bigger... no, smaller... actually the distances are weird." The review flagged it. The fix was a single table with every radius and distance defined as concrete numbers.

The spec had interactivity arriving at Prompt 8 out of 16. That meant for half the build, I'd be staring at a scene I could only rotate. Can't click a planet. Can't read a fact. For a project whose entire purpose is interactive exploration, that's backwards. The review caught it. Interactivity moved to Prompt 5.

Thirty issues. Twenty minutes of review. I'd have discovered every one of these problems eventually. During the build. When fixing them is ten times more expensive.

Build

I drop the four reviewed files into the root of a new project and execute prompts from the prompts file, one phase at a time.

For major builds, I add a second layer of adversarial review inside Claude Code itself. The prompt tells Opus to share its plan with a Sonnet subagent and a Gemini subagent. Each has to identify the three weakest decisions, flag unnecessary complexity, and call out unvalidated assumptions. Opus decides what to accept.

After each phase, two habits keep things clean. /simplify reduces unnecessary complexity. Code accumulates cruft, especially when an AI writes it. /sync-docs updates the spec and CLAUDE.md to match what was actually built, because code sometimes drifts from the plan. If the spec says one thing and the code does another, the next phase starts with bad context. Code is the source of truth. Not the spec.

The system isn't perfect

The adversarial review catches spec-level problems. It doesn't catch everything.

When I was building Office Survivors, a browser game, the spec and the code were both technically correct. But when I played the game, enemies were too strong. You couldn't survive past four minutes. No amount of spec review catches a balance problem. Only a real person playing the real thing does.

Same with the iPad app. The build went smoothly. The part that ate three weeks was operational: Apple Developer account setup, tax forms, App Store submission, rejection, resubmission. None of that shows up in any spec.

The system handles the building part well. It doesn't handle the parts that aren't building.

Claude.ai doesn't disappear after planning

This surprised me. Since the Project has full context of the spec and all the decisions behind it, I can go back to it whenever I get stuck during implementation. When I was adding a newsletter to my website, I had to create a Buttondown account and configure DNS records. Claude Code couldn't do that. But I could screenshot what I was stuck on, paste it into the Project chat, and get help immediately.

The Project becomes a thinking partner that stays with you for the life of a build.

The thing that will bite you

Context windows.

Chats get compacted fast, especially if you're pasting screenshots, PDFs, and long documents. Once compaction hits, earlier parts of the conversation get summarized and compressed. Claude starts responding to its own summaries instead of to what you actually said.

I learned this the hard way. I was running a content quality analysis in Cowork. Multiple phases, hours of work. Then the chat compacted. I had the output but no knowledge of how I got there. The reasoning, the intermediate steps, the decisions I'd made along the way. Gone. I had to start the analysis fresh.

Since then I've become deliberate about context limits. If a task is getting long, I break it into smaller sessions. The prompts file for Claude Code is designed so each prompt is self-contained. Code persists in the file system. Context doesn't need to. Even at the Refine level: if you've been going back and forth for twenty messages, start a new chat, paste in what you've decided so far, and continue from there.

What this costs

The first time I set up the full system, it took a full day. Each new project still takes thirty to sixty minutes of setup before any building starts.

I don't write code. I'm a product manager. And that setup time is the reason I can ship things that would otherwise need an engineering team.

If you try any of this, start with Refine. Next time you write a prompt longer than two sentences, ask Claude to improve it first. Two minutes, no setup, immediate difference. The rest of the system can come later, when you're ready to build something real.

From a Kid's Question to the App Store

Sun, 29 Mar 2026 00:00:00 GMT

My son asked me what would happen if an asteroid hit Earth. I was working on my laptop.

I didn't have an answer. I Googled it. He followed up with where the asteroid belt is, how big Jupiter is compared to Earth, and why the Moon goes around Earth but Earth goes around the Sun. This is a regular Tuesday in my house.

Everything out there for kids his age is either static or passive. Images in a book. A three-minute YouTube video about Saturn's rings. Nothing he could touch or play with. He wanted to interact with the solar system. The options available were "look at the solar system."

So I built a browser-based solar system explorer. React, Three.js, a weekend project. Drag to orbit, pinch to zoom, tap any planet to get fun facts. 22 celestial bodies. A spacecraft mode to fly between worlds.

My kids used it a few times and moved on.

Fair enough. A laptop browser isn't how a five-year-old wants to explore space. An iPad is. Touch, pinch, rotate. That's how kids already expect things to work.

So the next step was an iPad app. I had never opened Xcode. I didn't know Swift or SwiftUI or RealityKit. But I'd already shipped a browser game and a full website redesign using the same workflow: plan everything in Claude AI, break it into phased prompts, hand those to Claude Code. The question was whether that process would survive a platform I'd never touched.

It did. Four weekends. And the part that surprised me most was that the code was the easy part.

The code was the easy part

I spent a couple of days before writing a single line of code. Not learning Swift. Not watching tutorials. Just planning. What should this app be? How should the screens connect? What data does each view need? That planning phase produced 23 or 24 Claude Code prompts. Every screen, every interaction, every animation, mapped out before Xcode was even open.

Claude Code wrote the Swift. I reviewed the output. Most of it worked on the first or second pass. The gap between "I've never written SwiftUI" and "I have a working iPad app" turned out to be about two weekends of focused building. That's not a statement about AI in general. That's what happened on this specific project, with this specific workflow, because the planning was done properly before a single prompt was sent.

Skip the planning and you'll spend your weekends debugging instead of building. I've seen that happen too.

Six modes because I watched my kids

The original plan was simple. Rebuild the browser explorer as a native iPad app. Better touch controls, better 3D.

Then I started paying attention.

My son would explore for a bit, learn some facts, and then want more. He kept asking "what if" questions. What happens if Jupiter disappears? What if Earth had two suns? He wanted to test ideas, not just read facts.

My daughter had a completely different reaction. She asked if she could color Jupiter. Could she make it cuter? She's into fine arts and drawing. The solar system was interesting to her only if she could make it her own.

So the explorer became one of six modes. Size comparison. Quiz with badges and ranks from Space Cadet to Admiral. Customize, where you pick any planet and paint it however you want. My daughter painted Saturn pink with polka dots and a lot of hearts. That's the section she opens every time.

Then the hard stuff. "What If" lets kids remove planets or add suns and watch the gravitational impact in real time. "Build Your Own Solar System" lets them place stars and planets wherever they want, then switch to gravity mode and see if their creation survives actual physics.

None of this was in the original spec. All of it came from watching two kids use the first version.

The one part that was genuinely hard to build

Both "What If" and "Build Your Own" depend on gravity simulation. Get the formulas wrong and planets don't stay in their orbits. They fly off the screen. Or crash into each other. Or freeze.

Claude Code wrote the calculations. I verified visually after every build. Planets drifting out of stable orbits. Moons colliding for no reason. Rebuild, test, watch things break, rebuild again. Several iterations before the simulation held.

This was the exception. You can review most code by reading it. You can't review physics by reading it. You have to run it and watch. Every time.

Everything that was actually hard had nothing to do with code

I registered for the Apple Developer Programme. Paid the $99. Waited for the license. Two of my four weekends were just waiting.

Once the license came through, I submitted the app. It got rejected.

Not because of the app. I had included an in-app purchase, a 7-day free trial with a $2.99 unlock, but I hadn't filled in my taxation details and residential status. Apple requires that paperwork before they'll approve anything with an IAP. Nobody tells you this upfront. You find out when you get the rejection email.

Filled in the forms. Resubmitted. Approved.

The IAP itself was a deliberate experiment. I wanted to understand how App Store pricing works across geographies, how trial mechanics function, how the paywall connects to your developer account. I kept it live for about a week, then removed it and made everything free. The app is for my kids. But the process taught me things I couldn't have learned by reading documentation. How IAPs actually work. How Apple's review process actually works. How to push an update to a live app. You learn these things by doing them, not by reading about them.

If you're planning to put an app on the App Store: get your Apple Developer account ($99/year) early. The license takes days, not hours. Fill in every tax and legal form before you submit. If you have an IAP and the paperwork isn't done, Apple will reject you. Review takes a day or two. If you get rejected, read the reason carefully. It's almost always procedural.

Four weekends

Two weekends of building. Two more of waiting, submitting, getting rejected, filling forms, resubmitting, and fine-tuning in between.

The app is called Planetia. Free. iPad only. No ads, no tracking, no accounts. Six ways for kids to mess around with the solar system.

My son is grinding through quiz ranks. My daughter keeps repainting Saturn.

If you've been sitting on an app idea, the thing standing between you and the App Store isn't code. It's the Apple Developer account, the tax forms, the review process, and the patience to deal with all of it. The building part? That's a couple of weekends now.

Download Planetia on the App Store

How I Actually Learned AI (From Someone Who Couldn't Code)

Mon, 23 Mar 2026 00:00:00 GMT

After my last post, a few people reached out asking the same thing. Okay, but how did you actually do it? Where did you start? What did you use?

So here's how it went. The real version, not the one where I pretend I had a plan.

Start with your environment, not a course

The first thing I did wasn't enroll in anything. It was delete things. Games off the phone. Instagram and Facebook, gone. I kept Reddit and Twitter but gutted them down to communities where people were actually building with AI. Subreddits like r/ClaudeAI, r/vibecoding. Twitter accounts of people shipping agents and apps with Claude Code.

Within a few weeks, it started to feel uncomfortable to not be doing it. I was watching people with no more technical background than me ship real products. PMs, designers, marketers. People who three months ago were in the same spot I was. When your feed is full of that and you're standing still, inertia stops feeling like safety. It starts feeling like falling behind.

Your environment will do a lot of the work if you let it.

Three cheap courses, and the method that saved me

I enrolled in three Udemy courses. Each one cost under 500 rupees. I'm not going to pretend I found the three perfect ones. I just picked what looked relevant and started.

Here's what actually worked. I went through each course twice.

First time, fast. Didn't stop when something was unclear. Didn't try to understand everything. Just moved. The goal was to build a mental map of the terrain.

This wasn't some deliberate strategy. It was desperation. These courses assume background knowledge they never explain, then circle back to it three modules later. Trying to follow everything in sequence was getting me stuck. Going fast broke that. By the end of the first pass, I had a rough picture of the whole thing.

Second pass, slow. Side-by-side with Claude Code, actually building as I went. And nothing intimidated me anymore because I'd already seen where everything was heading. The unknown had become familiar.

Build things. Increasingly harder things.

Courses will only take you so far. At some point you have to make something.

My first project was about as small as it gets. A single-page website that called the Anthropic API and took user input. One day, done. That project taught me how to use an API in production and how to deploy to Vercel through Github. Basics. But I didn't know them before that day.

Then I built my personal website. That was a different kind of hard. Not technically complex, but full of design decisions I hadn't had to make before. Multiple pages, real structure, figuring out what goes where and what the whole thing should feel like.

The pixel art game taught me about working with external assets. Game sprites, sound files, things that have nothing to do with code but everything to do with getting a project to feel finished.

Then the iPad app. The building was actually the straightforward part. Getting it listed on the App Store was the real challenge. Provisioning profiles, review guidelines, metadata. An entirely different skill set that no coding course prepares you for.

Each project was harder than the last. But each one was possible because of what I'd learned from the one before it. The whole arc took about eight weekends over two months. Not a year. Not a sabbatical.

Starting small is the correct sequence. If I'd tried the iPad app first, I'd have quit.

The workflow that made it click

The building is manageable. The debugging will break you. When you can't code and something goes wrong, you can't read through the code to figure out why. You're just stuck.

Claude Code is a strong programmer. But when the problem is architectural, when it's about what the code is supposed to be doing, you need more than a good coder. You need a thinking partner who already understands the full picture of what you're building.

I figured this out later than I should have. Early on, I was doing everything inside Claude Code. Concept, build, debug, all in the same place. It was messy. I'd get halfway through something and realize I hadn't thought through a basic design decision.

So I stopped doing both in the same place.

I started using Projects in Claude.ai as my brainstorming space. Before touching Claude Code, I'd work through the full project there. What am I building. What are the components. Where will it probably break. What should I watch out for. Projects keep context across sessions and let you pin important reference files, so I wasn't re-explaining my project every time I came back.

By the end of a brainstorming session, I'd have three files ready. A claude.md with all the context Claude Code needs to understand the project. A prompts.md with the sequence of prompts I'd use to build it step by step. And a handoff.md tying it all together. By the time I opened Claude Code, I had a clear brief. I wasn't figuring out what to build and how to build it at the same time.

And when something broke, I had a brainstorming partner that already understood the full picture. I could describe the problem in plain English and work through it without needing to trace through every line of code myself.

That separation between thinking and execution is what made this work for someone who isn't a developer.

On tools: don't be cheap here

The courses were 500 rupees each. That's where to be frugal.

Start with Claude Pro at minimum. The free tier will frustrate you. You'll hit rate limits right when you're in the middle of something and lose all momentum. If you go deeper and find yourself using it every day, upgrade to Max. That sounds expensive until you compare it to the opportunity cost of not learning this at all. A hundred dollars a month to acquire an entirely new capability is one of the better trades available right now.

None of this required a computer science degree. I'm a product manager. I approached this the same way I'd approach any product problem. Understand the terrain, start small, ship something, learn from it, go again.

The discomfort of being a beginner is temporary. The discomfort of knowing you should be learning and choosing not to is permanent.

But the first time you see your own website live on the internet. Your own app sitting in the App Store. Something you made, that works, that people can actually use. You don't forget that.

Eight weekends. That's all it took.

You Are Not Your Job Title

Wed, 18 Mar 2026 00:00:00 GMT

A few weeks ago, I was talking with colleagues about AI and jobs. Will it take them, won't it, what should people do. Somewhere in the middle of all that, someone said something that stuck.

"The problem isn't losing your job. The problem is that most people don't know who they are without it."

It names something the entire AI-and-jobs conversation keeps skating past.

The deal we all signed up for

Yuval Noah Harari makes this observation in Nexus that puts things in perspective. In the year 1000 AD, a farmer's son was a farmer. His grandson was a farmer. His great-grandson was a farmer. Nobody chose a career because there was no choice to make.

Modern schooling changed the options but not the structure. Starting in the 1700s, kids went to classrooms, picked up trades, entered professions. More variety. But the underlying deal stayed the same: spend your first 20 years learning, spend the next 40 applying what you learned.

That deal held for a remarkably long time. Most of us still operate on it without realizing it.

And it's expiring.

The wrong debate

I'm not going to argue about whether AI takes jobs. That framing misses the point. AI is changing what jobs are. The tasks that made up your role five years ago won't be the same tasks five years from now.

Harari gives this sharp example. A 45-year-old fighter pilot, one of the best, gets asked to train a drone system. He does it brilliantly. Then the drone takes his seat. Not because he was bad at his job. Because he was so good at it that he made himself replaceable.

Now he has to start over. At 45. With 25 years of expertise in something the world no longer needs a human to do.

The economic problem is obvious. But there's a deeper one underneath it that nobody wants to name.

The status trap

People don't resist change because they're lazy or stupid. They resist it because starting over means losing status.

A senior professional with 20 years of experience decides to learn a new skill. On day one, they're at the same level as a 23-year-old fresh out of college. They don't just feel uncomfortable. They feel humiliated. They go from being the person others come to for answers to being the person asking basic questions.

Nobody talks about the humiliation part. But that's the real barrier. Not the learning curve. The ego curve.

I watched this happen with my father. When computers were introduced at his workplace, he couldn't adapt. He was in a government job, so he wasn't let go. But he never got better opportunities either. His career froze while people around him moved ahead.

He didn't lack intelligence. He lacked the willingness to be a beginner again, in front of people who used to look up to him. Being a beginner at 50, asking a 25-year-old how to do something on a computer, isn't a skills problem. It's a status problem. It feels like falling.

So he didn't try. The incentive structure made it rational to stay put, protect what he had, and hope the change wouldn't catch up.

But it did. It always does.

And this is how the trap works. You get good at something. You get recognized for it. Your competence becomes your reputation. Your reputation becomes your identity. And once your identity is welded to a specific skill, protecting that skill starts to feel like protecting yourself.

So when something new comes along, you don't adopt it early. You can't. Early adoption means admitting you're not good at the new thing yet. It means risking the status you spent years building. So you wait. You tell yourself you're being prudent. That the new thing is overhyped. That your fundamentals still matter. But while you're waiting, other people are learning. And a gap opens up.

That's the delayed adoption problem. It's not that people can't learn the new thing. It's that learning it costs them something they're not willing to pay: their position in the room.

And delayed adoption leads to something worse. Identity lag. The technology moves on. The job changes. But your sense of who you are is still stuck in the old version. The world has updated. Your internal operating system hasn't.

Most of us learned our core skill in our early twenties. Got decent by 28. Got good by 32. And then just... kept doing it. More senior titles, more meetings, but nothing fundamentally new. We ran the same operating system for decades and called it experience.

But experience and learning are not the same thing. Experience is doing what you already know in more situations. Learning is acquiring the ability to do something you couldn't do before. Most professionals haven't been a beginner at anything in 20 years.

Why this time is different

What happened to my father with computers was a gentle disruption. It played out over years. People had time, even if most wasted it.

AI is the same kind of revolution at a completely different magnitude. The cycle that took a decade now takes months. The status trap, the delayed adoption, the identity lag -- all of it is going to play out faster than people can process.

That's why "upskill" isn't enough. Every reskilling program, every corporate training, every LinkedIn post telling you to learn prompt engineering treats this as a skills problem. But the bottleneck isn't learning the new skill. It's letting go of the old identity. No training program in the world addresses that.

What actually helps

I can tell you what this looks like from the inside, because I almost fell into the same trap.

I work in product management. For months, I told myself my role was safe. Product thinking is human. Strategy is human. AI can't do what I do. I had all the arguments lined up.

But there was this uneasiness in my chest that wouldn't go away. Deep down, I knew that sitting on past accolades while everything around me was shifting was the worst possible thing I could do. I was doing exactly what my father did. Telling myself the change didn't apply to me.

So I enrolled in a couple of agentic AI coding courses. Went back to being a complete beginner. The first few weeks were humbling in a way I hadn't experienced since my early twenties. I was slow. I was confused. I asked questions that probably seemed obvious to everyone else.

But something unlocked that I wasn't expecting. Not just a new skill. A new way of relating to my own competence. I stopped being a product manager nervously watching AI from the sidelines and became a person actively learning something new. The identity shifted, and the anxiety went with it.

The discomfort of being a beginner is temporary. The discomfort of knowing you should be learning and choosing not to is permanent.

Two generations, one lesson

My father couldn't make the leap when computers arrived. Not because he was incapable, but because the cost felt too high. The status, the dignity, the sense of self he'd built over decades. He chose to protect all of that. I understand why. I nearly made the same choice.

The difference isn't intelligence or willpower. It's whether you see your identity as something fixed or something you can update. My father's generation was never taught that the operating system needed updating. Ours has no excuse.

AI isn't going to wait for anyone to feel ready. The only way ahead is to get comfortable with being uncomfortable. Not by learning the right skill. By becoming the kind of person who can learn any skill, at any age, without needing to be good at it right away.

The Weekend Website: Planning in Claude, Executing in Claude Code

Sat, 31 Jan 2026 00:00:00 GMT

This website went from idea to live in about three days. Four or five working sessions spread across a weekend and a couple of evenings.

I'm not a developer. I can't read code, I don't debug code and I don't write JavaScript for fun. So when I decided to build a personal site, my goal wasn't to learn web development. It was to get something live that I wouldn't be embarrassed to share.

Here's what I actually did.

The real work happened before I wrote any code

I didn't open Claude Code first. I opened Claude.

Inside a project in Claude (the web version), I started describing what I wanted: a place to publish articles, showcase side projects over time, list my speaking engagements. Not a portfolio exactly. More like an experiment playground that I could keep adding to.

Claude asked good questions. What's the site for? Who's the audience? Do you have content ready? It recommended Astro for the framework, suggested a folder structure, and when I mentioned I had rough outlines for a few articles, it helped me finish writing them.

By the time I was ready to build anything, I had a complete content package: three finished articles, an about page, speaking entries, and a reference document with the exact folder structure, page requirements, and design guidelines.

Then I asked Claude to do something that felt almost like cheating.

"Give me the prompts I should use in Claude Code"

I asked Claude to generate step-by-step prompts that I could feed into Claude Code to build what we'd just planned together.

It gave me a markdown file with eight or nine prompts. Phase 1: scaffolding. Phase 2: home page and writing list. Phase 3: add articles. And so on.

The prompts weren't magic. They were just clear. "Create a new Astro project with this folder structure. Clean, minimal design. Mobile-responsive." "Build the /writing page that lists all articles as cards with title, description, category, and date."

I opened Claude Code, copy-pasted the first prompt, and watched it work.

Most of it was copy-paste

That's the part that surprised me. I expected to be debugging, tweaking, going back and forth. Instead, I was mostly just pasting the next prompt.

There were minor adjustments. Sometimes I'd clarify something Claude Code asked about. Occasionally I'd say "actually, make the font size a bit larger" or "move the social links below the tagline." But the structure of the build was already decided. Claude Code was executing a plan, not figuring one out.

The entire scaffolding, all six pages, the article templates, the deployment to Vercel. It followed the script.

Skills emerged from friction

The watermark thing is a good example.

I'd generated images for the articles using Gemini, but they had a small diamond watermark in the corner. I asked Claude Code to crop it out. It tried, said it was done, but when I checked the image, the watermark was still there. Just partially cropped.

So I took a screenshot showing exactly where the watermark was still visible. Claude Code looked at it, adjusted, tried again. Still not quite right. Another screenshot. Another attempt. Three or four rounds before it finally got it right.

And that's when I thought: I'll need to do this for every article. Why not turn this into a command I can reuse?

That's how my first Claude Code skill was born. A one-liner that crops Gemini watermarks from any image in a folder.

The same thing happened with image compression. I'd dumped huge PNG files into the project, 3 to 5 MB each. Fine for my laptop, terrible for the web. I asked Claude Code to compress them. It figured out how to resize and convert to WebP, getting 90%+ size reduction. I made that a skill too.

By the end, I had skills for watermark removal, image compression, and a design QC agent that would screenshot every page at different viewport sizes and generate a prioritized list of issues.

None of these were planned. They just emerged when I hit the same friction twice and thought: this should be a command.

What this site actually is

It's not a portfolio. It's a playground.

The blog is the first project I've deployed here. The next might be a small tool I build while learning something. Or a game. Or an experiment that goes nowhere. The structure allows me to keep adding things without redesigning anything.

The "Projects" section says "Coming Soon" right now. That's fine. It's a placeholder for whatever I build next.

The workflow I'd use again

If I were starting a new project tomorrow, I'd do exactly this:

Start in Claude, not Claude Code. Describe what I want. Let it ask questions. Get the plan, the structure, the content sorted first.

Then ask Claude to write the prompts for Claude Code. Not vague instructions, but actual prompts I can copy-paste.

Open Claude Code and execute. Treat it like a build script with a human checking the output between steps.

When I hit friction twice, make it a skill.

That's it. The site you're reading is the result.

Built with Claude Code. Planned with Claude first.

What 10+ Bosses Taught Me About Exceptional Managers

Fri, 30 Jan 2026 00:00:00 GMT

The secret ingredient isn't being a top performer. It's something most people never talk about.

Fifteen years. Ten-plus managers. Some forgettable, some frustrating, and a few who genuinely changed where my career went.

When I look back at the managers who made the biggest difference, there's a pattern. It wasn't that they were the smartest people in the room. It wasn't their track record. The best ones shared something else: an emotional security that freed them from needing to prove themselves.

Let me tell you what I mean.

The fair credit dictum

Early in my career, I had a manager who was obsessive about one thing: making sure credit went where it belonged.

When a project succeeded, he didn't send a vague "great team effort" email. He named people. He called out who did the hard work, who solved the tricky problems, who stayed late to push it across the line. If multiple people contributed, everyone got mentioned. But the alpha contributors got highlighted.

That wasn't the remarkable part.

The remarkable part was what he did next. He'd take those contributors to meet the CXOs. Not himself presenting the work with his team in the background. Them presenting, him in the background.

At the time, I thought this was generous. Now I realize it was strategic. He understood something that insecure managers never grasp: his success was downstream of his team's success. By giving them visibility, he was building a team that people wanted to join. A team that worked harder because they felt seen. And that made him look like exactly what he was: a leader who could develop talent.

I've carried that lesson ever since. When multiple people contribute, call out all of them. Highlight the ones who carried the weight. Take them to the rooms they wouldn't otherwise have access to.

The mistake meeting

I still remember the dread walking into that conference room.

I had made a mistake. A real one, the kind with downstream consequences. I'd been running scenarios in my head all morning. Would there be shouting? A formal warning? That cold, disappointed silence that's somehow worse than anger?

My manager looked at me and said something I've never forgotten:

"It's okay to make mistakes. Everyone makes them. What's not okay is making the same one twice. That means you're not learning."

That was it. No drama. No drawn-out post-mortem designed to make me feel small. Just a principle, delivered calmly, that I still use today.

What struck me wasn't the words. It was the security behind them. A manager who needs to perform outrage, who needs to make you grovel, is usually managing their own anxiety. This one wasn't. He was focused on the only thing that actually mattered: making sure I learned something.

The other kind

Not all my managers were like this.

We were working on a high-profile, time-bound project. I disagreed with some UX decisions the design head was making. I raised my concerns to my manager, laid out my reasoning, asked for support.

He sided with the design head.

Fine. Managers have to make calls, and sometimes you're wrong. I moved on and executed the decision.

Then the product launched. The UX decisions I'd flagged fell flat. Users struggled with exactly the flows I'd predicted would cause problems.

And in the post-launch review? My manager was suddenly on the other side, pinning the failure squarely on my shoulders. The same decision he'd backed was now my mistake.

That was the day I decided to leave. Not because I was blamed. Blame happens. But because I realized I was working for someone who would never have my back when it mattered. Someone whose own standing was more important than the truth.

The contrast with my good managers couldn't have been sharper. They didn't need to protect themselves at my expense. They were secure enough to own collective decisions as collective decisions, win or lose.

What actually makes the difference

After fifteen years of watching this play out, here's the pattern I see in managers who transform teams:

They have an emotional security that lets them celebrate others without feeling diminished. They don't need to be the smartest person in the room. They don't need every success to have their fingerprints visibly on it.

They're genuinely collaborative. Not as a buzzword, but as a core belief. They've always thought 1+1 can equal 3, whether as individual contributors or leaders.

They get real satisfaction from developing others. Not career-advancement satisfaction, but the kind where they light up when someone on their team figures something out.

And they understand that leadership is a completely different skill from being a high performer. Some people never make this leap. They keep trying to be the best individual contributor in a room full of people they're supposed to be enabling.

My own learning curve

I'll be honest: when I was given responsibility for a sixty-person team across Product, Design, and SEO, I was overwhelmed.

My first instinct was to do what had always worked. Work harder. Be across everything. Prove I deserved the role. I was trying to do too much, and it was burning me out.

Leadership coaching helped. (My manager had arranged it, which itself told me something about the kind of leader he was.) But the real shift was internal.

I had to accept that for me to be successful, my team had to be successful. And for that to happen, I had to stop being the person who did things and start being the person who enabled others to do things. Available when they needed guidance. Not looking over their shoulders when they didn't.

If you say you trust your team, you can't be checking their work constantly. Trust is a behavior, not a statement.

The hardest part for high performers (and I include myself here) is letting go. You got to where you are by being good at things. Now you have to be good at helping others be good at things. It's a different skill entirely, and it requires setting aside your ego more often than feels comfortable.

What to look for, what to become

If you're early in your career, pay attention to how your manager handles these moments:

When you succeed, do they share the spotlight or absorb it?

When you fail, do they focus on learning or on blame?

When they're challenged, do they get defensive or curious?

When you grow, do they seem threatened or delighted?

The answers will tell you whether you're working for someone who will accelerate your career or just use it to accelerate theirs.

And if you're a manager yourself, or becoming one, the question is simpler: have you made the shift from proving your worth to multiplying others' potential?

It's not about whether you were a top performer. Plenty of great leaders weren't. Plenty of star individual contributors become mediocre managers.

It's about whether you've developed the emotional security to not need the spotlight, the instinct to believe in leverage over solo effort, and the genuine interest in watching others grow.

That's the formula I've seen work, over and over:

Emotional security + collaborative instinct + genuine investment in others' growth = leadership that actually transforms teams.

Everything else is just management.

From 7 Hours to 1: My AI Presentation Workflow

Sat, 10 Jan 2026 00:00:00 GMT

Confession: presentations used to be my time sink.

Not the presenting part. The building part. That slow, painful process of staring at slides, wondering why everything looks like it's from 2003.

Then I stumbled onto a workflow that changed how I make decks. Two AI tools that, weirdly, work better together than either does alone.

The problem I was trying to solve

I'd just come back from a two-day industry conference. Twenty-plus sessions, back to back. Our HR team asked me to present a summary of key learnings to the internal team.

My old process for something like this would have been:

Go through my notes. Try to remember what was actually useful versus what just sounded good in the moment. Coalesce everything into a rough outline. Open PowerPoint. Stare at blank slides. Drag boxes around. Hunt for images that aren't embarrassing stock photos. Realize the flow doesn't work. Restructure. Fix the formatting that broke when I restructured. Repeat.

Six to seven hours of dedicated effort, spread across multiple days. For a deck that would get presented once.

There had to be a better way.

The accidental discovery

I'd been playing with NotebookLM for a while. It was this cool tool that could generate podcasts and video summaries from documents you uploaded. Impressive demos, but I hadn't figured out a real use case for it in my actual work.

Then it clicked: I had all the conference materials. Speaker presentations. Session transcripts. What if I just... uploaded everything and asked it to find the patterns?

So I did. Dumped all the files in, gave it some context about what I needed, and asked for 10-ish slides worth of content summarizing the key learnings.

NotebookLM did the heavy lifting. It pulled themes across sessions, identified the insights that kept coming up, and structured them in a way that actually made sense.

Now I had content. But I still needed a deck.

Enter Gamma (after some hesitation)

I'd been hearing about Gamma for months. It kept showing up in my feed as THE AI presentation tool. But every time I opened it, I felt overwhelmed.

Too many options at first glance. Add a gamma (standard? custom?). API integrations. Different generation modes. It felt like the learning curve would be steep, and I didn't have time to figure it out.

But I had my NotebookLM output, and I was curious. So I found the "Paste in Text" feature and just... pasted.

Fifteen minutes later, I had a complete deck.

Not just slides with text on them. Actual designed slides. Custom images that made sense in context (no more generic photos of people pointing at whiteboards). Icons that looked intentional. A visual hierarchy that worked.

The workflow, step by step

Here's what I actually do now:

Step 1: Gather your source material. This works best when you have existing documents to work from. Conference presentations, meeting notes, research reports, competitor analysis, transcripts. The more context you give NotebookLM, the better the output.

Step 2: Upload everything to NotebookLM. Don't be precious about organization. Just dump it all in. NotebookLM is surprisingly good at finding signal in noise.

Step 3: Give it context and ask for slides. I tell it what the presentation is for, who the audience is, and roughly how many slides I want. Something like: "I need to present the key learnings from this conference to my internal team. Give me content for 10-12 slides covering the most important insights."

Step 4: Copy the output and paste into Gamma. Use the "Paste in Text" feature. Gamma will ask you some questions about style and tone. Pick what feels right. (I had to experiment a bit with which settings worked for text-heavy vs. visual content, and which image generation model to use. There's a small learning curve here, but nothing painful.)

Step 5: Review and tweak. This is the part you can't skip. More on this below.

Total time once you know the workflow: about an hour. Most of that is the review and polish, not the generation.

The critical step most people skip

Here's what Gamma gets wrong: data.

If your presentation involves numbers, statistics, quotes, or anything factual, Gamma can hallucinate. It will confidently put a number on a slide that didn't exist in your source material. Or slightly mangle a statistic in a way that looks right but isn't.

If you don't catch this, you end up in an embarrassing situation during Q&A when someone asks where a figure came from.

So: review every slide. Check every number against your source. Read every bullet point and ask yourself if that's actually what the original material said.

The generation is fast. The review is where you earn your credibility.

Other tweaks I usually make

Beyond fact-checking, I typically adjust a few things:

The opening slide often needs a stronger hook. AI tends to generate safe, generic openings. I'll rewrite to make it specific to my audience.

Some slides try to say too much. I'll split them or cut the weakest points.

Image choices are usually good but not always. Maybe one in five I'll swap for something better.

The flow between sections sometimes needs smoothing. AI generates good individual slides but doesn't always nail the transitions.

None of this takes long. Maybe 15-20 minutes of polish on top of the generated draft. Still way faster than starting from scratch.

When this works (and when it doesn't)

This workflow shines when you already have source material. Conference notes, research documents, meeting transcripts, existing reports you need to repackage. NotebookLM is essentially a summarization and synthesis engine, so it needs something to synthesize.

If you're starting with a blank page and an open-ended idea, skip NotebookLM and go straight to Gamma. You can prompt Gamma directly with your concept and it'll generate a first draft. It won't be as tailored, but it's still faster than building from scratch.

And if your presentation is highly data-driven with lots of charts and specific metrics, be extra careful. Or build those slides manually and use this workflow for the narrative sections.

Why this matters beyond saving time

The real value isn't just the hours saved. It's that I actually make presentations now.

Before, the effort required meant I'd avoid decks when I could. I'd send a document instead, or just talk through something verbally. Sometimes that was fine. Sometimes I was leaving impact on the table because the format would have landed better as a visual story.

Now the activation energy is low enough that I'll spin up a deck for things I never would have before. A quick summary for my team. A visual for a point I want to make in a meeting. A shareable version of something that was stuck in my head.

The tools aren't doing my thinking for me. They're removing the friction that stopped me from packaging my thinking well.

Try it yourself

Next time you have to make a presentation and you're dreading the build:

Gather whatever documents or notes you already have
Upload them to NotebookLM
Ask for slide content with context about your audience and goal
Paste the output into Gamma
Review, fact-check, and polish

The first time will take longer as you learn the interface. After that, you'll wonder why you ever did it the old way.

38 Audiobooks in 3 Years: How I Turned a 3-Hour Commute Into a Reading Habit

Mon, 05 Jan 2026 00:00:00 GMT

In 2020, I had twins. In 2021 and 2022, I read zero books.

Not a single one. Between raising two infants during Covid, working from home, and the general chaos of those years, there was no time left for reading. Whatever free moments existed went to sleep. Or staring at walls.

Then my work-from-home ended. And I inherited a 3-hour daily commute between Gurgaon and Noida.

Most people would see that as a problem. I decided to see it as a library.

The shift to audio

I tried physical books first. Even bought a Kindle. But the fundamental problem remained: at home, there was no "me time." Every moment was either work or family. Reading required a kind of quiet focus that simply didn't exist in my life anymore.

Audiobooks changed the equation. Suddenly, the commute wasn't dead time. It was learning time. Three hours a day, five days a week, with nothing to do but drive and listen.

I started with podcasts but found myself constantly hunting for new ones. The discovery tax was annoying. Audiobooks solved that: pick a title, and you have 8-15 hours of content. No hunting required.

From zero books in 2021-22, I've now listened to 38 books over the past three years. And counting.

The comfort food strategy

Here's what I learned early: not every listening session needs to be intellectually demanding.

Some days you're sharp and curious. Other days you're tired, traffic is bad, and your brain just wants to coast.

I started mixing familiar books with new ones. Harry Potter. Sherlock Holmes. P.G. Wodehouse. Books I'd read before or always meant to read. Listening to them was like eating comfort food. Easy to follow, pleasant to revisit, no cognitive strain required.

The new titles — Kahneman's Thinking, Fast and Slow, Harari's Nexus, Cixin Liu's Three-Body Problem — were different. Intellectually stimulating but exhausting. Nutritious food for the brain. I couldn't do them back-to-back without burning out.

Alternating between the two kept the habit alive. Finish something dense, reward yourself with something light. It sounds simple, but it's why I'm still listening three years later.

What worked (and what didn't)

Not every audiobook works in audio format. I've started plenty that I never finished. The reasons usually fall into three categories:

Pacing. Some books are slow. They take forever to build their narrative, meandering through setup and context. In print, you can skim. In audio, you're trapped. A few of these actually made me drowsy while driving — which is when I learned to abandon books without guilt.

Narration. The narrator matters more than I expected. Some are robotic. Some drone. Some have accents that don't click with your ear. And then there's Stephen Fry. His narration of Sherlock Holmes, Mythos, Heroes, and Troy is so engaging that I've recommended those specifically to people new to audiobooks. A good narrator turns a book into a performance.

Visual dependencies. Some books reference charts, graphs, or images constantly. "As you can see in Figure 3.2..." — except I can't see anything because I'm driving. This breaks the experience. I've learned to check reviews for warnings about this before starting.

The books that stuck with me

Out of 38 books, a handful have genuinely changed how I think:

No Rules Rules by Reed Hastings — Netflix's culture of radical candor and talent density. Made me rethink how I give feedback to my team.

The Ride of a Lifetime by Bob Iger — Disney's CEO on leadership. One story about owning mistakes publicly stayed with me so strongly I wrote a separate post about it.

The Remains of the Day by Kazuo Ishiguro — Not a business book. A quiet, devastating novel about a butler reflecting on his life. It hit differently while stuck in traffic, thinking about my own choices.

Thinking, Fast and Slow by Daniel Kahneman — Dense, took me weeks, but the mental models (System 1 vs System 2, anchoring, loss aversion) show up in my work constantly.

The Three-Body Problem trilogy by Cixin Liu — Science fiction that made me feel small in the best way. The scale of imagination is staggering.

The full list

For the curious, here's everything I've finished or am currently working through:

Business & Psychology: The Ride of a Lifetime, No Rules Rules, Thinking Fast and Slow, Atomic Habits, The Art of Spending Money, Outliers, The Man Who Solved the Market, Inspired, The Design of Everyday Things, Poor Economics

Science Fiction & Fantasy: The Three-Body Problem, The Dark Forest, Death's End, The Wandering Earth, Dune, Hitchhiker's Guide to the Galaxy, The Restaurant at the End of the Universe

Literary Fiction & Classics: One Hundred Years of Solitude, Kafka on the Shore, The Remains of the Day, To Kill a Mockingbird, 1984

Philosophy & History: Nexus, 21 Lessons for the 21st Century, Homo Deus, The Rise and Fall of the Third Reich, Caste, Inglorious Empire

Comfort Reads: Harry Potter (Full-Cast editions), Sherlock Holmes (Stephen Fry), P.G. Wodehouse, Mythos, Heroes, Troy

Parenting: How Children Learn, The Book You Wish Your Parents Had Read, You Your Child and School

The mix wasn't planned. It just happened. But looking back, the variety is what kept me going. Heavy book, light book. Fiction, non-fiction. English, Hindi. No rules except: keep listening.

Will it stick without the commute?

Honestly? I don't know.

I've tried listening during morning walks. It hasn't stuck the same way. There's something about being trapped in a car, with no other option, that makes the habit effortless.

If my commute disappears, I'll have to find a new forcing function. Maybe that's the real lesson here: habits are easier when you remove the need for willpower. The commute did that for me. It turned "should I read today?" into "what should I listen to today?"

If you have dead time in your day — commute, gym, chores — and you're not reading as much as you'd like, try audiobooks. Start with something familiar. Mix in something new. Don't feel guilty about abandoning books that aren't working.

And if you want a recommendation for your first one: anything narrated by Stephen Fry.