What I learned reading other people's code for 30 days straight

A month ago I set a rule for myself.

Every day, before writing any code of my own, I would
spend 30 minutes reading someone else's code. Real code.
Production code from open source projects I actually use.

I expected to pick up some useful patterns. I didn't
expect it to change how I write code as much as it did.

Why I started

I was reviewing something I'd written three months earlier
and I didn't like what I saw. Not because it was broken —
it worked fine. But it was the kind of code that only the
person who wrote it can read comfortably.

Long functions. Inconsistent naming. Logic that required
reading the whole function to understand what any part
of it was doing.

I'd been writing code for long enough that I had habits.
The problem with habits is you don't notice them. I
needed to see how people who write code professionally,
full time, on projects with thousands of users, approach
the same problems.

What I read

I focused on projects I was already familiar with as a
user so I had context for what the code was doing:

React source code — specifically the reconciler.
Not because I expected to understand all of it (I don't)
but because the naming conventions and comment style are
exceptional.

Next.js — the router implementation. I use Next.js
every day so reading how routing actually works internally
was genuinely useful beyond the code quality lessons.

Zustand — the entire source is surprisingly small.
Reading it in full takes about 20 minutes and teaches
more about how React state works than most tutorials.

Radix UI — component accessibility implementation.
This one changed how I think about building UI components.

The first thing I noticed: function length

Every function I read in production open source code
was short. Not artificially short — not broken into
pieces that didn't make sense on their own. But short
in the way that each function did exactly one thing
and was named precisely for that thing.

I counted lines in my own code after the first week.
My average function was 40-50 lines. The code I was
reading averaged around 10-15.

The difference wasn't that they wrote less logic.
They extracted more. Every time a block of code inside
a function had a clear purpose, it became its own
function with a name that described that purpose.

Before reading:

const processOrder = async (order: Order) => {
  // validate
  if (!order.items || order.items.length === 0) {
    throw new Error('Order has no items')
  }
  if (!order.userId) {
    throw new Error('Order has no user')  
  }

  // calculate total
  let total = 0
  for (const item of order.items) {
    total += item.price * item.quantity
  }
  if (order.discountCode) {
    const discount = await getDiscount(order.discountCode)
    total = total * (1 - discount.percentage / 100)
  }

  // save to database
  const savedOrder = await db.orders.create({
    data: { ...order, total, status: 'pending' }
  })

  // send confirmation
  await sendEmail({
    to: order.userEmail,
    subject: 'Order confirmed',
    body: `Your order #${savedOrder.id} is confirmed`
  })

  return savedOrder
}

After:

const validateOrder = (order: Order) => {
  if (!order.items || order.items.length === 0) {
    throw new Error('Order has no items')
  }
  if (!order.userId) {
    throw new Error('Order has no user')
  }
}

const calculateTotal = async (order: Order): Promise<number> => {
  const subtotal = order.items.reduce(
    (sum, item) => sum + item.price * item.quantity, 
    0
  )

  if (!order.discountCode) return subtotal

  const discount = await getDiscount(order.discountCode)
  return subtotal * (1 - discount.percentage / 100)
}

const processOrder = async (order: Order) => {
  validateOrder(order)
  const total = await calculateTotal(order)
  const savedOrder = await db.orders.create({
    data: { ...order, total, status: 'pending' }
  })
  await sendOrderConfirmation(savedOrder)
  return savedOrder
}

processOrder now reads like a description of what
happens. You don't need to read the other functions
to understand the flow. You only read them if you
need to know the details.

The second thing I noticed: naming

The code I was reading used longer names than I was
used to. Not long for the sake of it — precise.

Not: data, result, temp, item, val
But: pendingOrderItems, validatedUserInput,
formattedDateString, activeSubscriptionCount

I'd been shortening variable names to save typing.
The code I was reading treated names as documentation.
A well-named variable means you don't need a comment
explaining what it is.

The one that changed my habits most: boolean names.

// What I used to write
const loading = true
const valid = false
const modal = true

// What I write now
const isLoading = true
const isValid = false
const isModalOpen = true

One word difference. Reads completely differently.
isLoading reads as a question with an obvious yes/no
answer. loading reads as a thing.

What reading Zustand taught me

Zustand's entire source code is around 200 lines.
I read it expecting to find some complex React magic.
What I found was surprisingly simple.

The core of how it works:

const createStore = (initializer) => {
  let state
  const listeners = new Set()

  const setState = (partial) => {
    const nextState = typeof partial === 'function' 
      ? partial(state) 
      : partial

    if (nextState !== state) {
      state = Object.assign({}, state, nextState)
      listeners.forEach(listener => listener(state))
    }
  }

  const getState = () => state

  const subscribe = (listener) => {
    listeners.add(listener)
    return () => listeners.delete(listener)
  }

  state = initializer(setState, getState)

  return { getState, setState, subscribe }
}

That's essentially it. A state object, a set of
listeners, and functions to get/set/subscribe.

Reading this made me realize how much of what I
thought was "React magic" is just JavaScript.
setState notifies subscribers. The React integration
layer uses those subscriptions to trigger re-renders.
The complexity I imagined wasn't there.

Reading source code removes the mystery from tools
you use every day. That removal of mystery makes
you more confident using them and better at debugging
when they don't behave how you expect.

What reading Radix UI taught me

I'd been building UI components with almost no
attention to accessibility. Not deliberately ignoring
it — just not thinking about it.

Reading how Radix implements a dropdown menu opened
my eyes to how much work accessibility actually requires:

Managing focus when the menu opens (move focus to first item)
Returning focus when it closes (back to trigger)
Keyboard navigation (arrow keys, home, end, escape)
ARIA attributes that update based on state
Handling both mouse and keyboard interaction paths
Screen reader announcements for dynamic content

My dropdowns had none of this. They worked with a
mouse. They were broken for anyone using a keyboard
or screen reader.

I'm not saying every component needs to be Radix-level
accessible immediately. But knowing what proper
accessibility looks like means you can make informed
decisions about what to implement and what to defer —
rather than accidentally shipping something that
excludes users entirely.

The habit I kept after 30 days

I don't read for 30 minutes before coding every day
anymore. But I do open the source code of a library
whenever I hit unexpected behavior or when I want to
understand why the API is designed a certain way.

The answers are always in the source. The source is
always more readable than I expect. And I always come
away knowing something I didn't before.

The best part: reading code is free, it's always
available, and the people who wrote it are among
the best developers working in open source today.

You couldn't ask for better teachers.

推荐订阅源

DEV Community