why developers love react but can't explain why: lessons from start with why
·10 min read
share:
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.
when explaining our work, we go: WHAT → HOW → WHY.
typical developer portfolio/resume:
typical project README:
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.
simon sinek explains the golden circle:
and here's the kicker: this maps exactly to how our brain works.
the limbic brain has NO capacity for language.
that's why when you ask a developer "why do you love react?" they say:
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.
remember the early days of react vs angular?
angular's pitch (WHAT first):
technically impressive. feature-complete.
react's pitch (WHY first):
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.
i used to wonder why some projects with "worse" code get more stars than technically superior ones.
project A (WHAT first):
impressive. but... why should i care?
project B (WHY first):
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.
interviewer: "tell me about yourself"
my old answer (WHAT first):
response: "ok... cool."
my new answer (WHY first):
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.
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.
gordon bethune story from the book hit different for me as a developer.
1994, continental airlines = worst in america.
bethune becomes CEO. most would:
bethune started with WHY:
he asked employees: "why are we here?"
turns out: nobody knew. nobody believed in anything.
he gave them WHY:
then HOW:
result:
the engineering team parallel:
how many times have you worked on a project where:
great engineering teams start every feature with WHY:
then HOW to solve it. then WHAT to build.
old portfolio approach (WHAT first):
looks professional. but boring. forgettable.
nobody knows WHY i code or WHAT problems i care about.
new approach (WHY first):
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"
library X (WHAT first):
crickets.
library Y (WHY first):
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."
bad PR description:
reviewer: "...ok why though?"
good PR description:
same code change. but second one explains WHY.
great engineers explain WHY before HOW.
you don't need a startup or big project to apply this.
try:
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.
before reading this book:
after:
same work. different framing.
and people respond differently.
for every project/feature/PR:
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.