Forem: Tharun Chandra Lingala

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

Tharun Chandra Lingala — Tue, 19 May 2026 02:49:48 +0000

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.

TypeScript types I wish I knew when I started

Tharun Chandra Lingala — Mon, 18 May 2026 07:28:52 +0000

When I started using TypeScript I treated it like
JavaScript with one extra step — add a type here,
add an interface there, satisfy the compiler and
move on.

That approach works until it doesn't. You end up
with types that are technically correct but don't
actually prevent the bugs TypeScript is supposed to
prevent.

These are the features that changed how I use it.

Discriminated unions — for state that has multiple modes

I used to model loading states like this:

interface UserState {
  user: User | null
  loading: boolean
  error: string | null
}

The problem: this allows combinations that should be
impossible. loading: true and error: "something" at
the same time. user: someUser and loading: true
simultaneously.

TypeScript won't catch these. The types technically
allow them.

Discriminated unions model the actual possible states:

type UserState = 
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; user: User }
  | { status: 'error'; error: string }

Now TypeScript knows that when status is 'success',
user exists and error doesn't. When status is 'error',
error exists and user doesn't.

const renderUser = (state: UserState) => {
  switch (state.status) {
    case 'loading':
      return <Spinner />
    case 'success':
      return <Profile user={state.user} /> // user is User here, not User | null
    case 'error':
      return <Error message={state.error} /> // error is string here, not string | null
    case 'idle':
      return null
  }
}

The compiler knows exactly what's available in each
branch. No null checks, no "this should never happen"
comments.

Const assertions — for values that never change

I was defining arrays of options like this:

const DIRECTIONS = ['north', 'south', 'east', 'west']

TypeScript infers the type as string[]. If I try to
use a value from this array somewhere that expects
a specific direction type, it fails — even though
I know the values are exactly those four strings.

Const assertion fixes this:

const DIRECTIONS = ['north', 'south', 'east', 'west'] as const
// Type: readonly ["north", "south", "east", "west"]

type Direction = typeof DIRECTIONS[number]
// Type: "north" | "south" | "east" | "west"

Now Direction is a proper union type derived from the
array. If I add a fifth direction to the array, the
type updates automatically. One source of truth.

I use this constantly for:

Navigation link arrays
Status values
Configuration options
Any array that's treated as an enum

Template literal types — for string patterns

I needed a type for CSS color values — specifically
hex colors like #fff or #ffffff.

Before I knew about template literal types I either
used string (too broad) or wrote a runtime validation
function (works but TypeScript doesn't know about it
at compile time).

type HexColor = `#${string}`

const setColor = (color: HexColor) => {
  document.body.style.backgroundColor = color
}

setColor('#ff0000') // fine
setColor('red')     // TypeScript error — not a HexColor
setColor('#')       // technically passes — TypeScript can't 
                    // validate the full pattern, only the prefix

It's not perfect — TypeScript can't validate that the
characters after # are valid hex. But it catches the
obvious wrong inputs at compile time without any
runtime cost.

More useful examples:

// Event names that follow a pattern
type EventName = `on${Capitalize<string>}`
// Matches: onClick, onChange, onSubmit

// API endpoint patterns
type ApiRoute = `/api/${string}`
// Matches: /api/users, /api/products

// CSS size values
type Size = `${number}px` | `${number}rem` | `${number}%`
// Matches: 16px, 1.5rem, 100%

Mapped types — for transforming interfaces

I needed a "partial update" version of my User interface —
same fields but all optional, for PATCH requests.

My first approach: copy the interface and add ? to everything.

interface User {
  id: string
  name: string
  email: string
  role: 'admin' | 'user'
}

interface UserUpdate {
  id?: string
  name?: string
  email?: string
  role?: 'admin' | 'user'
}

This is a maintenance problem. Every time User changes,
UserUpdate needs to change too. You will forget. The
types will drift.

Mapped types solve this:

type UserUpdate = Partial<User>
// Exactly the same as writing all the optional fields manually
// But it updates automatically when User changes

TypeScript has several built-in mapped types worth knowing:

Partial<T>   // All fields optional
Required<T>  // All fields required
Readonly<T>  // All fields readonly
Pick<T, K>   // Only the fields you name
Omit<T, K>  // All fields except the ones you name

Real example:

interface User {
  id: string
  name: string
  email: string
  password: string
  createdAt: Date
}

// Safe to send to the client — no password, no internal fields
type PublicUser = Omit<User, 'password' | 'createdAt'>

// For update requests — everything optional except id
type UpdateUserRequest = Required<Pick<User, 'id'>> & 
  Partial<Omit<User, 'id' | 'createdAt'>>

The satisfies operator — new and genuinely useful

Added in TypeScript 4.9. I missed it for a long time
and when I found it I used it immediately.

The problem it solves: you want TypeScript to check that
a value matches a type, but you also want TypeScript to
remember the exact shape of the value (not just the type).

type Colors = {
  [key: string]: string | { light: string; dark: string }
}

// With a type annotation
const palette: Colors = {
  red: '#ff0000',
  blue: { light: '#add8e6', dark: '#00008b' }
}

// TypeScript thinks palette.red is string | { light: string; dark: string }
// even though we know it's just a string
palette.red.toUpperCase() // Error — might not be a string

With satisfies:

const palette = {
  red: '#ff0000',
  blue: { light: '#add8e6', dark: '#00008b' }
} satisfies Colors

// TypeScript remembers the exact types
palette.red.toUpperCase() // Fine — TypeScript knows red is a string
palette.blue.light        // Fine — TypeScript knows blue has light and dark

You get the type checking of an annotation without losing
the precision of inference. Best of both.

One thing I still get wrong

Generic constraints. I understand them, I write them,
I still occasionally write one that's more restrictive
than it needs to be and blocks a valid use case.

// Too restrictive
const getProperty = <T extends object, K extends keyof T>(
  obj: T, 
  key: K
): T[K] => obj[key]

// I've written constraints like this when the function 
// worked fine with a simpler signature

If you find yourself fighting TypeScript's type checker
on something that should obviously work — check your
constraints first. They might be the problem.

TypeScript's value is in the bugs you never write, not
just the ones it catches. The types above moved me from
"TypeScript stops the obvious mistakes" to "TypeScript
makes impossible states actually impossible."

That's the version of TypeScript worth learning.

Why I stopped using useEffect for everything and what I do instead

Tharun Chandra Lingala — Mon, 18 May 2026 05:40:20 +0000

There was a point in my React journey where useEffect
was my answer to everything.

Data needs to load when the component mounts? useEffect.
Something needs to happen when a prop changes? useEffect.
Need to sync two pieces of state? useEffect.

Six months ago I looked at a component I'd written and
counted seven useEffect calls. The component worked.
It was also completely impossible to follow. Bugs were
showing up that I couldn't reproduce consistently and
fixing one would break another.

That component forced me to actually understand what
useEffect is for — and more importantly, what it isn't for.

What useEffect is actually for

useEffect exists for one purpose: synchronizing your
component with something outside of React.

That's it. Outside of React means:

A browser API (document.title, addEventListener)
A third party library that doesn't know about React
A network request
A WebSocket connection
An interval or timeout

If what you're doing doesn't involve something outside
of React, useEffect is probably the wrong tool.

The mistake I made most often

Syncing state with state.

// What I used to write
const [firstName, setFirstName] = useState('')
const [lastName, setLastName] = useState('')
const [fullName, setFullName] = useState('')

useEffect(() => {
  setFullName(`${firstName} ${lastName}`)
}, [firstName, lastName])

This looks reasonable. It's actually creating a problem.

Every time firstName or lastName changes, React renders
the component, then runs the effect, then sets fullName,
then renders the component again. Two renders for every
one change.

The fix is just a variable:

const [firstName, setFirstName] = useState('')
const [lastName, setLastName] = useState('')

// Calculated during render — no effect needed
const fullName = `${firstName} ${lastName}`

React calculates this on every render anyway. You're not
saving any work by putting it in state — you're adding work.

Fetching data — where it gets complicated

Data fetching is the useEffect use case everyone learns first:

useEffect(() => {
  fetch('/api/user')
    .then(res => res.json())
    .then(data => setUser(data))
}, [])

This works. It also has several problems that don't show
up until your app gets bigger:

No loading state. The component renders before the
data arrives. If you're not handling that, you get
undefined errors or blank flashes.

No error handling. If the fetch fails, nothing happens.
The user sees nothing and doesn't know why.

No cleanup. If the component unmounts before the fetch
completes, you're trying to set state on an unmounted
component.

Race conditions. If the user triggers two fetches
quickly (navigating back and forth), you can't guarantee
which one resolves last. The slower one might overwrite
the faster one.

A more complete version:

useEffect(() => {
  let cancelled = false

  setLoading(true)
  setError(null)

  fetch('/api/user')
    .then(res => {
      if (!res.ok) throw new Error('Request failed')
      return res.json()
    })
    .then(data => {
      if (!cancelled) setUser(data)
    })
    .catch(err => {
      if (!cancelled) setError(err.message)
    })
    .finally(() => {
      if (!cancelled) setLoading(false)
    })

  return () => { cancelled = true }
}, [])

This handles all four problems. It's also 25 lines for
what should be a simple data fetch.

This is why libraries like React Query and SWR exist.
They handle all of this — loading state, error state,
cancellation, deduplication, caching — so you don't
have to write it every time.

I'm not saying never write your own fetch logic. I'm saying
understand what you're giving up when you simplify it.

Event listeners — a genuine useEffect use case

This is wher
e useEffect actually belongs:

useEffect(() => {
  const handleKeyDown = (e: KeyboardEvent) => {
    if (e.key === 'Escape') closeModal()
  }

  document.addEventListener('keydown', handleKeyDown)

  return () => {
    document.removeEventListener('keydown', handleKeyDown)
  }
}, [closeModal])

You're synchronizing React with a browser API. There's no
React-native way to listen to keyboard events. useEffect
is exactly right here.

The cleanup function matters. Without it, every time this
component mounts you add a new listener and never remove
the old one. After ten mounts you have ten listeners all
calling closeModal at the same time.

What I use instead now

For derived state: just calculate it during render.
No hook needed.

For expensive calculations: useMemo, but only when
profiling shows it's actually slow. Not as a default.

// Only if the calculation is genuinely expensive
const sortedItems = useMemo(() => {
  return items.sort((a, b) => a.name.localeCompare(b.name))
}, [items])

For data fetching: React Query in any app that fetches
from an API. The caching alone is worth it.

For browser APIs: useEffect with proper cleanup.

For syncing with external libraries: useEffect,
but isolate it in a custom hook so the component
code stays clean.

// Custom hook isolates the external sync
const useDocumentTitle = (title: string) => {
  useEffect(() => {
    const original = document.title
    document.title = title
    return () => { document.title = original }
  }, [title])
}

// Component stays clean
const ProductPage = ({ product }: Props) => {
  useDocumentTitle(product.name)
  return <div>...</div>
}

The question I ask before every useEffect

Before I write useEffect now I ask: am I synchronizing
with something outside of React?

If the answer is no, I look for a different approach first.
Derived value, event handler, library, custom hook.

useEffect isn't bad. It's a precise tool for a specific
job. Using it for everything is like using a screwdriver
to hammer a nail — it works sometimes, but it's not
what it's for.

That seven-useEffect component I mentioned at the start?
I refactored it to two. One for a WebSocket connection,
one for a document title update.

Everything else moved into derived values, a custom hook,
and React Query.

It's been three months and I haven't touched it since.