The funny part is that, in 2024, I believed going to the gym was enough. I wasn’t regular, I wasn’t intentional, and I definitely wasn’t paying attention to what I was eating. I had this delusional logic that if I ran on the treadmill for 30 minutes, then I had earned the right to eat whatever I wanted. I would literally walk out of the gym and reward myself with food, as if the workout existed purely to cancel out my cravings. And I didn’t think this was a problem; it felt normal to me. But in hindsight, I can see how I was basically fighting myself: one step forward in the gym, five steps back in the kitchen :)

And then came 2025, the year I assumed would be different just because the calendar changed, but of course, nothing did. I repeated the same patterns. Same inconsistency. Same food. Same excuses. I kept telling myself I had a “slow metabolism” or “I’ll fix it when life becomes less hectic,” as if there is ever a phase of life where everything magically aligns for you. It was such a copy-paste year that I can barely separate it from 2024; everything blended into this long stretch of wanting results without wanting the responsibility that comes with them.

The turning point, if I can even call it that, wasn’t inspiring at all. It wasn’t a movie moment. No sunrise jog. No emotional breakdown in the mirror. It was much more boring, just a normal day where I suddenly felt tired of listening to my own excuses.

So I started going to the gym more regularly. Not perfectly. Not with a transformation plan. Just… regularly. And for the first time, I didn’t treat it like something separate from my life. I didn’t aim for muscle-building or aesthetics or any big milestone. My only intention was to be more active than I had been before. That was it.

Then slowly, and I mean slowly, I started paying attention to what I ate. I didn’t follow a hardcore diet. I didn’t become a nutrition expert. I simply looked at my portions, asked myself whether I was eating because I was hungry or because I was bored, and cut down on eating outside. I still eat out sometimes, especially because there are days I’m negotiating with him but even on those days, I choose better options. And these tiny decisions started compounding.

What surprised me the most is that I never noticed the progress myself. I’d look in the mirror and see the same person. But people around me started saying, “You look a bit different,” and it’s strange how a casual comment from someone else can suddenly make you realise your habits have actually been working. It made me understand something I had never understood before: your body is changing long before your brain accepts that it is.

But here’s where the real lesson comes in losing fat was not the difficult part. The difficult part was accepting that I needed to live differently if I wanted to maintain anything I gained. That this wasn’t going to be a one-month effort or a “2025 goal.” It had to become a normal part of my life, something I didn’t negotiate with, something that didn’t feel like punishment.

People think fat loss is about motivation or diet charts, but I realised it’s much more about your relationship with life: how you respond to boredom, stress, cravings, comfort, laziness, routine, and all the subtle habits that quietly shape your days.

Today, I’m not in a “fitness era” or a “transformation phase.” I’m simply in a place where my habits are lighter, my choices are intentional, and my body doesn’t feel like it’s fighting me. I’m also more aware, aware of what I eat, aware of when I’m overeating, aware of how much movement I get, and aware of how much control I actually have when I stop overcomplicating things.

I wish someone had told me earlier that you won’t see progress immediately and the real result isn’t the weight you lose, it’s the person you become when you show up for yourself quietly and consistently.

I didn’t play much, only for an hour, but that was enough to see patterns. I had set a clear threshold for myself. Don’t be greedy; stop when the limit is hit. Still, the moment I started winning, I could feel that inner voice whispering, “Just one more chip, maybe this round will change everything.” It was fascinating to notice the temptation in myself and fight it.

But the real insights came from watching others. There was a father-son duo at one table who were not only playing but actively persuading others to join in and bid more. It wasn’t random, as there is a logic behind it. The more players they attracted, the more chances they had to tilt the odds in their favour. It was persuasion, ego and strategy mixed together.

Then there was a couple, very sharp in how they played. The wife was the one placing the bets, and her luck was in full swing that night. The husband barely intervened, just sat back with quiet confidence as if he knew she was in rhythm. It was less about luck and more about how calm and collected she stayed, even under pressure.

On the other end of the spectrum, I saw a silent man who didn’t talk at all. He kept his chips hidden and played each move with laser focus. No emotions on his face, no reactions to winning or losing. It almost felt like watching a machine in human form.

And then, there was my friend. He started light-hearted, laughing, keeping it fun. But the moment he lost a couple of rounds, I could see his ego step in. Instead of slowing down, he began putting in more and more money, determined to recover what he lost. For him, it wasn’t about the cards anymore; it became about proving he could win. Ironically, he did end the night in net positive, but watching him made me realise how dangerous that spiral can be. The win wasn’t the point; it was the way the game had pulled him into a psychological tug of war.

What struck me is how casinos bring out raw psychology in real time:

• Ego pushes people to recover losses at any cost.

• Greed convinces them that one more round might change everything.

• Patience and discipline let a rare few quietly walk away as winners.

• Luck always plays a role, but it’s amplified or wasted depending on the mindset.

I realised it’s not very different from what I see in tech or startups. People chase goals, sometimes logically, sometimes emotionally. Some play for the long term, some for short term highs. Some collapse under pressure, while others treat it as a game of strategy.

I walked out with a small win that night, and the money wasn’t the real win. What stayed with me was how a casino shows human behaviour in its rawest form. In tech, we deal with systems and algorithms breaking under edge cases. In a casino, it’s people who are the systems, and you watch how they react when pressure builds.

For me, the real victory was not giving in to that voice saying, “Just one more chip.” That’s when it hit me, the actual game isn’t with the cards or the dealer. The actual game is always with your own mind.

I legit used to wonder, why do people run? Why are they willingly spending all their energy like that? Bro, you could’ve built a rocket with that much effort. Running made zero sense to me.

Then life changed.

Cut to 1.6 years back, I had just moved to Bangalore. Suddenly, I wasn’t moving at all. Just sitting. Long calls. Back pain. Feeling like I’m 60 at 23. That’s when I forced myself to join a gym.

But sticking to it? That was a whole circus. One week I’m going regularly, next week something happens, some stupid cold, long work hours, mood off, whatever and boom. 3 weeks gone. I had phases where I’d show up 5 days a week and then ghost the gym.

Also, I wasn’t ready to give up my food. Dude, I want to eat ice cream and biryani and all the good stuff without doing math in my head. Why should fitness mean punishment? That was always non-negotiable for me.

So yeah, obviously no results. I was stuck.

Now, back to the running bit.

It wasn’t some inspiring story. My friend used to run, and I was like, “What’s this guy doing so seriously for some marathons?” And then Insta started throwing me reels about runs, medals, and finish lines. And I won’t lie, the medals looked kinda cool. So I thought, okay fine, maybe I’ll try it once.

Did my first 5K last year.

It was exhausting. My legs screamed, my lungs gave up halfway, and by the end, I felt... nothing. No magical transformation. Just wanted to crash on the nearest patch of grass. I thought, “Okay, cool. Done. Never again.”

But somewhere around April-May this year, something in me shifted. I don’t know what exactly, maybe it was a need to feel stable, maybe I was just tired of feeling off-track in life, but I told myself I need something that keeps me moving and grounded at the same time. I didn’t even plan it, it just happened.

Started going to the gym again, this time with a bit more focus. Started fixing my food, not dieting, just being mindful. Trying to make it part of life instead of this “thing I have to do.”

And somehow, I started making it work. I got weirdly into micro-planning. Like, I book my auto at 6:15, leave office at 6:45 (or at least try to), reach home by 7:30, change, and hit the gym by 8. If that fails, I go to the 9 PM class. Sounds chaotic, but it works 80% of the time. And if not, I guilt-trip myself into making it work the next day.

Okay, okay, now finally getting to the part I wanted to talk about from the beginning…

Last month, I randomly signed up for a 5K again (with some colleagues) after doing a few practice runs.

AND BRO IT WAS SO GOOD.

The run, the energy, the crowd, the finish line moment, this time it hit. I was like, okay, maybe this is why people are addicted to it. After that, I did another 5K, alone this time. Put on my shoes, started my playlist, and ran. Felt that same rush again. This time with better timing and pace. Progress!

And today? I did my first 10K.
Let that sink in. TEN. KILOMETRES.

I still can’t believe I did it. Already signed up for another one next week. I’m not even in it for anything other than that feeling of being in flow. Of zoning out completely. Somewhere in the middle of that run, I realised my playlist had switched from “Namo Namo” to “Naina”, and I was literally smiling like an idiot.

It’s weird how running turns into a mini therapy session. You start with tired legs, and by the time you hit 3K, you’re solving life problems. By 5K, you’re rethinking your career goals. And by the time you hit 10K, you’re just vibing, high on endorphins and planning your 5-year roadmap.

That’s been the best part for me: the clarity.

Running hasn’t just made me fit, it’s made me feel more like myself.

So yeah, if you’re someone who thinks running is boring or hard or pointless, I get it. I was there. Still feel that some days. But if you ever feel even slightly curious, just try it. And then try again.

The first run might suck. Second one too. But that third or fourth one? Might just change something.

And even if it doesn’t, you’ll get a sick playlist and maybe some random life clarity out of it.

Now that it’s all over, I’m still thinking about how much fun I had doing something I never thought I’d enjoy this much.

So here’s how those three days went, what I figured out along the way, and a few little things I’d tell anyone grabbing the mic for the first time.

Day 1: Nervous but figuring it out

This day was all about not messing up. I was mostly inside my head, holding the mic right, checking the schedule a hundred times, and trying to remember my first line.

But once I got a laugh or a smile from the audience, something shifted.
That’s when I realised… It’s not about putting on a show. It’s just about being there, with people

✨ Tip 1: Don’t perform, talk. Treat the audience like real people. No one’s expecting perfection, they just want to feel like they’re part of something fun.

Day 2: Wait… this is fun?

By now, I’d settled in. I stopped overthinking, started slipping in jokes, chatting between sessions, and going a little off script. And surprisingly, those bits? They worked.

We played a quiz game. People were engaged. There was energy. It didn’t feel like I was “hosting, it felt like I was part of the fun.

✨ Tip 2: Don’t be scared to go with the moment. Things won’t go exactly as planned and that’s okay. Sometimes, the unscripted parts are the best ones.

Day 3: In the zone (and loving it)

Everything just flowed.
The team backstage was in sync, the transitions were smooth, and I wasn’t thinking too hard anymore, I was just doing it.

What surprised me the most was how much the “quiet” moments mattered.
Those little pauses between things, the short resets, the way you carry yourself when nothing is happening, that’s where a lot of the magic is.

✨ Tip 3: Hold the room, even when you’re not speaking. You don’t always need the perfect line. Sometimes, a pause or a smile does the job.

Looking back, I’m still surprised by how much I enjoyed it.

Being an MC taught me a lot about presence, people, and just trusting myself a little more.
It wasn’t just about speaking on stage. It was about holding space, reading the room, and having fun in between.

I don’t say this often, but I’m really proud of myself for doing it.
I ended up talking on stage for almost an hour across those three days and loved every bit of it. 💛

Let’s just wait one more week.

It sounds responsible. Thoughtful, even. Like you care about quality. Like you're doing the right thing by holding the line a little longer.

But that one week wait? It almost always does more harm than good.

This isn’t about being reckless. It’s about recognising that speed, momentum and real world feedback matter more than polish or internal opinions.

Here’s why:

You Delay the Only Feedback That Matters

When you delay shipping, you’re not just pausing delivery, you’re pausing learning.

Every week that you don’t ship, you’re not getting real feedback. You’re not hearing from users. You’re not validating assumptions. You’re not observing any behaviour.

You’re in a bubble. And the longer you stay there, the worse your instincts get.

Let me tell you about a feature I worked on a while ago. It was basically done, but I thought it needed some UI tweaks. Nothing major, just “a little more polish.” So we waited a few days.

Then design wanted to weigh in. Then someone noticed edge cases in the logic. Then found some edge cases. All valid points but each added a few more days.

When we finally shipped, users weren’t using the feature the way we thought they would. Our assumptions were off. We ended up reworking the entire thing.

Had we just shipped it sooner and behind a flag and to a small cohort, we’d have learned that immediately. We could’ve avoided weeks of overthinking and iterations built on the wrong premise :)

Momentum is a Force. Just Use It or Lose It

Tbh momentum is invisible but it drives everything.

Teams that ship regularly feel alive. There's a rhythm. Energy builds. People are excited. You feel progress. You just see it.

I’ve worked on teams where a feature sits “basically done” for days because someone is waiting for the perfect time to launch. After a while, no one is excited about it anymore. By the time it goes live, it feels like old news.

Perfect doesn’t matter if no one’s using it

This one is simple: users don’t care about how “perfect” something is. They care whether it solves their problem.

You can polish a feature forever, but if no one wants it or if you built the wrong thing, it doesn’t matter. You won’t know until you ship.

Shipping early lets you see what’s working and what’s not. You can always fix rough edges later. You can’t fix a feature that no one’s using because it never shipped.

Internal Feedback Can’t Replace Real Usage

Internal feedback is valuable until it becomes a loop.

Too often, teams confuse alignment with validation. You end up with endless Figma comments, “one more” content suggestion, or a last-minute re-review of UX copy. I once spent two full days navigating a debate about empty state wording.

Internal alignment helps smooth out obvious friction but it can’t tell you what users will actually do.

This doesn't mean you shouldn't focus on delighting users.

How to Ship Fast Without Breaking Prod

“Move fast” doesn’t mean “move carelessly.”

It means being deliberate, focused and outcome-driven. Here's how to ship fast and smart:

• Use feature flags: Ship behind toggles. Release to internal users or beta cohorts. You don’t have to go full 100% right away.

• Break things down: Don’t wait for a feature to be “complete.” Ship pieces that deliver value even if small. Stack wins :)

• Track usage: Ship with analytics. Know what’s being used and how.

• Document the gaps: If something is missing, call it out. Tell users what’s coming if required.

• Build for today: Don't wait for what might be needed in the future. You can always make changes later. But you can't improve something that hasn't been released.

So… Why Are You Really Waiting?

The next time someone suggests holding off another week, ask:

“What exactly are we waiting for?”

If the answer isn’t a critical bug, a user impacting flaw or a real blocker then it’s probably not worth the delay.

You’re not waiting for “the perfect moment.” You’re just… waiting.

So stop and

Ship it.
Then learn. Then improve. Then ship again.

That’s how great products are built not by chasing polish endlessly but by solving real problems in the hands of real people.

But Wait, Does That Mean Quality Doesn’t Matter?

Not at all.

Code quality absolutely matters. It’s the foundation that allows you to move fast safely. Well written, modular, well tested code makes it easier to iterate quickly, fix issues and extend functionality without fear.

But here's the thing: spending too much time perfecting code on its own rarely makes the product better. Trying to make everything perfect too soon can be as harmful as rushing to ship without care.

Instead of aiming for perfect code out of the gate, aim for:

• Clean, readable, testable code that’s good enough to ship.

• Well scoped PRs that are easy to review and also reason about.

• Fast feedback loops that catch real issues very early.

• Monitoring and metrics just to know when something breaks.

Good engineering is about balance.

It’s not speed or quality, it’s speed with quality.

So yes write good code. But don’t let “perfect” code hold you back from delivering value

When I first started using tools like Cursor, Claude or ChatGPT for frontend development, I expected magic. I thought I could just highlight a buggy snippet, slap on a comment like:

Fix this

…and the AI would instantly understand everything: my tech stack, styling conventions, component logic, even the bugs I hadn’t diagnosed yet.

What I got instead? Half working suggestions. Sometimes vaguely helpful, other times flat out broken. It was like working with someone who knew how to type but not how to think.

Then it clicked.

These tools aren’t your senior engineer, they’re your fastest junior hire. They work fast, but you need to be precise.

Everything changed when I started applying prompt engineering principles to frontend work. Here’s exactly how I did it and how you can too.

1. Set the Stage: Provide Context Like You are Pairing

Context is your most powerful tool. Even though Cursor can see your file, it can’t read your mind.

Imagine asking a junior dev to help with a bug and only saying:

"Can you fix this?"

They would stare back at you: What is “this”? What is broken? What’s the expected result?

AI works the same way. It doesn't know your framework, your styling system or whether you’re in a client or server component unless you tell it.

🚫 Bad Prompt:

Fix this useEffect

✅ Good Prompt:

This is a React client component using useState and useEffect.
It fetches user data by ID, but runs twice in development due to React 18 Strict Mode.
Prevent double-fetching. Use a flag or AbortController. No external state management libs.

Why This Works:

• Specifies the environment: React 18 + dev mode quirks

• Defines the goal: fetch only once

• Lists constraints: no state libraries

• Mentions framework and component type

With this, the AI suggested a clean fix: a useRef flag, proper cleanup, and fetch control. It worked first try.

Another Example:

Prompt:

I’m using Next.js 14 App Router with Server Components.
Convert this client component to use a server action to handle form submission.
The form sends name + email and shows a success toast.

Result:

Cursor created a server action, updated the form to useFormState, passed it correctly into the client component and added toast logic using useEffect.

2. Define the Goal: Tell the AI What "Better" Means

“Improve this component” is not a prompt. It’s a hope :). Your idea of “better” might mean:

• More readable

• More performant

• Smaller bundle

• Idiomatic to your stack

Unless you define the success criteria, the AI will make assumptions. And you might not like them.

Vague adjectives = vague output.

Let’s say you have a clunky card component:

<div>
  <div style={{ padding: 10, border: "1px solid #ccc" }}>
    <h2>{title}</h2>
    <p>{description}</p>
  </div>
</div>

🚫 Bad Prompt:

Optimize this component

Result:

AI might add unnecessary flex layout or wrap everything in a grid for no reason and inline more styles.

✅ Good Prompts (with clear goals):

Improve readability and styling. Use Tailwind.
Add padding, shadow, rounded corners, and hover transition.
Make it responsive and mobile-friendly.

Result:

<div className="max-w-sm p-4 rounded-lg shadow-md bg-white hover:scale-105 transition-transform">
  <h2 className="text-lg font-bold">{title}</h2>
  <p className="text-gray-600">{description}</p>
</div>Each of these tells the AI:

Why this works:

• Mention multiple axes:

  • "Use Tailwind" - you tell it how to style

  • "Improve readability" - guides semantic naming

  • "Add hover transition" - you define UX behavior

  • "Responsive" - it might add max-w, sm:, md: classes

In short: you removed ambiguity.

3. Split Complex Tasks Into Promptable Steps

Don’t ask the AI to build Rome in one prompt. Think like a developer: break features into components.

Prompt like you write code: component-first, feature-later.

🚫 Bad Prompt:

Build a responsive product list with filters, search, sorting and pagination

The AI would:

• Add everything into one massive component

• Mix up loading and UI logic

• Miss the styling system I used (Tailwind)

✅ Good Prompts (step by step)

Step 1: Basic fetch

Create a component that fetches products from /api/products and displays them

const [products, setProducts] = useState([]);
const [loading, setLoading] = useState(true);

useEffect(() => {
  fetch('/api/products')
    .then(res => res.json())
    .then(setProducts)
    .finally(() => setLoading(false));
}, []);

Step 2: Search

// Add a search input that filters products by name (case-insensitive)

const [query, setQuery] = useState("");

const filtered = products.filter(p =>
  p.name.toLowerCase().includes(query.toLowerCase())
);

Step 3: Sort

// Add dropdown to sort filtered products by name (A-Z, Z-A)

const [sortOrder, setSortOrder] = useState("asc");

const sorted = [...filtered].sort((a, b) => {
  return sortOrder === "asc"
    ? a.name.localeCompare(b.name)
    : b.name.localeCompare(a.name);
});

Step 4: Pagination

// Add pagination: 10 items per page, with next/prev buttons

const [page, setPage] = useState(1);
const itemsPerPage = 10;
const paginated = sorted.slice((page - 1) * itemsPerPage, page * itemsPerPage);

Why this works:

• Smaller prompts are easier for the model to handle

• Easier for me to review and test each change

• Reduces the chance of logic errors or inconsistent code

This is how you would break it into Jira tickets. Prompting works the same way.

4. Use Behavioral Examples and Edge Cases

One of the most underrated prompt patterns is giving examples. Adding example inputs and outputs turns your prompt into a contract.

❌ Bad Prompt

Format this number into currency

✅ Prompt (Use TDD-Like Prompts)

Create a formatPrice(amount) function:
Input: 12.5 -> Output: "$12.50"
Input: 5 -> Output: "$5.00"

❌ Bad Prompt

Add a search bar

✅ With Edge Case:

Add a search input that filters products by name.
Case-insensitive. If query is "mob", it should match "Mobile", "MobX", etc.
If no matches, show "No results found".

Now the AI:

• Uses toLowerCase() for comparison

• Adds empty-state UI

• Handles common edge cases automatically

Why This Works:

AI tools tend to overlook edge behavior unless explicitly prompted. Guardrails matter.

5. Use Roles to Shift Quality

Prompt the AI to take on a role. You will often get a shift in tone, architecture, and quality.

Act like a senior React developer. Review this component for potential bugs or anti-patterns.

Or

You're a mentor explaining this useEffect logic to a junior dev. Add comments line-by-line.

This usually makes the AI:

• Explain itself better

• Write clearer code

• Catch things it otherwise skips

Another Favourite:

You are a Tailwind expert. Rewrite this JSX with clean, utility-first styling and responsive behavior.

It uses flex, gap, max-w, hover: and other best practices not inline styles or CSS classes.

Takeaway: Prompting = Product Thinking

At its core, writing great prompts is no different from writing great specs or tickets:

• Be clear

• Define success

• Think in steps

• Handle edge cases

• Communicate like a teammate

AI isn’t here to replace good engineers, it amplifies great ones. Treat your AI assistant like a sharp new hire: fast, eager but needing direction.

The clearer you are, the better the code gets.

So I wrote down some notes and thoughts that stayed with me. Sharing them here in case someone else finds them useful.

1. Start with the Customer and Work Backwards

This is a big one. It’s actually where the book and the blog gets its name. The idea is that you don’t start with a business idea or a technical solution, you start by deeply understanding the customer’s problem.

What do they need? What’s frustrating them? What would make their life easier?

Then, once you have figured that out, you work backwards to build a solution. You think about what kind of product would solve that, how to make it happen within your own limitations (team, time, money, tech) and then go from there.

It’s a simple concept but very easy to forget. A lot of teams (and I have done this too) just build things because they can, not because someone asked for it or needed it.

2. Obsess Over the Customer

At Amazon, they are not just “customer-focused”, they are obsessed. It’s a mindset where every decision is rooted in how it will affect the customer.

And it’s not always about asking customers what they want. Sometimes customers don’t even know. It’s about digging deeper.

What are their pain points? What do they complain about quietly? What slows them down?

For example: if you are building an online form and 20% of people drop off halfway, you don’t just say “that’s normal”, you ask why. Is it too long? Confusing? Annoying? That’s where customer obsession kicks in. You fix the little things that people didn’t even know could be better.

3. The bar raiser thing

One hiring practice they talk about is this idea of “raising the bar.” Basically, every person you hire should be better than the average current team member in at least one meaningful way.

Not better at everything. Not perfect. But they should bring something new, something they are great at. Maybe it’s design, maybe it’s speed, maybe it’s empathy. It keeps the team growing and evolving.

I really liked this. Not because it’s about hiring “only the best” (whatever that means) but because it’s about thinking hard about why someone should join your team and how they make it better.

4. Single-threaded ownership

This one made a lot of sense to me. The idea is simple: if something’s important, give it a single owner. One person whose full time job is to make sure it succeeds.

Too often, we spread things across 3 different teams, or assign it to someone already juggling 5 other things. Then we wonder why it moves slowly or gets stuck.

Giving one person full ownership and the freedom to focus, just works. It brings clarity and accountability. If something matters, it should have a name next to it.

5. PR/FAQ method

One of their most famous practices is writing a fake press release and FAQ before building a product.

The press release explains what the product does, why it matters, and how it helps the customer as if it’s already launched. The FAQ then answers common questions and challenges, like how it works, what might go wrong, or what edge cases need to be handled.

This is such a smart exercise. It forces you to think from the customer’s point of view and make sure the product is even worth building before you get too deep.

It’s also a great way to align the team. Everyone reads the same doc and understands the vision upfront.

6. Input vs output metrics

This part hit home. Most of us track output metrics things like revenue, user growth, engagement. But Amazon puts a lot more focus on input metrics, the things you can control that lead to those outcomes.

For example: if your goal is more signups, don’t just look at the signup number. Look at things like page load time, how clear your CTA is, whether people drop off at step 2. These are inputs you can act on.

Fixing those leads to better outputs naturally. It’s more actionable and more motivating.

7. The flywheel idea

There is this flywheel diagram Jeff Bezos drew back in the day. It shows how improving one part of the business feeds into others.

• A better customer experience brings more traffic

• More traffic attracts more sellers

• More sellers means better selection

• Better selection improves experience

• And around it goes

It’s this loop that feeds itself. The key is identifying what your version of that flywheel is and figuring out which part you can push to make the whole thing spin faster.

The book ends on a very real note. You don’t need to do everything Amazon does. In fact, you shouldn’t.

But you can take the ideas that make sense for you. Try them out. Adapt them to your team, your culture, your goals. Whether that’s writing PR/FAQs, focusing more on input metrics or just asking better questions.

If you have read Working Backwards too, would love to hear what you took away from it. And if you haven’t read it yet, it’s definitely worth picking up.

Okay, full disclosure: I had no plans to write this. I was supposed to be working on a blog about my solo trip (which is still just a folder of photos, honestly) but instead, I ended up explaining React and Next.js to my cousin over the weekend. He was super curious about how stuff like useState and server-side rendering actually works. I grabbed a pen, sketched things out and it clicked for him. That moment that “aha!” made me think, hey, maybe this could help others too.

So this blog is more of a brain dump. If you’re someone who knows React but wants to understand why things work the way they do, this is for you.

What Happens When You Write React Code?

Let’s start with what you actually write:

function App() {
  return <h1>Hello, World!</h1>;
}

It might feel like HTML inside JavaScript but this is actually JSX. And JSX isn’t something the browser understands directly, it gets converted by a compiler (like Babel) to a function call:

React.createElement('h1', null, 'Hello, World!');

That call creates a React element, not an actual DOM node basically just a plain JavaScript object that describes what you want on screen:

{
  type: 'h1',
  props: {
    children: 'Hello, World!'
  },
  key: null,
  ref: null
}

This is React's Virtual DOM, a lightweight, in memory representation of your UI. React holds onto this to later figure out what needs to be updated in the actual DOM.

What Actually Happens When a Component Renders?

Consider:

function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

Here's what happens:

1. React renders the component, calling it like a function.

2. It sets up internal tracking via hooks by an internal "dispatcher".

3. When useState runs, it checks if it's the first render or a re-render and either initializes state or returns the latest.

4. When you click the button, setCount triggers a re-render.

5. React compares the new return value with the previous one and applies only the changed parts (we will talk about that in reconciliation).

Class Components:

class Counter extends React.Component {
  state = { count: 0 };

  increment = () => {
    this.setState({ count: this.state.count + 1 });
  };

  render() {
    return <button onClick={this.increment}>{this.state.count}</button>;
  }
}

Same idea, more boilerplate. Internally, React assigns an updater to manage setState, which schedules a re-render.

Class components give you lifecycle methods but they have largely been replaced by useEffect, useLayoutEffect etc in modern apps.

Reconciliation: The Diff That Keeps Things Fast

This is where things get fun. Reconciliation is React’s algorithm for updating the UI efficiently.

Why does this matter?

DOM operations are expensive. So rather than refreshing the whole page (like jQuery used to do), React compares what’s changed and only touches those parts.

How it works:

1. A component’s state changes.

2. React re-renders that component and builds a new tree of React elements.

3. It compares this new tree with the old one.

4. React calculates the minimum number of operations to apply to the DOM.

5. Only the changed nodes are updated.

This process is called diffing and it’s fast O(n) because React uses some smart assumptions:

• Elements with the same type get updated.

• Keys help identify elements in a list.

• If keys or types change, React assumes it’s a new element.

Real example:

<ul>
  {items.map(item => <li key={item.id}>{item.name}</li>)}
</ul>

With stable keys, React knows which list items were removed, moved or added.

This optimization is why React apps feel snappy.

The Rendering Pipeline in React

Here’s how rendering flows:

1. JSX turns into React elements

2. React creates or updates the Fiber tree

3. Fiber nodes map to real DOM nodes via react-dom

4. DOM updates are batched and applied

React renders in two phases:

• Render phase: pure, no DOM mutations

• Commit phase: applies DOM changes, runs effects

The Fiber architecture enables React to pause and resume rendering, key to features like Suspense and Concurrent Mode.

Where Next.js Comes In

React doesn’t care where it renders. Browser, native, terminal? It just gives you the virtual DOM.

But when you want:

• SEO

• Server rendered pages

• Static pages with dynamic data

...you need more. That’s where Next.js shines.

What Next.js Adds

• Server-side rendering (SSR)

• Static site generation (SSG)

• File-based routing

• Built-in API routes

• Image optimization

It’s not just a framework — it’s an opinionated toolkit that works with React to make your life easier.

Traditional SPA (React only)

1. Server returns a mostly empty HTML shell

2. JS bundle loads

3. React mounts and fetches data

4. UI finally appears

With Next.js (SSR)

1. Server renders full HTML page with data

2. User sees meaningful content immediately

3. React hydrates it in the browser

What’s Hydration?

Let’s say you server render a page. The user gets full HTML: content, structure, everything.

But it’s not interactive yet.

Hydration is the process of attaching React’s logic i.e event listeners, hooks, state to that HTML. It turns your static HTML into a live React app in the browser without re-rendering the DOM.

This is possible because Next.js sends a JSON blob:

<script id="__NEXT_DATA__">{ props, paths, page info }</script>

This contains the props returned by getServerSideProps or getStaticProps, letting React "catch up" with what’s already on screen.

⚠️ If hydration fails (due to mismatch), React logs warnings and may re-render.

Things You Can't Do on the Server

Server rendering has limits. You are in a Node.js environment, not a browser. So:

• No window, document, localStorage

• No user event handlers

• No CSS media query logic

• No DOM measurements (like getBoundingClientRect())

If you need those, defer them to useEffect() which only runs on the client.

Next.js Rendering Modes

This flexibility lets you choose performance or freshness depending on your page needs.

Final Thoughts

React gives you the tools to build UIs efficiently with declarative, component-driven code. It abstracts the pain of DOM manipulation and makes state management predictable.

But when you need a full-fledged web app with performance, SEO and server integration, you’ll want a framework like Next.js.

Next.js doesn’t replace React. It completes it.

Want to turn this into a series or go even deeper into Suspense, useTransition or how the React scheduler works? Let me know.

Also yes, that solo trip blog is still coming. Probably. Eventually :)

Backend? That was someone else’s job. But then, I had to make a backend change.

At first, my instinct was to ask a backend developer for help. But then, I thought—how hard could it be? After all, we have AI now, right?

I was working on the onboarding flow for job seekers, ensuring we fetched relevant data from their preferences and resumes. We already had a service extracting skills from resumes, so all I had to do was send one more extra field. It sounds simple enough.

I wrote the code, pushed the changes, and tested it locally. It worked! But something about it fascinated me. Instead of just moving on, I wanted to really understand what was happening under the hood. That curiosity pushed me deeper into Rails.

The Mistakes I Made (And What They Taught Me)

I opened the codebase, trying to approach it from a JavaScript developer’s mindset. I looked for familiar patterns, if-else statements, function calls and data manipulations.

My first instinct was: "Let me write this from scratch."

1. Where’s My Object?

I initially wrote something like this:

resume = HackerResume.where(hacker_id: current_hacker.id, active: true)

I assumed where would return a single object, just like find in JavaScript. But nope! where returns an ActiveRecord relation (basically, an array). What I actually needed was:

resume = HackerResume.find_by(hacker_id: current_hacker.id, active: true)

Always check whether a method returns an array or a single object. where is great when expecting multiple results, but for a single record, find_by is the way to go.

2. I Forgot to Import the Model

Everything seemed fine, but then I hit a NoMethodError. Rails was telling me that HackerResume was undefined. I was confused because I saw it being used elsewhere in the code.

After some digging, I realized I had forgotten to import the model in the file where I was using it. I had to manually require it in my case.

include Community::Apply::ResumeHelper

3. job.skills Didn’t Work

I expected job.skills to return the skills associated with a job. But instead, it threw an error. Why? Because job was a hash, not an Active Record object!

Instead of this:

job_skills = job.skills

I had to do:

job_skills = job['skills'] || []

In Rails, hashes and ActiveRecord objects behave differently. Always check whether you're working with a model instance or raw data.

4. Loop Didn’t Update the Array

I tried using a loop similar to JavaScript’s forEach, assuming it would update my array:

active_jobs.each do |job|
  job_skills = job['skills'] || []
  missing_skills, _, matched_score, matching_skills = matcher(job_skills, current_hacker.id, job['job_url'])
  job['matched_score'] = matched_score
  job['matching_skills'] = matching_skills
  job['missing_skills'] = missing_skills
end

But it didn’t update active_jobs. I learned that, unlike JavaScript modifying elements inside .each in Ruby doesn’t update the original array.
Instead, I had to use .each_with_index and update the array manually:

active_jobs.each_with_index do |job, index|
  job_skills = job['skills'] || []
  missing_skills, _, matched_score, matching_skills = matcher(job_skills, current_hacker.id, job['job_url'])

  active_jobs[index] = job.merge({
    'matched_score' => matched_score,
    'matching_skills' => matching_skills,
    'missing_skills' => missing_skills
  })
end

What I Learned About Rails and Ruby

At first, I thought of Rails as just another framework with its syntax. But the more I worked with it, the more I realized that Rails is built on Ruby’s unique strengths. To get better at Rails, I needed to understand Ruby first.

Rails follows a philosophy called Convention over Configuration, which means developers follow a set of predefined rules instead of writing repetitive configurations. This makes development faster but can be confusing if you don’t know the conventions. More on Convention over Configuration.

Some key things I learned:

• Ruby Methods Are Flexible – Unlike JavaScript, Ruby allows default values, named arguments, and dynamically defined methods.

• Blocks, Procs, and Lambdas – These allow Ruby to handle functions in different ways, often used in Active Record scopes and callbacks. Guide on Procs & Lambdas.

• Rails Uses Metaprogramming – This allows Rails to dynamically define methods, reducing repetitive code. Understanding Metaprogramming.

• Symbols Are More Efficient – :symbol is more memory-efficient than "string", which is why it’s commonly used in Rails.

• Enumerable Methods Make Things Easier – Built-in methods like map, select and reduce made handling collections much simpler. Enumerable Methods in Ruby.

• ………………This all happened just last week, so I haven't had much time to read more but I would love to explore more of its magic!

My Takeaway

What started as a simple task of adding some fields turned into a deep dive into debugging, reading documentation and learning the internals of Rails. Tbh, I just wanted to get the job done. But the more I explored, the more I appreciated the elegance of Ruby and Rails.

Looking back, my mistakes were lessons. They forced me to read source code, experiment, and understand concepts rather than just making things work.

Now, I feel a little confident diving into the backend world. And the next time I need to write Rails code, I won’t just be copying and pasting, I will actually know what I’m doing :)

Nobody Tells You How to Handle the Shit Storm

You know that feeling when everything's on fire, and you're like "I have no idea what I'm doing"? Yeah, that's actually normal. Here's the deal:

• That time when your star developer storms in saying they're quitting? No playbook.

• You have to choose between fixing technical debt and shipping that feature your biggest customer needs.

• When your team is burning out but the company needs that critical release.

Nobody has it all figured out. We're all just trying our best not to mess up too badly.

Just like how he had to figure out how to save Loudcloud during the dot-com crash, you'll have to make tough calls with incomplete information.

The Truth About Technical Decisions

Here's something nobody tells you: Sometimes all your options are bad and you still have to pick one. Like when:

• You have to choose between fixing that scary bug or shipping the feature that keeps the lights on

• Your best engineer wants to rewrite everything (but you really can't afford that right now)

• Your team needs a break but the deadline isn't moving :)

Just make the call, own it and move on. Sitting on decisions usually makes things worse.

And when you are in the trenches, remember: There is no silver bullet — only lead bullets. Meaning? There is rarely a magical fix. Most of the time, you have to grind through the hard stuff, make incremental improvements and keep pushing forward. No shortcuts, just doing the work.

The "Peacetime CEO vs Wartime CEO"

This was eye-opening. You've got to be a different kind of leader depending on what's happening:

Peacetime Engineering Leader:

• Sure, let's try that new framework everyone's excited about

• Take time to make things pretty and clean

• Let people experiment and learn

Wartime Engineering Leader:

• Ships code that works, even if it's not pretty

• Focus on keeping the business alive

• Sometimes you gotta do the ugly thing to survive

I have lived this transition and both modes required different mindsets and different types of courage.

People > Process

As engineers, we love our processes – our pipelines, our code review process, our architecture decision. But people matter more than processes.

Real example: I once saw a team stick rigidly to their "no deployments on Friday" rule, even when a simple one line fix could have prevented weekend customer issues. The process became more important than the people so smart teams know when to bend the rules.

New Stuff I Learned the Hard Way

These weren't in the book but man, I wish someone had told me:

• Trust your gut when someone's not working out - you probably noticed the signs months ago

• Document the weird stuff - you'll thank yourself later

• Sometimes saying "I don't know, let me figure it out" is the best answer :)

• Your mental health actually matters - you can't help anyone if you're burned out

• Building trust with your team is like putting money in the bank - you'll need it someday

Practical Stuff That Helps

Some real, practical things that make life easier:

• Keep a "wins" folder for tough days

• Write down the hard decisions you make and why - helps when you doubt yourself later

• Find other leaders to talk to - seriously, this helps so much

• Learn to spot the difference between "uncomfortable" and "wrong"

• Take walks when things get intense - helps more than you'd think

Look, I feel leadership is messy. It's personal. It's hard. And that's actually okay. The goal isn't to be perfect – it's to be a little better at handling the chaos each time.

Remember this: Everyone you look up to was once where you are, figuring stuff out, making mistakes, and wondering if they're cut out for this. They made it through. You will too.

P.S. When all else fails, remember: This too shall pass. Usually. Probably. Eventually.

Will users care about this feature? 😬

As an engineer, I can tell you that building features people love isn’t about throwing in fancy tech or quirky ideas and hoping for the best. It’s about understanding what users really need and then delivering it in a way that makes them say:

This is exactly what I wanted! 😍

Think of it like making chai (or coffee, if that’s your thing). You have got to balance the ingredients just right. Too much sugar → it’s undrinkable; too little → it’s bland.

The same goes for features: they need the functionality, usability and a little spark of joy (not you vaasavi 😜). Oh and don’t forget, there’s no magical chai recipe that works for everyone. You have to experiment, taste and adjust.

In the world of product development, the recipe looks like this: decide, build, test, launch and repeat...

Decide 🧐

Every successful feature starts with understanding your users.
What bugs them?
What tiny, everyday annoyances are they begging you to solve?
Surveys, interviews, analytics — use all the tools you can to dig deep into their world. And when you’ve got a million ideas, don’t get distracted. Prioritize the ones that will make the biggest difference.

Your mantra here? Impact over fluff :)

Build 🛠️

Here’s where the engineering fun begins. Start with an MVP.
Yes, because even the first version should feel like something worth showing off.

Don’t aim for a shiny, all-singing, all-dancing feature right out of the gate.
Solve the core problem first, then leave room to grow.

Test 🧪

Think your feature is done?
Haha! Testing is where the real learning happens.

Roll it out to a small group, get their feedback and watch how they actually use it. Just letting you know, they won’t use it exactly how you imagined. That’s okay. Tweak it. Iterate. Rinse and repeat.

Launch 🚀

Time to shine! But don’t just quietly release it — celebrate it! Use emails, in-app banners, or even a cheeky social media post to let users know why this feature is awesome.
Make them feel like this was built just for them (because well it was).

Repeat 🔄

Here’s the catch: you are never really done. After launch, track how people are using the feature. Look at the data. Read their feedback. Figure out what’s working and what’s not and then improve it.
Think of it as a never-ending cycle of awesomeness.

Okay, now enough theory.

Let’s look at some real-world examples of companies that nailed it. These are stories of features that started as ideas, went through the messy process of creation and came out the other side as user favourites 🌟.

1. Duolingo’s Streak Feature 🦉

The Problem: Learning a new language is hard, and people often lose motivation after just a few days.

The Solution: Duolingo introduced streaks: a gamified way to reward daily practice. Each day you learn, your streak grows. Miss a day? It’s gone. (unless you use a streak freeze)

How They Built It: The team realized users needed something to keep them coming back. Streaks tapped into a simple principle: people love consistency and hate breaking a winning streak. Early testing showed users were devastated when they lost their streaks, so Duolingo added streak freezes. The result? Users stayed motivated without feeling punished.

Impact: Streaks turned Duolingo into a daily habit for millions. It’s so popular that users brag about their streaks on social media. Free marketing, anyone?

2. Slack’s “Do Not Disturb” Mode 😴

The Problem: Notifications were driving users crazy, interrupting their focus and causing stress.

The Solution: Slack added a Do Not Disturb mode, letting users pause notifications when they needed quiet time.

How They Built It: Slack started by talking to users who were overwhelmed by constant pings. They built a simple, intuitive way to snooze notifications, with options for recurring schedules. Early testers loved it, and Slack fine-tuned it based on their feedback.

Impact: Do Not Disturb became a lifesaver for users juggling collaboration and deep work. It’s now one of Slack’s most-loved features, proving that sometimes, less noise is more.

3. Airbnb’s Experiences 🏡

The Problem: Travelers didn’t just want a place to stay, they wanted authentic, local experiences.

The Solution: Airbnb launched Experiences, a platform for booking unique activities hosted by locals. Think pasta-making in Italy or surfing lessons in California.

How They Built It: Airbnb started by asking travelers what they wanted most. They piloted the feature in a few cities, collected feedback and refined it. They focused on making it easy for hosts to sign up and for users to book activities seamlessly.

Impact: Experiences turned Airbnb into more than a lodging app. It became a go-to travel platform, attracting a new audience and creating memorable trips for millions.

4. Spotify’s Discover Weekly 🎶

The Problem: Finding new music is overwhelming. Users wanted personalized recommendations without the hassle.

The Solution: Spotify created Discover Weekly, a playlist updated every Monday with tracks tailored just for you.

How They Built It: Using ML, Spotify analyzed your listening habits and matched them with others who share similar tastes. They tested the feature with small groups, refining the balance between familiar favorites and surprising discoveries. And to keep users hooked, they made the playlist refresh every week.

Impact: Discover Weekly became an instant hit. Users loved waking up on Mondays to a fresh batch of songs. It drove engagement, made Spotify feel esstential and turned Mondays into something to look forward to :)

Conclusion 💭

Building features users love is a mix of understanding their needs, experimenting, and improving constantly. The above success stories show what’s possible when you combine empathy with innovation.

So what’s your next big idea? The world’s waiting for it.

• “Do you think it’s a good idea?”

• “Would you use something like this?”

• “How much would you pay for X?”

But here is the thing — people want to be nice. Even if your idea isn’t great, they will try to be encouraging. I have been there and it’s super easy to confuse polite nods with genuine market validation.

The Time I Messed This Up

Once, my team and I were working on what we thought was a game changing feature. To kind of validate our idea, we reached out to an influencer for feedback. But instead of letting them share their thoughts, I blurted out:
“Do you think this idea fits the market?”

Their response?
"Yeah, I think there’s scope to it.”

I was thrilled! But looking back, they were probably just being polite (or worse, saying what I wanted to hear). That’s when I stumbled upon the book The Mom Test by Rob Fitzpatrick.

This book was a game-changer for me. It taught me how to approach conversations in a way that uncovers truth, not compliments. And yes, I realised how much I’d been doing it wrong.

What is The Mom Test?

Imagine asking your mom if your business idea is good. What’s she going to say?
“Of course, sweetie! You’re a genius!”

She loves you, so she’ll lie. The same goes for friends, colleagues and anyone who doesn’t want to hurt your feelings. The Mom Test teaches us to ask questions that make it impossible for someone to lie.

What I Learned from The Mom Test

Here’s what I learned (and wish I knew earlier):

1. Avoid Asking Leading Questions
Bad question:

“Do you think this idea will sell?”
People will nod just to be nice.

Good question:

“How do you currently solve this problem?”
This digs into their existing behavior, not their imagination.

2. Focus on Actions, Not Opinions
Bad question:

“Would you pay for this feature?”
They might say yes to avoid awkwardness.

Good question:

“When was the last time you paid for a similar product? What made you pay for it?”
Now you’re uncovering behavior.

3. Ask About Specific Experiences
Bad question:

“Do you think this app idea is cool?”
Coolness doesn’t guarantee adoption.

Good question:

“Can you walk me through the last time you tried solving X?”
This gives you insight into real challenges and workarounds.

In short:

👉 Don’t ask for opinions. Instead, ask about experiences and actions.

How to Ask the Right Questions

Here’s a cheat sheet for productive conversations:

• To understand a feature request:

  • Why do you want that?

  • How are you coping without it?

  • What would it let you do that you can’t do now?

• To explore emotional pain points:

  • Why haven’t you fixed this yet?

  • What’s the most frustrating part of your current solution?

• To validate a solution idea:

  • When was the last time you tried solving this X?

How to Have Better Conversations

1. Start Broad, Then Zoom In
   Begin with open ended questions to get the full context.
   ex:“Can you walk me through your day-to-day process for X?”

2. Focus on Past Actions, Not Hypotheticals
   Instead of asking what they would do, ask what they have done.

3. Pay Attention to Emotions
   Ask how they felt about specific experiences. Frustrations often highlight opportunities.

4. Ask for a Commitment
   If someone truly believes in your idea, they will show it — by introducing you to someone, signing up for a trial or pre-paying.

What Not to Do

• Don’t Pitch: When you pitch, you’re looking for approval, not insights.

• Don’t Chase Compliments: A “this sounds cool” won’t help you build a product.

• Don’t Convince: If your idea is good, it’ll stand on its own.

Wrapping Up

Building something meaningful starts with understanding real problems — not chasing compliments. The Mom Test taught me to approach validation like debugging code: ask the right questions, look for patterns and test assumptions.

Validation isn’t about hearing “yes”. It’s about uncovering the truth — even if it’s not what you hoped for.

Your ideas deserve it. 🙌

• Are users engaging with our features? 🤔

• Where are they encountering difficulties? ⚠️

• How can we enhance their experience? ✨

Here’s a guide on making analytics work for you as an engineer.

Skipping Analytics ❌

One of the biggest missteps is deciding not to add analytics to certain features. This can happen when we feel the data is unnecessary or just eager to ship a new feature. But skipping analytics is like launching a rocket without tracking — it leaves us in the dark about user behaviour.

Adding analytics, even if it seems small, is like putting markers along a path. It gives you data to look back on, helping you see what's working and what isn't.

Using Multiple Analytics Tools 🛠️

With growth, it’s tempting to introduce new tools for each product segment. In my experience, however, this can create more problems than it solves. Initially, we used Plausible and Umami for different small products and Redash for community insights. Each tool had its way of storing data, making it challenging to gather a unified view.

Challenges with Multiple Tools:

• Inconsistent Data 📊: When using multiple analytics tools, each one tends to track and store data in its unique way. This inconsistency can lead to difficulties in obtaining a cohesive and aligned understanding of the insights.
  For example, one tool might track user engagement one way, while another does it differently, leading to reports that don't match up and are tough to piece together.

• Higher Maintenance ⚙️: Managing multiple tools takes more effort and resources. Each tool might need regular updates, configuration changes, and troubleshooting, which can make your workflow feel scattered.

  This approach can slow down how quickly you analyze data and apply insights because you spend time jumping between different platforms and making sure each one is working properly.

• Confusion 🤷‍♂️: When data is spread across different tools, it can confuse team members. This makes it hard for teams to trust the data because differences between tools can cause doubts about accuracy.

  This makes decision-making harder, as teams might be unsure about using insights that don't come from a single, reliable data source.

Tip: Stick to just one or two trusty tools for collecting data across your products. It'll save you loads of time and make it way easier to use your insights.

The Learning Curve 📈

The first time I wrote a query, it felt overwhelming, especially since I am primarily a front-end developer. I remember starting with something simple like:

SELECT * FROM h_hackers h WHERE h.email = "notgoingtosharepublicly@gmail.com"

That query took forever to run because I had no clue which fields mattered. At first, every query felt like a struggle — lots of trial and error with table names, fields and joins. But once I got the hang of SQL, I could explore data on my own, spot patterns, and get answers way quicker.

Why Learning Queries Matters:

• Saves time waiting on the analytics team (if present).

• Gives direct access to insights that may be buried in dashboards.

• Lets you troubleshoot product issues independently.

Understanding User Perspectives 👥

Engineers are often evaluated on what we ship, so focusing on analytics doesn’t always feel like a priority.

However, analytics gives us valuable insights into how users navigate our product, where they get stuck and what features they use most. Reviewing session data, user paths, and patterns in real-time allows us to make data-driven adjustments.

Ways to Use Analytics for User Insights:

• Track Common User Paths: Understand typical workflows and catch any issues users might face along the way.

• Identify Drop-off Points: See where users abandon tasks, which can signal usability issues or confusing flows.

• Spot Usage Patterns: Notice trends around feature usage, which helps in prioritizing improvements.

A small UI tweak can improve your completion rate by X% without a full redesign.

Session Replays 🔄

Session replays are powerful for spotting problems hidden behind the numbers. This tool isn’t just for diagnosing bugs but it’s also essential for finding UX issues that users might not report.

When data looks “off” replays allow you to see user interactions and identify potential pain points.

• Spot UX Issues: Understand how users navigate and see where they get stuck.

• Identify Product Flow Problems: Find parts of the feature that are confusing or unnecessary.

• Validate Hypotheses: Test if your assumptions about user behaviour match reality.

DLI (Data that Lasts Insights) 📅

Engineers typically focus on quantitative metrics like load times and query speeds, but these alone don’t give a complete picture. DLI is about long-term impact—observing how feature changes affect user engagement over time rather than in the first days post-launch.

Tips for Tracking DLI:

• Avoid overreacting to early data fluctuations.

• Look for sustained changes in user behaviour over weeks or months.

• Evaluate if new changes increase engagement or retention in the long term (very important).

Sending Clean Data

As companies grow, data can get pretty messy if it's not organized well, making it tough to get reliable insights. Setting up standards early on for consistent, usable data is super important. Here are some tips from a developer's point of view to keep your data clean:

• Consistent Naming Conventions: Use lowercase, present-tense, and camelCase (e.g., ClickSignupButton) for event names and property keys. This consistency makes it easier to read, maintain, and query your analytics data.

• Versioning Events: As your application evolves, implement versioning for events (e.g., signupV2). This allows you to compare old and new event data without losing historical context, aiding in debugging and data analysis.

• Type Safety: Use TypeScript or similar tools to define data types for your analytics events. This ensures that the properties sent to your analytics platform match expected formats, reducing errors during data collection.

• Utilize Feature Flags: When launching new features with associated analytics, use feature flags to control the rollout. This lets you test the impact on user behaviour without affecting all users, and you can adjust your analytics tracking as needed.

Adding analytics to your engineering workflow might feel like it's not as important as building and shipping features, but the perks are totally worth it. Getting comfy with data means you're not just making features — you're crafting products that really connect with users and offer lasting value. 🌟

Digging into data, whether it's writing queries or checking out session replays, gives you a wider view that helps you become a better, more user-focused engineer.

The Reality Check 💡

I ran a quick survey among friends about engineers taking on support and their responses were pretty much what I expected:

1. "It's annoying, especially when users ask irrelevant questions."

2. "It breaks my flow. I’m in the middle of coding!"

3. "Isn't that why we have support engineers?"

4. "It takes too long to dig through legacy code and figure out the issue."

5. "That’s not my JOB!"

No doubt, these are valid points. While these concerns may vary by team and company, I believe support is an underrated goldmine of insights, ideas, and opportunities to make your product shine 🌟.

The product I'm currently working on requires more support from users than they need from us to build the next successful feature.

So there are significant benefits when engineers get involved directly:

The Fast Lane to Solutions 🚗💨

The common support process goes like this: tickets first go to support engineers, who either resolve the issue or guide users to the documentation. If they can’t solve it, a JIRA ticket is raised and passed to an on-call engineer. Only then does the engineer begin working on it.

Phew!!!! It's such a long process.

That’s a long journey to get one issue fixed. But imagine if you, the engineer who built that feature, handled it directly. You have the context, the code and the knowledge. What might take a support engineer hours or even days to escalate, you could fix it in a fraction of the day ⚡.

Real User Impact on Code 💻

In support, you don’t just see how the code should work; you see how it actually works 👀. You get a front-row seat to what works, what doesn’t, and what frustrates people 😩.

For example, we once had a flood of tickets from users anxious about receiving their certification results. Turns out, they had completed the test but were stuck seeing the same flow without any status. We didn’t realize this issue until it surfaced in support.

Being close to the users makes it easier to spot and fix these kinds of issues, especially those tricky edge cases 🎯.

Holistic Perspective on the Product 🌍

As engineers, we get to see the entire product lifecycle, from coding it up to watching how users interact with it in the wild. We might think users will follow a certain path (because hey, that’s how we designed it, right?), but the truth is, they can go in the most unexpected ways.

Without the right guidance, things can go into a poor user experience. Spending time in support helps us spot these moments in real time, giving us that crucial insight to prioritize what truly matters.

"Our users teach us more than what we can learn about our product." - Hari

For example, we recently launched a feature behind a flag, accessible only to select users. Those who encountered it were informed that it was a beta release and could opt in if interested. To our surprise, we received a lot of support tickets from users eager to try it out, validating that we were on the right path. This kind of insight is invaluable when deciding what to build next and ensuring you are creating products users love and want 💖.

It’s not just about building what you think is cool, it’s about understanding what users love and leaning into that.

Product Ownership and Accountability 🏗️

Support pushes you to build reliable, maintainable software. When you’ve spent a few hours untangling a mess of bugs, trust me, you start thinking about:

“How can I prevent this from happening in the future?”.

You become more conscious of tech debt, documentation and building with long-term sustainability in mind.

And guess what? That’s how you become a better engineer. Accountability doesn’t just build products, it builds you 💪.

Sharpening Problem-Solving Skills 🛠️

Let’s be real: support issues often involve the weirdest edge cases. You know, the kind that never shows up in development but somehow always pops up in the wild.

Spending time in support forces you to diagnose these issues and strengthen your debugging skills. Over time, you’ll get quicker at identifying patterns and predicting what could go wrong in future builds. (It’s like becoming a product detective! 🕵️‍♂️)

Empathy for End Users 💖

Nothing teaches empathy like hearing a frustrated customer explain why something isn’t working for them. Spending time in support helps you understand those frustrations and drives you to build products that aren’t just functional but also delightful ✨.

It’s one thing to build a feature that works on paper, but it’s another to ensure users have an enjoyable experience using it.

Suddenly, your focus shifts from “Does this feature work?” to “Is this feature providing any value?”. You’ll find yourself asking, “Is this user-friendly?” or “Can we add a little delight here?”. That’s when real, impactful changes happen.

Just look at the raindrops bouncing on the search bar. It’s those little touches that users remember!

Documentation Makes Life Easier 📝

One of the biggest benefits of spending time in support is that it forces you to document your solutions. When you solve an issue, writing it down in a common place means that the next person who encounters the same problem can fix it even faster 🏃‍♂️.

Plus, good documentation doesn’t just make your life easier, it helps both support and engineering teams solve issues faster. In the long run, it saves time for everyone ⏳.

Power of Feedback 😎

You know what’s incredibly satisfying? Getting a small “Thank you!” from a user whose problem you just solved. That little burst of dopamine makes all the hard work worth it. Positive feedback isn’t just a pat on the back — it’s the fuel that keeps us going.

Knowing you made someone’s day? That’s priceless 💫.

Teamwork Makes the Dream Work 🤜🤛

Building a good rapport with your support engineers is crucial. They’re on the front lines, dealing with users day in and day out. By working closely with them, you can share knowledge, streamline processes and ultimately make your product better for everyone.

It’s Not Always About Coding

(as i said in my previous blog also.)

To build that kind of seamless experience, engineers need to understand the user journey. It’s not just about coding — it’s about building something that makes users lives easier.

"The best customer service is if the customer doesn’t need to call you, doesn’t need to talk to you. It just works.” - Jeff Bezos

Wrapping it Up

I think I’ve made enough points to convince you. Who knows? You might even find yourself enjoying support. Crazy, right? 😄

BTS: I spent nearly a month brainstorming what to write for this blog. It wasn’t until the last minute that the idea finally came to me. The right inspiration hit during a classic last-minute panic! And of course, a big thanks to the amazing people who helped me with some valuable points to include <3

A Little Backstory: How I Found the First Book🕵️‍♀️

During my company holidays, I decided to visit an amazing book cafe called Champaca in Bangalore. If you ever find yourself in Bangalore, you must visit this beautiful place. It's a haven for book lovers. I initially went there to wrap up some work, but soon found out that using a laptop on weekdays requires a purchase from the shop. So, I thought, "Why not read some books instead?"

Every book in the cafe was displayed with its title visible. After some exploration, I stumbled upon a book lying on a shelf. Suddenly, a lady appeared and whispered, "This is an amazing book, you should read it." That was the first triggering point for me.

Introducing: "The Boy, the Mole, the Fox and the Horse" 👦🦫🦊🐴

The first book I discovered is called "The Boy, the Mole, the Fox and the Horse" by Charlie Mackesy. Tbh, I couldn't remember the title at first. Whenever I share about this book, I only remember the amazing four characters. It's a series of illustrations and moments shared by a boy, a mole, a fox, and a horse. There isn't a traditional storyline, but there's something about this book that hooks you on every page, making you think about the deep truths of human nature.

These four characters become unlikely friends, united by their sorrows, hurts, and musings about life. Their sorrow unites them, their hurt and their musings about life – all of which contribute to the growing love they acquire for each other. The book beautifully shows that we can be united in our suffering and love others and ourselves better because of it. As the book says, “Asking for help isn’t giving up, it’s refusing to give up.” 🤝

Many lines resonated with me deeply, but a couple that stood out are:

“The bravest thing we can do is ask for help”

“The greatest thing we can do is love.”

This book has become my go-to, and I highly recommend everyone read it at least once.

The Second Book: "Big Panda and Tiny Dragon" 🐼🐉

After raving about the first book to everyone, my mentor introduced me to another fantastic book: "Big Panda and Tiny Dragon" by James Norbury. This book features two characters, Big Panda and Tiny Dragon, who embark on a journey through the seasons (🍂❄️🌸☀️) of the year. They get lost but discover beautiful sights they'd never have found otherwise.

The Panda, the calm voice of reason often reassures the Dragon to look for positives rather than negatives and embrace adventure. The artistic expression in the book brings the narrative to life, allowing you to connect with the characters on a deeper level.

Some lines that struck me are:

“Mistakes mean you are trying, so don’t give up.”

“If you don’t try, you never know you can fly.”

The whole book is filled with such gems.

Why You Should Read These Books 📚

Both books offer more than just stories, they provide reflections and inspirations that can enrich your life. Here’s why you should dive into these reads:

1. Heartfelt Wisdom: The Boy, the Mole, the Fox and the Horse is a gentle reminder of the importance of love and cherishing the little moments in life. If you’re looking for a book that offers comfort and clarity, this is it.

2. Charming Adventures: Big Panda and Tiny Dragon encourages you to embrace life’s ups and downs with positivity and curiosity. It’s perfect for when you need a bit of inspiration and joy.

Conclusion

I hope you understand this blog's title: I am the girl and these amazing characters are my new friends who teach me something about life. If you know of any similar books, please let me know, I’d love to add them to my list. I highly recommend everyone read these two books at least once. I bet you'll love every piece of them.

Happy reading! ✨

Alright, let's jump right in! 🌊

As the title suggests, this blog is about my three-year journey in engineering. Yes, it's been three years — well, technically 1.6 of those were as an intern, but who's counting? 🤷‍♂️ These years have been nothing short of crazy, filled with immense learning, company experiences and some seriously intense coding marathons.

It's tough to sum up all the lessons I've learned, but I'll do my best to capture the gist of it.

💻 It's Not Always About Coding

Understanding the importance of product thinking, participating in design decisions, and providing feedback is crucial. It's not just about writing code, it's about understanding the bigger picture and how your work fits into it.

When you engage in product thinking, you start to see the product from the user's perspective. This means considering how features will be used, what problems they solve, and how they can be improved.

Participating in design decisions allows you to contribute to the overall user experience. It's about collaborating with designers to ensure that the product is not only functional but also intuitive and enjoyable to use. Your technical insights can help shape the design in ways that make it more feasible and efficient to implement.

Providing feedback is equally important. Whether it's during code reviews, design discussions or product planning meetings, your input can significantly impact the outcome.

🔍 Every Pixel Matters

UX is crucial. Even the smallest detail, like a single pixel, can significantly influence how users perceive and interact with your application.

Truly, deeply, madly care about your users ❤️

I clearly remember this one time I spent hours tweaking a small transition in an animation. At first, it felt like a tiny, insignificant task that wouldn't matter. But the boost in user satisfaction was huge. That experience showed me how important it is to focus on even the smallest details.

💡 Mistakes Happen, Learn from Them

Mistakes are inevitable, but the key is to learn from them and grow. Every mistake you make provides an opportunity to improve and refine your processes, ultimately making you a better developer and strengthening your team's workflow.

For instance, there was a time when we accidentally broke the prod because of a small oversight during the testing phase.

This incident could have led to finger-pointing but instead, we took it as a learning experience. We decided to implement a "testing plan" that required thorough verification by all team members involved in the project. This plan included detailed checklists, peer reviews and multiple rounds of testing to catch potential issues before they reached prod.
This experience underscored the importance of learning from our errors and using them as stepping stones toward better practices and more robust solutions.

🔄 Review Your Own Code

Reviewing your code before asking others to review it can significantly streamline the entire review process, making it both easier and faster.

By taking the time to go through your code meticulously, you can identify and correct mistakes, optimize performance and ensure that your logic is sound. This approach not only enhances the quality of your code but also makes the reviewer's job much simpler.

When you review your own code, you can catch syntax errors, logical flaws, and potential performance bottlenecks that might have been overlooked during the initial dev phase.

Moreover, self-reviewing your code allows you to think critically about your implementation choices and consider alternative solutions that might be more efficient or elegant.

Ultimately, this habit of self-reviewing not only improves the quality of your code but also contributes to your growth as a developer.

📞 Setting Priorities - OnCall

Developers might not like interruptions but when you're on call, customer needs come first.

This responsibility requires you to be available and responsive, often outside of regular working hours, to address urgent issues that could impact the user experience or system performance.

Being on call taught me to prioritize effectively and handle emergencies calmly. It was stressful but incredibly rewarding to resolve critical issues promptly. I learned to quickly assess the situation, determine the root cause of the problem and implement a solution under pressure. This experience not only improved my technical skills but also enhanced my ability to stay composed and focused during high-stress situations.

🔍 Go Deeper into Issues

Even if you don't know everything at first, diving deep into issues is super helpful. By really looking into problems, you learn a lot and get better at what you do. It's totally fine to ask for help when you need it, but trying to figure out the root cause on your own can be a great learning experience.

This way, you can spot patterns, understand how things work, and get a better handle on the subject. Over time, this habit not only makes you more skilled but also boosts your confidence in handling tough problems by yourself.

🙋 Ask for Help

Don't hesitate to ask for help when you need it.

I'm currently reading a book called Thinking in Bets, which emphasizes the importance of being comfortable with uncertainty and admitting when you don't know something.

The book suggests that saying, "I'm not sure," is not a sign of weakness but rather a step towards finding the right answers. By acknowledging your limitations, you open the door to learning and collaboration.

I once faced a particular problem that was beyond my expertise. Initially, I hesitated to ask for help, fearing it would make me appear less competent. However, when I finally reached out to a colleague, their advice was invaluable. They provided insights and solutions that I hadn't considered, which not only resolved the issue but also expanded my understanding of the subject.

🏆 Take Ownership

Take ownership of your code and the product you work on. This means taking full responsibility for the quality and functionality of your contributions.

When you take ownership, you are more likely to feel a sense of pride in your work, which can lead to greater job satisfaction and motivation.

🛠️ Improve Old Code

When working on old code, it's important not to blame the previous developers. Instead, focus on improving the code.

Aim to leave the codebase in a better condition than you found it.

Refactoring an old codebase can be tough, but it's super rewarding. By cleaning up and optimizing the existing code, you can really boost the app's performance. This usually means spotting and fixing inefficiencies, getting rid of redundant code, and updating old practices to match current standards.

One big perk of refactoring is that it makes future maintenance a breeze. Cleaner, well-organized code is easier to understand and tweak, which means fewer new bugs when changes are made. Plus, better code readability helps new team members get up to speed faster, making the whole team more productive.

From my experience, tackling an old codebase not only improved the app's performance but also gave me a huge sense of accomplishment. It let me use best practices and modern techniques, leading to a stronger and easier-to-maintain codebase

📄 Document Your Work

Writing down what you do is super important for a bunch of reasons. Over time, it's easy to forget the details of what you've done, especially after a few years. By keeping good records, you can track your progress and achievements easily.

Plus, documentation is a great reference for you and your team. It helps everyone understand why certain decisions were made, how features were implemented and what solutions were used to tackle problems. This is handy when you go back to old projects or when new team members join and need to catch up quickly.

🤝 Collaboration is Key

Working effectively with your team is vital for the success of any project. It's important to share knowledge openly, ensuring that everyone is on the same page and has access to the information they need. Clear communication is essential, it helps to avoid misunderstandings and ensures that everyone knows their responsibilities and deadlines.

Supporting each other is equally crucial. This means being available to help your teammates when they encounter challenges, offering constructive feedback and celebrating each other's successes.

🚀 Embrace Challenges

Challenges are just opportunities in disguise. Embrace them, and you'll grow both personally and professionally. When you face a challenge, it pushes you out of your comfort zone and makes you think creatively to find solutions. This not only improves your problem-solving skills but also builds resilience and adaptability.

Every obstacle you overcome adds to your knowledge and expertise, making you better at what you do.

So, the next time you face a challenge, don't shy away from it. See it as a chance to learn, grow, and make meaningful contributions to your work and your team.

⚖️ Balance Work and Life

Maintain a healthy work-life balance. Burnout is a real problem that can mess with your productivity and happiness. It's super important to take care of yourself just as much as you focus on your work.

Set some boundaries between your work and personal life. This could mean stopping work at a certain time each day, taking regular breaks and making sure you have time to chill and unwind. Do things you enjoy and that help you recharge like hanging out with family and friends, pursuing hobbies or just taking a walk outside.

Remember, taking care of your mental and physical health will not only make you feel better but also boost your work performance. When you're well-rested and happy, you're more creative, focused, and productive.

🎉 Celebrate Achievements

Celebrate your milestones, no matter how small they seem. Recognizing your accomplishments is super important because it boosts your morale and keeps you motivated.

Whether it's finishing a tough project, learning a new skill, or just meeting a deadline, take a moment to acknowledge your hard work and dedication. This could be as simple as treating yourself to something you enjoy, sharing your success with your team or just taking a moment to reflect on what you've achieved.

Celebrating these moments not only makes you feel good but also encourages you to aim for even greater achievements in the future.

🗣️ Effective Communication

Communication is crucial, especially when you're working with a team. Sharing your ideas clearly and making sure you understand others can save you from a lot of mix-ups and mistakes.

I remember once I misunderstood a requirement because it wasn't explained well. That mistake cost me a whole week of work. Now I always double-check and confirm everything before diving into a task.

⏰ Time Management

There was a time when I had to juggle multiple high-priority tasks simultaneously. Each task demanded my full attention and had strict deadlines. To handle this, I started by listing all my tasks and identifying which ones were most urgent and important. I then broke down each task into smaller, manageable steps and allocated specific time slots for each step. By doing this, I could focus on one task at a time without feeling overwhelmed.
This approach allowed me to meet all the deadlines without compromising the quality of my work.

🌈 Enjoy the Journey

Lastly, enjoy the journey. The ups and downs, the late nights, the breakthroughs - they're all part of the engineering adventure. Embrace every moment, whether it's a tricky bug that keeps you up at night or the joy of finally solving a complex problem. These experiences make you a better engineer and a stronger person.

Take time to appreciate the small wins, like successfully deploying a new feature or getting positive feedback from users. These moments make all the hard work worth it.

Remember, the learning never stops. Each project, each line of code, and each collaboration with your team is a chance to grow. Stay curious, ask questions, and don't be afraid to try new things.

The journey is just as important as the destination and by enjoying it, you'll find more satisfaction in your work and stay motivated to keep going.

To wrap things up, my engineering journey has been quite the rollercoaster, packed with valuable lessons and experiences. From tackling tough projects to working with awesome teammates, every step has helped me grow as an engineer.
There's always more to learn, and sharing what we know is the best way to grow together. By swapping ideas and insights, we can all get better at what we do.

I encourage you to stay curious and keep exploring new tech and methods. Engineering is always changing and there's always something new to check out. Whether it's a new programming language, a cool tool or a fresh way to solve problems, jumping on these opportunities will keep you ahead in the game.

Stay tuned for more insights and stories from my ongoing adventure in the world of engineering! I can't wait to share more of my experiences, challenges and wins with you 🚀.

The primary excuse? I didn't have a vehicle to get to the gym.

"It's impossible without a vehicle," I would tell myself.

The logical next step, in my mind, was to acquire a means of transportation. The prospect of owning a vehicle seemed like a worthy investment for my fitness journey. But, my mom, always the voice of reason, promptly refused the idea of a two-wheeler in a new city.

"Who will take care of you if something happens?" she wisely pointed out.

Little did I know, I was falling into the trap of what some call Yak shaving – getting caught up in unnecessary tasks that distract from the original goal.

Instead of focusing on my fitness, I was entangled in the web of excuses and unrelated tasks. It wasn't until I had a moment of clarity that I realized the absurdity of my excuses. I didn't need a vehicle to reach the gym, I needed determination and a change in perspective*.*

The turning point came when, on the very first day of the new year, I decided to take matters into my own hands and began walking to the gym. No more excuses, just a commitment to myself.

To make the journey more exciting, I set a challenge – if I could complete a month with at least four gym sessions per week, I would reward myself with a gift.

The catch? It could be anything, even something delightfully unhealthy.

As I entered the second week, I found myself settling into a routine. The initial enthusiasm was still there, but the real challenge was keeping it alive. I realized that the key to staying on track was to add variety to my workouts. So, I decided to mix things up – from cardio to strength training, each day brought a new challenge.

Sure, there were moments when my alarm's snooze button seemed like a tempting escape, but the promise and visions of my end goals (and the hefty gym fee I paid 🙂) kept me on track.

So, here's to ditching the excuses, finding fitness and proving that resolutions are more than just a myth. Let's see where this journey takes me!

Understanding the Formik Landscape:

For those not in the know, Formik is like that buddy who makes dealing with forms a breeze in React. No fuss, no drama, just simple and effective. It acts as a guardian, simplifying the often complex and tedious process of handling form state, validation, and submission. To get started, toss it into your project like this:

npm install formik
# or
yarn add formik

Once installed, you can import Formik into your React components and start building forms with ease.

Now, let's talk about the discoveries that sparked my excitement during this recent exploration.

1. FieldArray: Taming the Array Beast 🦁

Ever found yourself needing users to input not one, not two, but a bunch of things in a form? That's where the magical FieldArray comes into play.

Why: Handling arrays of form fields can be like juggling invisible balls. FieldArray says, "Chill, I got this!" It helps you manage lists, multiples, and even complex data structures effortlessly.

How:

<FieldArray name="emails">
  {({ push, remove }) => (
    <div>
      {values.emails.map((email, index) => (
        <div key={index}>
          <Field name={`emails[${index}]`} />
          <button type="button" onClick={() => remove(index)}>
            Remove
          </button>
        </div>
      ))}
      <button type="button" onClick={() => push('')}>
        Add Email
      </button>
    </div>
  )}
</FieldArray>

2. Custom Form Fields: Formik's VIP Treatment 🎩

Tired of the same old input fields? Formik's got your back with the VIP treatment for custom components! 🕶️

Why: Sometimes, you want your form to wear a fancy hat. The render prop lets you create custom form fields without sacrificing Formik's superpowers.

How:

<Formik
  initialValues={{ customField: '' }}
  onSubmit={/* Your submission logic */}
>
  {({ values, handleChange }) => (
    <form>
      <label htmlFor="customField">Custom Field:</label>
      <input
        type="text"
        id="customField"
        name="customField"
        onChange={handleChange}
        value={values.customField}
      />

      {/* Your custom rendering logic */}
      <div>{/* ... */}</div>

      <button type="submit">Submit</button>
    </form>
  )}
</Formik>

3. Optimizing Re-renders: React.memo to the Rescue! 🚑

Ever feel like your form re-renders every time you blink? 😳 Not cool, right? Enter React.memo to save the day!

Why: Memoization is like telling your form, "Chill, you only need to change when things actually change." It's like giving your form a cup of ginger tea to relax.

How:

const MemoizedForm = memo(({ values, handleChange }) => (
  <Form>
    <Field type="text" name="field1" />
    <Field type="text" name="field2" />

    {/* ...other form components */}
  </Form>
));

const OptimizedForm = () => {
  return (
    <Formik
      initialValues={{ field1: '', field2: '' }}
      onSubmit={/* Your submission logic */}
    >
      {({ values, handleChange }) => (
        <MemoizedForm values={values} handleChange={handleChange} />
      )}
    </Formik>
  );
}

4. Formik Context: Where Forms Share Secrets 🤝

Formik has a secret club, and it's called Formik Context! 🤫

Why: Imagine your form elements having a chat across the component tree. That's Formik Context! It lets you access form state and actions wherever you want.

How:

import { Formik, Form, Field, useFormikContext } from 'formik';

const CustomInput = ({ label, ...props }) => {
  const { values, handleChange } = useFormikContext();

  return (
    <div>
      <label htmlFor={props.name}>{label}:</label>
      <input
        {...props}
        onChange={handleChange}
        value={values[props.name]}
      />
    </div>
  );
};

const AdvancedForm = () => {
  return (
    <Formik
      initialValues={{ /* ... */ }}
      onSubmit={(values, actions) => {
        // Handle form submission logic here
        console.log(values);
        actions.setSubmitting(false);
      }}
    >
      <Form>
        <CustomInput label="Username" type="text" name="username" />
        <CustomInput label="Password" type="password" name="password" />
        <button type="submit">Submit</button>
      </Form>
    </Formik>
  );
}

So there you have it! Formik is not just a form manager; it's a versatile tool that makes your form-building journey a breeze.
Explore these features, have fun with your forms, and may your code be forever bug-free! ✨

Recently, I had the opportunity to delve into the world of personal style through the course "Building and Owning Your Personal Style" by Karla Welch. In this blog, I want to share my insights from the course and discuss how I have embraced my own personal style. 😊

Note: You can find the course on MasterClass, where you can access a wealth of knowledge and guidance from industry experts.

Now, let's dive into my personal style journey and the valuable lessons I've learned from this incredible course! 💃

The Stories We Tell 📚👗💖

Let's start by looking at the influence of our childhood experiences on our style. 🌸 If you could choose just one dress from your childhood, I invite you to reflect on a special dress that holds value or memories.

I remember a special dress from my childhood. I had a little disagreement with my mom about buying both the shoes and the dress, but I ended up getting them. We then went for a small photoshoot, and I have a picture of me wearing that dress. 💕📸

The Power of Presentation 🌟👚

In a world where first impressions matter, how we choose to present ourselves holds incredible power. Personal style is all about authentically expressing ourselves, rather than conforming to fashion trends.

For instance, I greatly admire my manager Hari, who confidently wears his HackerRank T-shirt, effectively communicating his passion for coding and the hard work he has invested in building a successful company. 💪💻

Experience - A Stylist's Secret Weapon 💁‍♀️🔑

Karla Welch highlights the importance of experience in a stylist's ability to solve fashion problems efficiently. Similarly, our own life experiences shape our personal style choices. While getting dressed may only take a few minutes, it is our lifetime of experiences that enable us to curate a wardrobe that truly reflects our authentic selves. Our style becomes a beautiful reflection of our journey. 🌈

Building a Purpose-Driven Style 💼

Creating a purpose-driven personal style is all about aligning our passions and values with our clothing choices. By infusing determination and hard work into our style journey, we can build a wardrobe that not only reflects our true selves but also empowers us with confidence and authenticity. It's a continuous process that may even lead us to create a purpose-driven business or career that aligns with our style and values. 💫💖

The Journey of Finding Your Style 🌟

Discovering our personal style is an exciting adventure filled with self-expression and exploration. Here are some key steps that have helped me on my style journey:

1. Thriving in Flea Markets 🛍️
   For me, flea markets are like hidden treasure troves filled with one-of-a-kind pieces 💎. I absolutely love the excitement of discovering unique items with fascinating stories behind them. What makes it even better is that shopping at flea markets doesn't break the bank. It gives me the freedom to curate a wardrobe that truly represents my individuality and stands out from the crowd.

2. The Art of DIY ✂️

   Creating clothes from scratch has become an essential part of my style journey. I love doing DIY projects because they allow me to design and make garments that perfectly match my vision 🎀. It's a way for me to freely express my creativity and create unique pieces that are personalized just for me.
   In fact, I've been considering starting to learn sewing so I can make my own dresses. It's an exciting prospect that would give me even more control over my personal style and allow me to truly showcase my individuality.

3. A Fusion of Inspiration 💡
   Pinterest is like my creative haven, where I find inspiration and discover new trends, colours, and outfit ideas. I create mood boards that capture the looks and vibes that truly speak to me, forming the basis of my personal style exploration. It's like building a visual diary that helps me define and refine my unique aesthetic.

4. Sasta Sundar Mazboot 💸
   My style choices prioritize not only aesthetic appeal but also durability and quality. The phrase "Sasta Sundar Mazboot" captures my appreciation for value and longevity. I seek out pieces that not only look good but also withstand the test of time.
   Note: "Sasta Sundar Mazboot" is a Hindi phrase that translates to "Affordable, Beautiful, and Durable" in English.

5. Styling One Piece of Clothing in Multiple Ways 🔄
   When selecting clothes, I look for items that have the potential to be styled in different ways. This could be a classic white shirt, a little black dress, or a pair of well-fitted jeans. By choosing versatile pieces, I can easily mix and match them with other items in my wardrobe, creating numerous outfits without feeling the need to constantly buy new clothes.
   Let's get creative and explore the endless possibilities within our own closets, making fashion more sustainable and fun.

6. Accessorizing to Add Flair 🧣
   Accessories play a crucial role in changing the vibe of an outfit. By using different accessories, such as scarves, belts, statement jewellery, and bags, I can completely transform the look and feel of a single piece of clothing.
   For instance, a plain white shirt can be styled with a colourful scarf and chunky earrings for a bohemian-inspired look, or paired with a sleek belt and heels for a sophisticated ensemble.

The Courage to Take Risks 🎉

Truly owning our personal style requires stepping out of our comfort zones and taking risks. It's about embracing the opportunity to express ourselves authentically and fearlessly.

When we wear something we love, we radiate energy and positivity, influencing not only ourselves but also the world around us. So let go of the fear of judgment, wear what makes you happy, and watch your confidence soar. 💃🌟

Conclusion 🌈

Through the course "Building and Owning Your Personal Style" and my own fashion journey, I have come to realize that personal style is a powerful means of self-expression. It allows us to showcase our stories, passions, and values to the world. So, let's embrace the joy of exploring our unique tastes, experimenting with different looks, and expressing ourselves confidently.

Remember, your style is an extension of your beautiful and authentic self. Own it, celebrate it, and let your personal style radiate positivity and confidence in everything you do! 💖✨