Skip to main contenthomeblog
back to blog

why developers love react but can't explain why: lessons from start with why

1 nov 2025, 13:10 utc+8·10 min read
share:

the realization that hit me

just finished reading "Start with Why" by Simon Sinek.

expectation: another business book, probably not relevant to coding.

reality: literally explained why some of my projects get zero stars on github while others blow up. why some tech interviews went amazing while others crashed. why people love certain frameworks even when "technically" there are better options.

this book unintentionally became the best career advice i've gotten as a developer.

let me explain.

what most developers do (including me)

when explaining our work, we go: WHAT → HOW → WHY.

typical developer portfolio/resume:

  • "built a todo app with react, typescript, tailwind" (WHAT)
  • "implemented redux for state management, used react query for data fetching" (HOW)
  • "...so you should hire me?" (WHY???)

typical project README:

  • "this is a web scraper built with python and selenium" (WHAT)
  • "uses async/await for better performance" (HOW)
  • "star this repo" (WHY???)

sounds technical. sounds impressive.

but nobody cares.

and i couldn't figure out why my carefully-built projects got ignored while someone's "simple" project with worse code got thousands of stars.

until i read this book.

the golden circle: why your brain loves certain code

simon sinek explains the golden circle:

  1. WHY (innermost) - why does this exist? what problem does it solve?
  2. HOW (middle) - how do you solve it differently?
  3. WHAT (outermost) - what did you build?

and here's the kicker: this maps exactly to how our brain works.

  • neocortex (outer brain) - logic, analysis, language → processes WHAT
  • limbic brain (middle brain) - feelings, trust, decision-making → processes WHY & HOW

the limbic brain has NO capacity for language.

that's why when you ask a developer "why do you love react?" they say:

  • "it just... feels right"
  • "i vibe with it"
  • "the developer experience is good"

they can't articulate it. because the decision wasn't made in the language part of the brain.

great projects, great companies, great developers communicate from inside out: WHY → HOW → WHAT.

react vs angular: a case study in starting with why

remember the early days of react vs angular?

angular's pitch (WHAT first):

  • "we're a comprehensive framework" (WHAT)
  • "with two-way data binding, dependency injection, built-in router" (WHAT)
  • "using typescript and decorators" (HOW)
  • "you should use it for your app" (WHY???)

technically impressive. feature-complete.

react's pitch (WHY first):

  • WHY: "building UIs is complicated. we believe it should be simple and predictable."
  • HOW: "we make it simple by letting you build with components and one-way data flow."
  • WHAT: "here's a javascript library. it only does the view layer."

wait, react has FEWER features? less built-in stuff?

yet developers fell in love with it.

why? because react sold a belief: "building UIs should be simple."

people don't choose frameworks based on features. they choose based on philosophy.

github projects: what vs why

i used to wonder why some projects with "worse" code get more stars than technically superior ones.

project A (WHAT first):

  • README: "microservice architecture with kubernetes, redis, postgresql"
  • "implements CQRS and event sourcing"
  • "97% test coverage"

impressive. but... why should i care?

project B (WHY first):

  • README: "tired of spending hours setting up authentication for every project? me too."
  • "that's why i built this. dead simple auth that takes 5 minutes to set up."
  • "here's how: just add one line to your express app."
  • "built with node.js and jwt."

which one would you star?

project B has a WHY. it solves a pain point you FELT.

project A just lists technologies. it's asking you to care about WHAT without explaining WHY.

lesson: your side projects fail because you lead with tech stack, not with problem.

tech interviews: the question i kept failing

interviewer: "tell me about yourself"

my old answer (WHAT first):

  • "i'm a full-stack developer"
  • "i know react, node, typescript, docker, kubernetes"
  • "i built 10+ projects using these technologies"

response: "ok... cool."

my new answer (WHY first):

  • "i'm obsessed with solving real problems through code"
  • "i got into programming because i saw how technology could automate boring tasks and free up people's time"
  • "that's why i focus on building tools that actually help people - like a leave management system that reduced HR processing time by 80%"
  • "i use react, node, typescript - whatever gets the job done"

same skills. different response.

first answer: they're comparing my stack to other candidates.

second answer: they're understanding my motivation and problem-solving mindset.

people don't hire tech stacks. they hire problem-solvers with purpose.

documentation: why nobody reads your docs

ever wonder why some library docs feel amazing while others make you want to cry?

WHAT-first documentation:

## Installation
npm install awesome-library

## API Reference
useAwesome(config: Config): Result
- config.option1: boolean
- config.option2: string

technically correct. tells you WHAT it does.

but you still don't know WHY you'd use it.

WHY-first documentation:

## The Problem
ever tried to handle form validation in react?
you end up with 100 lines of useState for one form.

## Why awesome-library exists
we believe form handling should be simple.
no boilerplate. no repeated code.

## How it works
one hook. handles validation, errors, submission.

## Installation
npm install awesome-library

which docs make you want to try the library?

great docs explain WHY before WHAT.

look at react's docs: they start with "thinking in react" - the WHY and philosophy.

bad docs: just API reference with no context.

the continental airlines lesson for engineering teams

gordon bethune story from the book hit different for me as a developer.

1994, continental airlines = worst in america.

bethune becomes CEO. most would:

  • rewrite the entire system (WHAT)
  • implement new processes (HOW)
  • fire underperforming people (WHAT)

bethune started with WHY:

he asked employees: "why are we here?"

turns out: nobody knew. nobody believed in anything.

he gave them WHY:

  • "we're here to get people home safely and comfortably"
  • "that's our purpose"

then HOW:

  • $65 bonus per month if on-time performance hits top 5
  • listen to frontline employees
  • make decisions like a passenger would

result:

  • 1 year: worst → middle of pack
  • 1998: airline of the year
  • stock up 1000%

the engineering team parallel:

how many times have you worked on a project where:

  • nobody knows WHY the feature exists
  • PMs just say "build this"
  • devs write code without understanding user pain
  • result: technically good code that solves the wrong problem

great engineering teams start every feature with WHY:

  • why does this feature exist?
  • what user problem does it solve?
  • why is this important?

then HOW to solve it. then WHAT to build.

my portfolio mistake (and how i fixed it)

old portfolio approach (WHAT first):

  • homepage: "full-stack developer"
  • projects section: lists tech stacks for each project
  • skills section: logos of technologies

looks professional. but boring. forgettable.

nobody knows WHY i code or WHAT problems i care about.

new approach (WHY first):

  • "i build tools that solve real problems"
  • "i believe technology should make life easier, not more complicated"
  • projects section: leads with the problem each project solved
  • "built with react/node" comes AFTER explaining the why

difference?

old version: "here's another developer with the same tech stack as everyone"

new version: "here's someone who cares about solving problems i relate to"

open source: why some projects attract contributors

library X (WHAT first):

  • "a state management library for react"
  • 50 features, extensive API
  • "contributions welcome"

crickets.

library Y (WHY first):

  • "redux is too complex for simple apps. we believe state management should be intuitive."
  • "that's why we built this - all the power, zero boilerplate"
  • "we need help making this vision real. contribute?"

attracts contributors who BELIEVE in the vision.

people don't contribute to code. they contribute to missions.

zustand, jotai, nanostores - they all sold a WHY: "state management should be simple."

code reviews: what vs why

bad PR description:

  • "refactored user service"
  • "changed from class to functional components"
  • "updated tests"

reviewer: "...ok why though?"

good PR description:

  • "users complained about slow profile loading"
  • "profiling showed unnecessary re-renders in user service"
  • "refactored to functional components with proper memoization"
  • "result: 60% faster load time"

same code change. but second one explains WHY.

great engineers explain WHY before HOW.

the honest takeaway for developers

you don't need a startup or big project to apply this.

try:

  1. next portfolio project: start README with WHY this exists, what problem it solves
  2. next interview: explain WHY you code, what problems excite you
  3. next PR: explain WHY this change matters before diving into WHAT changed
  4. next code review: ask WHY before critiquing HOW
  5. next tech choice: understand WHY the tool exists before using it because "everyone else does"

and most importantly: find your WHY as a developer.

why do you code? why does this work matter to you? what problems do you want to solve?

if you can't answer that, you're just another "react/node/typescript developer" in a sea of thousands.

but if you have a WHY?

you're someone who "happens to use react/node/typescript to solve problems i care about."

massive difference.

how this changed my approach to everything

before reading this book:

  • portfolio: lists tech stacks
  • projects: "built with X, Y, Z"
  • interviews: "i know these technologies"
  • PRs: "changed this code"

after:

  • portfolio: "i solve these problems"
  • projects: "this tool exists because this pain point sucks"
  • interviews: "i'm passionate about these problems"
  • PRs: "this change fixes this user pain"

same work. different framing.

and people respond differently.

the framework that clicked

for every project/feature/PR:

  1. start with WHY: what problem does this solve? why does it matter?
  2. then HOW: how are you solving it differently/better?
  3. finally WHAT: what technologies/approach are you using?

example:

old project description: "todo app with react, redux, typescript, tailwind, firebase"

new project description: "i kept forgetting tasks and missing deadlines. existing todo apps were too complex or too simple.

built a todo app that auto-prioritizes based on deadlines and dependencies - smart enough to help, simple enough to not get in the way.

uses react, firebase, and a custom priority algorithm."

which one makes you want to check out the project?

anyway, read "Start with Why" by Simon Sinek.

or watch his TED talk (60M views) if you're lazy.

it's not a "coding book" but it's the best coding career advice i've accidentally found.

now if you'll excuse me, i need to rewrite all my project READMEs with this framework.

wish me luck.