One year ago, I didn't know anything about Git worktrees except the name.

Today, they're my best friends.

What changed? AI tools.

Here's my current setup:

• A cw alias in my zshrc, alias cw='claude --worktree', spins up Claude Code inside a fresh worktree

• I pass a branch name every time I remember: cw nfdiop/feature-x. When I forget, I end up with folders called lucky-bouncing-sedgewick, and hate myself

• Any time I'm juggling more than one task in the same repo, I reach for cw

If you've ever opened a PR and found changes that didn't belong, worktrees are the fix.

What are Git worktrees

Imagine you're deep in a branch. Uncommitted changes on disk. A dev server running in one terminal. A test watcher in another.

Now a teammate pings you. Can you pull down my PR and sanity-check it locally?

You have three painful options:

• Stash everything, kill the processes, then git checkout their branch

• Commit your half-done work, kill the processes, then git checkout, except your changes aren't ready for any human to see

• Clone the whole repo into a different folder. Slow and cumbersome if the codebase is big

Git worktrees give you a fourth option.

A worktree is a second working directory tied to the same repo. Same .git under the hood, different files on disk. You can have main checked out in one folder and a feature branch checked out in another. Both live, both editable, no stashing.

git worktree add ../review-pr their-feature-branch

That's it.

Dissecting the command

Every worktree command reuses the same three parts:

git worktree add   ../review-pr        their-feature-branch
│                  │                   │
│                  │                   └── BRANCH: which branch to check out.
│                  │                        Must already exist. 
│                  │
│                  └── where the new folder lives on disk.
│
└── COMMAND: adds a new linked working tree.

Git worktree operations

Four commands cover 95% of what you'll use.

# Create a worktree on an existing branch
git worktree add <worktree-path> <branch>

# Create a worktree with a brand-new branch
git worktree add -b <new-branch> <worktree-path>

# List all worktrees
git worktree list

# Remove a worktree (deletes the folder, cleans up refs)
git worktree remove <worktree-path>

# Clean up stale references for worktrees you deleted manually
git worktree prune

Memorize the first three. The rest you'll pick up as you go.

Why Git worktrees are all the rage now

One year ago, I worked on one feature at a time. Switching branches was rare.

Now I run 3+ Claude Code sessions at once, bouncing between branches every day.

The bottleneck moved. The question used to be how fast I could write code. Now it's how many branches my brain can track.

The first time it bit me, I opened a PR that was ready for review and saw changes that didn't belong to it. They were from a different feature I'd been jumping to. I had to send Claude the PR link and say this PR has unrelated changes. Clean it up.

Then I noticed the other branch, the one that was supposed to have those changes, didn't have them either. Two fixes, not one.

The worst part? Five minutes earlier I'd been clicking through a UI thinking I was testing the new behavior. The branch I was on didn't have the new behavior. I was testing nothing. I figured it out by glancing at the branch name in my terminal 🙈.

Worktrees fix this because each branch lives in its own physical folder. The folder name is the branch. You can't be on the wrong one.

Agents don't collide with each other. You collide with yourself. They let you parallelize your attention beyond what your brain can hold.

If you're running agents without worktrees, you've probably already shipped a wrong-branch PR. You just haven't noticed yet.

Gotchas

A few things burned me early. They'll burn you too.

1. Same branch, two worktrees → Git refuses.

You can't check out the same branch in two places. Git blocks you. Makes sense once you think about it. The branch's HEAD can only point at one checkout. Fix: use a new branch per worktree.

This one happens to me often.

2. Worktrees don't show up on GitHub.

A worktree is a local thing. It's not a remote branch. If you want collaborators to see the code, you still git push the branch like normal. The worktree itself is just a convenience on your laptop.

So get in the habit of committing code when you’re done with a feature so you don’t accidentally lose all your code by deleting the worktree.

3. npm run dev may not work out of the box.

Each worktree has its own node_modules, or needs one. Your dev server reads from the local install, so you'll run npm install inside the new worktree before anything boots. Annoying the first time. Worth it.

4. Sibling directory is the convention.

../review-pr next to the main repo is what most people do. git status stays clean, and your editor doesn't index the same files twice in search.

If you use claude --worktree, the default lives inside the repo and that's fine too. Just know your editor will see both copies.

How to make worktrees actually pleasant

A few tiny things made worktrees easier for me.

• Alias to delete all worktrees and start from a clean state:

dw() {
  git worktree list | tail -n +2 | awk '{print $1}' | xargs -I {} git worktree remove {} --force
  git worktree prune
}

• Claude Code worktree alias:

alias cw='claude --worktree'

Every Claude session starts in its own folder. No configuration, no thinking.

If you're on Codex: worktree support is still an open issue: https://github.com/openai/codex/issues/12862. Subscribe to it.

• Scope editor search to one worktree.

When you open a parent folder containing multiple worktrees in VS Code, Cursor, Windsurf, etc., global search spans all of them. Confusing when the same file shows up six times.

Two fixes:

• Specify files to include or files to exclude in the search panel

• Or open the single worktree folder as the workspace root. Simpler.

Try this today

Worktrees aren't new. They've been in Git for years.

What's new is you. Running agents in parallel means juggling more branches than your brain was ever asked to track.

Go look at your last few PRs right now. Search for changes that don't belong. I bet you'll find one.

Then add the cw alias to your zshrc so it doesn't happen again:

alias cw='claude --worktree'

Restart your shell. Spin up your next Claude session with cw your-handle/feature-x.

December 15, 2017. 1:29 AM. I'm doing a master's at Berkeley, about to send a cold LinkedIn message to an engineering leader at Pinterest.

The message is generic. I tell him I'd like to work at Pinterest. I attach my resume and cover letter. I ask for a referral.

He replies with nine words: "Passed your resume to the right folks. Good luck!"

I get the interview. I get the offer. I take Palantir instead.

I don't remember how many other cold messages I sent that month. But I sent a few. Being at Berkeley likely helped. The message itself wasn't clever. It still worked.

That was the 2018 playbook for landing your first dev job: master DSA, find a referral, apply, get hired.

That playbook is dead.

I know this because I came back from maternity leave a few months ago and watched Claude Code eat 1/4 of my job in real time.

First week back, I had to ship a change across the frontend and the backend. Previously that kind of cross-stack work would have cost me half a day just understanding the backend code I didn't write. With Claude I understood it in five minutes. Ready in a day instead of three.

I sat with that for a while.

If a senior dev at Palantir is having that experience, the junior market is something else. Not doomed. Just harder than it's been in years. The kind of work I would have handed a junior to ramp up on can now be done by an AI in under 10 minutes.

So if I was looking for a junior frontend role in 2026, here's what I'd actually do.

What's in this issue

1. Get serious about communication from day one

2. Use a coding agent until you can feel when it's lying

3. Learn the things Claude gets subtly wrong

4. Build real things and ship them to real people

5. Get one foot in the door, anywhere

6. Network the way I networked that Pinterest exec

7. Pick up something beyond frontend

8. Contribute to open source, slowly, with thought

9. Let people watch you figure things out

If you can only do two this month, do the first two. The rest compound once those are in motion.

1. Get serious about communication. On day one.

This is item nine on every "how to get a job as a junior dev" list. I'm putting it first because it's the part of the job Claude can't touch.

• Public speaking.

• Influencing a decision in a meeting.

• Reading a room and noticing the manager is annoyed before anyone says it out loud.

• Writing a doc that someone actually finishes.

These are the things I now spend more of my time on, because the rest has shrunk.

When I was a junior I assumed the best coder wins. The best coder no longer wins on code alone, because Claude writes a lot of the code. The dev who ships the code AND explains why AND gets the other humans to agree wins.

So I would invest in this from week one, not from year five.

2. Use a coding agent until you can feel when it's lying

Not optional anymore.

Pick a coding agent. Use it every day. Learn what it's good at and where it lies. Stay close to the news so you notice when something better drops.

If you can't afford a paid plan: free models, opencode, Gemini CLI, student credits from OpenAI and Anthropic. If you can build well with cheap models, the better ones will feel like cheating.

The advantage you have over me is that you don't have years of habits to unlearn. You can build the AI-native instincts from scratch.

3. Learn the things Claude gets subtly wrong

I keep telling people this. I'll keep telling people this.

• HTML, CSS, JavaScript.

• Data structures.

• Browser dev tools.

• Being able to build a small project without React or Tailwind.

Why this still matters in 2026: Claude will write the code. Without strong fundamentals, you won't catch the subtle bugs in what it writes. You'll ship something that compiles, passes the tests, and is silently wrong, and you won't know why for two days.

4. Build real things and ship them to real people

The basic portfolio is dead. Anyone with Claude can produce a basic portfolio in an afternoon, including the recruiter screening you.

What works instead: build something that solves a real problem you have.

• Job hunting? Build a resume tool.

• Studying? Build something for your study group.

Then use it. Get other people to use it. Now you have a story for the recruiter, and you'll have hit the actual hard part of being a dev, which is not writing the code. It's getting the code into someone's hands and dealing with what they say back.

5. Get one foot in the door, anywhere

A nonprofit with an ugly website. Your school's admin. A researcher whose data analysis lives in a 2009 spreadsheet. Anyone with a real problem who'd let you solve it for free.

Experience is the unfair differentiator. The people doing the hiring know that what you learn at a job is different from what you learn in class. A semester of fixing a real organisation's broken signup flow beats six months of LeetCode.

6. Network the way I networked that Pinterest exec

Most jobs are not won through the portal.

Engage with people from companies you want to work at. Regularly, not once. Do cold outreach. Join the dev communities where devs hang out.

Look back at the top of this post. The cold message was generic. The reply was nine words. The offer came anyway. The probability of any one message landing is low. The probability of zero messages landing if you send one hundred is also low.

Thanks to AI, you can now send more customised messages at scale. A spreadsheet of 100 people you want to work with, and a prompt that generates a unique message for each of them. You can do this in an afternoon. Do it.

7. Pick up something beyond frontend

• Design taste.

• A bit of backend.

• Product sense.

Something that makes you a person who can think about a whole feature, not just the part with the buttons. The "just a frontend dev" job is the most exposed one in this market.

8. Contribute to open source. Slowly. With actual thought.

Find a project you already use. Pick a beginner-friendly issue. Understand every line of what you're about to submit. Then open the PR.

Don't be the person flooding maintainers with agent-generated PRs. They're already drowning in those. The signal you want to send is the opposite: I'm a person who took the time to understand this codebase.

9. Let people watch you figure things out

Devs have gotten jobs from this. When people watch you learn, two things happen. They see you actually doing the work. And they get a real sense of what you're capable of, which is more than your resume can ever tell them.

It also makes friends, which loops back to the networking point.

I'm writing this from inside a job AI is reshaping under my feet. I have not figured out the new rules. I'm partly writing this to figure them out.

But here's what I keep coming back to. I can write two or three lines of code now and watch them get shipped to people using the software in a hospital, or a factory, somewhere I'll never visit. Their day gets a little easier because of those two or three lines.

If that's still what you want, here's where I'd start this week: open a doc, write down one real problem a real person around you has, and see if you can build the first ugly version of a fix by Sunday. That's the whole job. Everything else in this post is in service of that.

I've been writing React code as an engineer at Palantir for the past 6+ years.

These are the 29 red flags that tell me a React codebase is going to be painful to work with.

Ready? Let's dive in! 💪

1. 🚩 Using libraries for what vanilla JS can do

We've all done it:

• Importing lodash just to use isNil instead of == null.

• Using dayjs rather than Intl.DateTimeFormat for future use cases (spoiler alert: they end up never coming).

• Etc.

But this is wrong because every dependency:

• adds maintenance overhead: You have to update it when bugs are fixed, vulnerabilities disclosed, new versions come out.

• adds to your bundle size.

• can break when you upgrade React or TypeScript.

Before you add a dependency, ask yourself: can I do this with vanilla JS?

If the answer is yes, do that instead. It keeps your codebase lean.

2. 🚩 Reaching for heavy dependencies when lighter alternatives exist

moment.js is 75KB minified. day.js is 3KB with the same API.

axios is 14KB. The native fetch API is free.

I've reviewed PRs where someone added a 70KB library to do something a 3KB alternative handled just as well.

Nobody checked the size, because nobody had the habit. It adds up fast and your users on a 3G connection in Lagos or São Paulo are the ones who pay for it.

Before you install, check the bundle size on bundlephobia.

If a lighter alternative exists, use it.

3. 🚩 No linter or formatter configured

Non-negotiable.

I once sat through a meeting where engineers spent 30 minutes arguing about whether to use tabs or spaces.

What settled the debate? Configuring the formatter for the entire repo and moving on.

Without repo-level config, every review becomes a style debate instead of a real conversation about the code.

Set it up once and move on.

4. 🚩 No consistent folder structure

I've wasted so many hours of my life trying to figure out where to put a new file 🥲.

One developer organises by feature, another by file type, a third just dumps things wherever.

Pick a convention – feature-based, domain-based, whatever works for your team – document it, and enforce it in reviews.

// 🚩 Red flag: chaotic structure
src/
  components/Button.tsx
  pages/home/helpers.ts
  utils/userStuff.ts
  lib/api.ts
  shared/Button.tsx   // wait, there's already a Button?

5. 🚩 Junk drawer utils files

Every codebase has one. A utils.ts that starts with 3 helper functions and grows into 40 unrelated ones.

• Nobody owns this file.

• Everyone adds to it.

• Nobody cleans it.

• A simple change to one function can cause merge conflicts with a change to a completely unrelated function.

• A small change can cause bugs in an unrelated function because they share the same scope.

In the example below, formatDate and calculateTax are neighbors for no reason.

// utils.ts — the junk drawer
export function formatDate(d: Date) { /* ... */ }
export function parseQueryString(s: string) { /* ... */ }
export function calculateTax(amount: number) { /* ... */ }
export function debounce(fn: Function, ms: number) { /* ... */ }
export function hexToRgb(hex: string) { /* ... */ }
// ...35 more

Instead, related functions should be grouped together: date-utils.ts, string-utils.ts, math-utils.ts.

If your utils file needs a table of contents, it's time to break it up.

6. 🚩 Related files not colocated

When a component lives in /components, its styles in /styles, its tests in /__tests__, and its helpers in /utils... you're constantly jumping across the project to understand one feature.

Files that change together should live together.

When I need to modify the UserProfile feature, I want to open one folder, not four. And when the feature gets killed, I want to delete one folder, not hunt through four directories for orphaned files.

PS: I’m not jumping that much between files these days: Claude does 😅. But still…

// 🚩 Red flag: scattered files
src/
  components/UserProfile.tsx
  styles/UserProfile.css
  __tests__/UserProfile.test.tsx
  utils/userProfileHelpers.ts

// ✅ Colocated
src/
  features/user-profile/
    UserProfile.tsx
    UserProfile.css
    UserProfile.test.tsx
    helpers.ts

7. 🚩 Barrel files that re-export everything

I've done that mistake too 🙈.

You want to simplify imports, so you create an components.ts file that re-exports everything in the folder.

Little did you know that this creates a hidden coupling between all those files.

• In development, your bundler processes the entire barrel on every hot reload, even files you never touch.

• You get weird compilation errors due to a file that you're not even using but is still being processed.

• You have a hard time tracing where something is defined: you click through to the import and land in a wall of re-exports instead of the actual code.

If you must use barrel files, be explicit: name each export instead of using export *.

// 🚩 components.ts
export * from './Button'
export * from './Modal'
export * from './Table'
// ...50 more

8. 🚩 God components

Data fetching, state management, form validation, error handling - all in one file, all in 500+ lines.

Signs you have a God component:

• Scrolling 30 seconds to find the return statement

• Searching return gives you 20+ results

I've worked on components like this: you fix a bug in the form validation and accidentally break the data fetching because everything shares the same scope.

So break it up. Each piece should have one job.

9. 🚩 Passing entire objects when only one field is needed

// 🚩 Red flag
<UserAvatar user={user} />

// ✅ Better
<UserAvatar avatarUrl={user.avatarUrl} name={user.name} />

When you pass the whole object, the child component is coupled to the shape of user and re-renders whenever any field on that object changes, not just the ones it uses.

You also make the component harder to reuse: what if another part of the app has avatar data but it doesn't live in a user object?

So only pass components the data they need. It keeps them decoupled, reusable, more performant, and easier to test.

10. 🚩 Storing derived values in state

// 🚩 Red flag
const [firstName, setFirstName] = useState('')
const [lastName, setLastName] = useState('')
const [fullName, setFullName] = useState('')

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

// ✅ Just compute it
const fullName = `${firstName} ${lastName}`

If a value can be calculated from other state or props, it's not state, it's a computation.

I've seen this cause real bugs: there's always a render where fullName is stale because the effect hasn't run yet.

The fix is simple: just compute it inline.

If the computation is expensive, wrap it in useMemo. But don't store it in state.

11. 🚩 Using state when it should be a ref

Timer IDs, previous values, flags that shouldn't trigger a re-render: these belong in a useRef, not useState.

If changing the value shouldn't update the screen, it's not state.

// 🚩 Red flag: triggers a re-render every time
const [timerId, setTimerId] = useState(null)

// ✅ No re-render needed
const timerIdRef = useRef(null)

12. 🚩 Putting everything in a global store

Not everything needs to be in Redux or a global Context.

I've worked on codebases where tooltip visibility was stored in Redux: an action to open it, a reducer to track it, a selector to read it, all for state that only one component ever needed.

// 🚩 Red flag: global state for local UI
dispatch(setTooltipVisible(true))

// ✅ Keep it where it lives
const [isVisible, setIsVisible] = useState(false)

The rule: if no other part of the app needs to know about it, keep it local.

13. 🚩 A single massive Context that re-renders half the app

// 🚩 Red flag: one context for everything
const AppContext = createContext({
  user: null,
  theme: 'light',
  locale: 'en',
  sidebarOpen: false,
  notificationCount: 0,
})

Every time any of these changes, every consumer re-renders.

The sidebar toggles? Your notification badge re-renders.

The locale changes? Your sidebar re-renders.

Split your contexts by concern: UserContext, ThemeContext, etc.

It's a small upfront cost that saves you from chasing phantom performance problems later.

And if your contexts start becoming unmanageable, that's a sign you need a state management library with more granular updates.

PS: If your app is simple enough, using a single context is fine 😉.

14. 🚩 Poor TypeScript hygiene

any everywhere. You're using TypeScript but typing things as any?
You're getting all the overhead with none of the safety.

That's just the start. Poor TypeScript hygiene also looks like:

• No discriminated unions — you're allowing impossible states.

• Switch statements without exhaustive checks — every new variant
  is a bug waiting to happen.

TypeScript is only as good as the types you write.

// 🚩 Red flag: allows impossible states
type FormState = {
  isSubmitting: boolean
  isSuccess: boolean
  errorMessage: string | null
}
// { isSubmitting: true, isSuccess: true } — shouldn't be possible, but is

// ✅ Discriminated union
type FormState =
  | { status: 'idle' }
  | { status: 'submitting' }
  | { status: 'success' }
  | { status: 'error'; message: string }

15. 🚩 eslint-disable to silence the exhaustive-deps warning

// 🚩 Red flag
useEffect(() => {
fetchData(userId)
// eslint-disable-next-line react-hooks/exhaustive-deps
}, [])

This looks harmless. It's not.

The linter is telling you: your effect depends on userId, but it won't re-run when userId changes.

Two things can go wrong:

• Your users see stale data whenever userId changes.

• Someone adds a dependency inside fetchData later, gets no warning, and the bug ships silently.

The fix isn't to silence the warning — it's to understand it:

• Maybe fetchData should be wrapped in useCallback.

• Maybe the effect should list userId as a dependency.

Silencing the linter doesn't fix the underlying issue — it just hides it until a user reports stale data.

16. 🚩 Using array indices as keys

We've all written this at some point:

// 🚩 Red flag
{items.map((item, index) => (
  <TodoItem key={index} item={item} />
))}

React just needs something for key, right?

Here's what goes wrong.

You have a list of 3 items. The user deletes item 0. React sees key={0} still exists so it reuses the first DOM node instead of removing it. The component doesn't reset. The stale state from the old item bleeds into the new one.

You'll see this as: inputs that don't clear, animations that fire on the wrong item, form values that belong to a deleted row.

// ✅ Use a stable, unique id
{items.map((item) => (
  <TodoItem key={item.id} item={item} />
))}

If your data doesn't have an id, generate one when it enters your system, not at render time.

17. 🚩 Using a hook when a plain function would do

Just because you're building components doesn't mean everything has to be a hook.

If your function doesn't call React state, effects, or other hooks, it's just a function.

Making it a hook means it can only be called at the top level of a component or another hook, not inside event handlers, loops, or conditionals.

A plain function can be called anywhere. It's also easier to test 😉.

// 🚩 Red flag: it's a hook for no reason
function useFormatCurrency(amount: number) {
  return new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD',
  }).format(amount)
}

// ✅ Just a function
function formatCurrency(amount: number) {
  return new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD',
  }).format(amount)
}

18. 🚩 Rolling your own data fetching layer

// 🚩 Red flag
useEffect(() => {
  setLoading(true)
  fetch(`/api/users/${id}`)
    .then(res => res.json())
    .then(data => {
      setData(data)
      setLoading(false)
    })
    .catch(err => {
      setError(err)
      setLoading(false)
    })
}, [id])

This code works. For a simple one-off fetch, it's fine.

The red flag is what comes next.

Your app needs a loading state.

You add one.

Then error handling.

Then retry on failure.

Then cache invalidation.

Then request deduplication so the same request doesn't fire twice.

There's also a subtle bug already: if id changes quickly, the first response can overwrite the second, a race condition you'll need to handle with an AbortController.

You've just started rebuilding React Query. Poorly.

Libraries like React Query and SWR already solved all of this.

You don't have to use them — but if you find yourself adding more and more logic around useEffect + fetch, reach for a library instead of reinventing it.

19. 🚩 No error boundaries

I've seen an app where JSON.parse on a value with an unexpected shape crashed the entire app: navigation, sidebar, everything. Gone.

TypeScript couldn't catch it: JSON.parse returns any, so the type system had no idea.

A single unhandled error shouldn't take down the whole page.

Wrap critical sections so the rest of the app keeps working. The user loses one capability instead of everything.

// ✅ Wrap critical sections
<ErrorBoundary fallback={<p>Something went wrong.</p>}>
  <UserDashboard />
</ErrorBoundary>

20. 🚩 Empty catch blocks

I can't tell you how many times I've seen this:

• User complaints about an issue

• You check the logs and see... nothing. No errors, no warnings, no clues at all.

• You have to ship new code just to add logging and figure out what went wrong 🤦‍♀️.

The culprit is always the same:

// 🚩 Red flag
try {
  await saveData()
} catch (e) {}

At minimum, log the error. Better yet, tell the user something went wrong (+ how to fix it).

21. 🚩 No loading or error states

No loading spinner, no skeleton, no error message.

Just a blank screen when the API is slow and a crash when it fails.

Your users don't have localhost speeds and perfect networks. You need three states: loading, error, success.

// 🚩 Red flag: only handles success
function UserList() {
  const [users, setUsers] = useState([])

  useEffect(() => {
    fetch('/api/users').then(r => r.json()).then(setUsers)
  }, [])

  return <ul>{users.map(u => <li key={u.id}>{u.name}</li>)}</ul>
}

22. 🚩 Accidentally breaking memoization with default values

I once introduced a new component to my codebase.

And for whatever reason, my app started crashing whenever I typed in an unrelated input.

The culprit? A ?? [] default value in the new component that was creating a new array on every render.

The fix:

// ✅ Define the default outside the component
const EMPTY_ITEMS = []
<ItemsList items={items ?? EMPTY_ITEMS} />

Same goes for {}, () => {}, and any other inline default.

If it's passed as a prop and the child is memoized, define it outside the render.

23. 🚩 Unreadable conditional rendering

Nested ternaries and long && chains both make JSX impossible to follow:

// 🚩 Nested ternaries
{isLoading ? <Spinner /> : error ? <Error /> : data ? <Content /> : null}

// 🚩 Long && chains
{isLoggedIn && hasPermission && !isExpired && featureFlag && <SecretPanel />}

If you have to mentally parse boolean logic to understand what renders, extract it into a variable or use early returns:

// ✅ Clear and readable
if (isLoading) return <Spinner />
if (error) return <Error />
if (!data) return null
return <Content />

24. 🚩 No early returns

If you're five levels of indentation deep, flip your conditions and return early.

This makes the code easier to read.

// 🚩 Red flag: deeply nested
function UserProfile({ user }) {
  if (user) {
    if (user.isActive) {
      if (user.hasProfile) {
        return <Profile data={user.profile} />
      } else {
        return <CreateProfile />
      }
    } else {
      return <InactiveMessage />
    }
  } else {
    return <NotFound />
  }
}

// ✅ Early returns
function UserProfile({ user }) {
  if (!user) return <NotFound />
  if (!user.isActive) return <InactiveMessage />
  if (!user.hasProfile) return <CreateProfile />
  return <Profile data={user.profile} />
}

25. 🚩 Magic values with no explanation

I can't tell you how many times I've wanted to modify a value in the code but was too scared to change it because I had no idea why it was that value.

• setTimeout(retry, 3000). Why 3 seconds?

• pageSize: 37. Why 37?

If a value isn't self-explanatory, give it a name and document it.

// 🚩 Red flag
setTimeout(retry, 3000)
const PAGE_SIZE = 36

// ✅ Named and documented
const RETRY_DELAY_MS = 3000 // Matches the p95 API response time
const PAGE_SIZE = 36 // 4 columns × 9 rows in the grid layout

26. 🚩 The same conditional logic scattered everywhere

// 🚩 Red flag: scattered across the codebase
{user.role === 'admin' && <DeleteButton />}
{user.role === 'admin' && <AdminPanel />}
{user.role === 'admin' || user.role === 'moderator' && <ModTools />}

// ✅ Centralized
function canDelete(user: User) { return user.role === 'admin' }
function canModerate(user: User) { return ['admin', 'moderator'].includes(user.role) }

When if (user.role === 'admin') appears in 10 different components, you've built a maintenance trap.

The day someone adds a new role or changes what "admin" means, you don't want to hunt through 10 files.

Centralise it into permission helpers and import those everywhere.

27. 🚩 No abstraction layer over third-party libraries

// 🚩 Red flag: tightly coupled to recharts
import { LineChart, Line, XAxis, YAxis } from 'recharts'
// ...used directly in 20 components

// ✅ Wrapped behind your own interface
import { Chart } from '@/components/Chart'
<Chart type="line" data={data} xKey="date" yKey="revenue" />

If your charting library is imported directly in 20 components, you're one migration away from rewriting half the app.

A thin wrapper isn't always worth the effort for every dependency.

But for anything you use in more than a handful of places: charting, analytics, HTTP clients, etc. it pays for itself the first time you need to swap.

28. 🚩 Massive files nobody dares refactor

Every codebase has one.

The 1,200-line component that everyone is afraid to touch because there are no tests and everything might break. So it keeps growing. New features get bolted on. The fear compounds. Nobody refactors it. It just gets worse.

The fix is never as hard as the team fears.

Start small: extract one pure function. Write one test. Then another. You don't need to rewrite the whole thing in a weekend. You need to stop feeding it.

29. 🚩 Not memoizing context values

// 🚩 Red flag: new object on every render
<AuthContext.Provider value={{ user, login, logout }}>
  {children}
</AuthContext.Provider>

// ✅ Memoize the value
const value = useMemo(() => ({ user, login, logout }), [user, login, logout])
<AuthContext.Provider value={value}>
  {children}
</AuthContext.Provider>

Every time the provider re-renders, it creates a new value object.

Every consumer re-renders, even if nothing changed. If your context is near the top of the tree, that's potentially your entire app re-rendering for nothing. One line of useMemo prevents it.

None of these flags mean a codebase is doomed.

Every one of them is fixable.

I've introduced some of them myself: the first time you see a pattern is rarely the first time you've written it.

But if you're counting more than a handful in the same project, that's worth paying attention to. Not as a judgment, but as a signal that the codebase needs some care.

Start with the ones that hurt the most. Fix those. The rest will get easier.

That's a wrap 🎉

Leave a comment 📩 to share the red flags you've spotted in the wild.

And don't forget to drop a '💖🦄🔥'.

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

🤖 AI TIP

Use the skill-creator skill to create new skills and improve existing ones.

I once pushed the hardest part of a project to the end because I wasn't ready for it.

The project required GraphQL. I wasn't familiar with it. So I kept building the parts I already knew: the components, the layout, the small PRs that felt productive.

When I finally got to GraphQL, I discovered that schema changes took much longer to propagate than I expected.

What I thought was a day of work turned into a week.

I missed my deadline.

Not because the work was impossible, but because I found out too late how long it would take.

The frustration wasn't about the difficulty. It was knowing I could have avoided the whole mess by starting there.

The monkey and the pedestal

Astro Teller, Captain of Moonshots at X, Alphabet's Moonshot Factory, has a thought experiment: you're trying to teach a monkey to recite Shakespeare while standing on a pedestal. What do you work on first?

Start with the monkey. The pedestal is easy. You can build it anytime. But if the monkey can't learn Shakespeare, none of it matters.

What building the pedestal looks like

Imagine you're building a real-time chat app in React. You need a message list, a text input, and real-time syncing via WebSockets.

You know how to build the message list and the input box. You've done that a hundred times. But you have no clue how to handle WebSocket connections or reconnection logic when the network drops.

The temptation: focus on the styling, the emoji picker. Feel some progress. That's building the pedestal.

Why the hard part can't wait

Putting the hard bit at the end means surprises at the worst possible time.

If I had started with GraphQL on day one, I would have hit that wall early, adjusted my estimate, and told the team. Instead, I delivered bad news when it was too late to adjust.

On another project, I started with the most complex component — the one that would teach us how the infrastructure should work and how to talk to the backend. Once we built that, the patterns were set. The other components fell into place.

Three ways to catch yourself

Even knowing all this, I still fall into the trap. These help me:

Prototype first. Before building anything, do a throwaway prototype that only tackles the risky part. For the chat app, spend a day wiring up a bare WebSocket connection in the console. No UI. No styling. Just: can I make this work? That prototype tells you whether your estimate is 2 days or 2 weeks.

Say it out loud. Share the plan at standup: "I'm tackling the WebSocket logic first." Once you've said it publicly, you feel committed. If you drift back to easy work, the team can flag it.

Ship ugly. Get the hard parts working with minimal UI. A working WebSocket connection with messages in real time, even if the message list is an unstyled <ul>. Once the core works, the polish is easy.

Avoidance vs. paralysis

Last month, I spent 2 days building a nice-to-have feature instead of the core problem. I was shipping PRs, getting code reviews, checking things off. It felt like real progress.

Then I hit a wall. The approach had limitations I hadn't considered. It wasn't even recommended. Two days of work, and the hard problem was still exactly where I'd left it.

I had to close the laptop and regroup. The wasted work wasn't what bothered me. It was realizing I'd chosen that work because it was comfortable, not because it mattered.

That's avoidance. And it's sneaky, because it looks and feels like productivity.

Here's the distinction I wish I'd learned earlier:

Paralysis feels like nothing is happening. You're staring at the problem. You can't start. If this is you, knock out a quick easy win to break the freeze. Get your hands moving. Then pivot to the hard thing.

Avoidance feels productive. You're committing code, making PRs, crossing tasks off your list. But the hard problem isn't getting closer to solved. If you're getting things done and the scary part is still untouched, that's not momentum. That's the trap.

Be honest about which one you're in.

Next time you begin a project, ask yourself: what's the part I'm least sure about?

Start there.

You ask Claude to refactor a component. The code looks clean. You run the app — something's broken.

You prompt it to fix it. Now something else breaks. Three rounds later, you give up and revert everything. (It gets worse when you forgot to commit first.)

TDD saved me from this loop. That's what this post is about.

What is TDD

You write a test that defines the expected behavior before you write the code. Then you write just enough code to make the test pass.

The cycle:

• Write a test → it fails (Red)

• Write the minimum code to make it pass (Green)

• Clean up the code (Refactor)

• Repeat

Most of us do the opposite — write the code first, then test afterwards. Or never test at all.

Why TDD matters more now

1. It protects your refactors

I've done this more than I'd like to admit: write solid code, refactor it before committing, and introduce a bug I then spend 30 minutes chasing.

With TDD, once the tests exist, you can rename things, restructure, go wild. As long as tests pass, you didn't break the behavior.

2. It's your only reliable safety net with AI

This is the big one. This is why TDD matters more now than five years ago.

Here's what keeps happening: Claude writes good code. I ask for a small refactor. It breaks the feature. I prompt it to fix. Now something else breaks. Three, four, five rounds — I revert everything.

Without TDD, you're stuck in a fix loop. Each prompt introduces new problems. You can't tell what's broken until you run the app and manually check. By round three, you've lost track of what the code was supposed to do.

With TDD, the moment the AI breaks something, the test goes red. You see it immediately. No guessing. No manual checking. No spiral.

I use a TDD skill that enforces this automatically — the AI writes tests first, runs them, then implements. When I ask for a refactor and something breaks, the tests catch it before I even look at the diff.

We now have tools that write code 10x faster and break it 10x faster. TDD is the only thing that keeps up.

3. And yes — it forces you to actually write tests

How many times have you said "I'll add tests later" and never did? TDD removes the excuse. Tests come first. You can't skip what you start with.

Because you verify they fail before writing the code, you know they actually test something real — not a green-by-default placeholder.

How to start

With AI tools

Install a skill that enforces the Red-Green-Refactor cycle so your agent can't skip it.

Two I've used:

• tdd — this is the one I run daily. It makes Claude write the test, verify it fails, then implement. If the test doesn't fail first, it loops back.

• superpowers/test-driven-development — similar behaviour.

Install one, configure your AI tool to use it by default, and forget about it. The skill handles the discipline.

Without AI tools

Pick one function you're about to write. Before you write it:

1. Write a test: it should calculate the total price with tax

2. Run it — it fails. Good.

3. Write the function. Run it — it passes. Refactor if needed.

One function. One test. That's your entry point.

Conclusion

TDD felt wrong to me at first. Writing tests before the code goes against every instinct.

But last week I merged a refactor at work — nothing dramatic, but tests stayed green and I didn't think twice before hitting merge. That quiet confidence is what sold me.

Pick one feature you're working on this week. Write the test first. If you're using AI tools, install one of the skills above and let it enforce the cycle for you.

I was mid-sentence, raving about a colleague to a new joiner, when I caught myself.

I always talk about this person. To other teammates. To new hires. To anyone who asks.

Every interaction I've had with them has been pleasant — even during disagreements, even under pressure.

If I'm doing their marketing for free, how many others are too?

That question changed how I think about careers.

1. People want to work with you

• When a manager asks "who should we pull in?", the first names aren't always the most skilled. They're the ones people enjoy working with.

• When deciding which team to join, people ask around. They want to know what it's like to work with you. If they hear good things, they're more likely to choose you.

Your skills get you in the room. How you treat people decides whether you get invited back.

2. People advocate for you behind your back

That's what happened with my colleague. I was doing free marketing for them — without them knowing.

When you're nice, people remember. When your name comes up in a room you're not in, they speak up. For promotions. For opportunities. For team changes.

You can't control what people say about you. But you can make it easy for them to say good things.

3. People want to give back

Psychologists call this reciprocity: when someone helps us, we feel a pull to return the favour.

Help a colleague debug a tricky issue on a Friday afternoon? They'll remember when you need a last-minute code review. Be supportive when someone is struggling? They'll go to bat for you when it matters.

This isn't manipulation. It's human nature — and it stacks up over time.

4. Your feedback actually lands

Some colleagues can give me tough feedback and I take it well. I know it comes from a good place. I don't get defensive. I listen.

Other colleagues give mild feedback and I'm already on guard. Not because the feedback is wrong — the relationship doesn't have that trust.

Be nice and constructive by default, and you earn the right to be direct when it matters.

5. Nice ≠ pushover

Being nice doesn't mean saying yes to everything. It doesn't mean avoiding conflict. It doesn't mean letting people walk over you.

It means you can say no respectfully. Push back without making someone feel small. Hold strong opinions while respecting the person across from you.

The best leaders I've worked with were both kind and firm. That combination is rare. And people follow it.

What this actually looks like

My colleague who does this well? When I ask for help, he shows up. No sighing. No making me feel like a burden.

When I'm wrong — and I've been wrong plenty — he raises concerns so gently I want to reconsider. He'll say "I see where you're coming from, but what about this edge case?" and I think "oh, good point." Compare that to "that won't work" with no context. Same message, completely different experience.

Even when he's right — especially when he's right — he never makes anyone feel stupid.

Think about the colleague you rave about. What is it about them? I bet it's not their technical skills. It's how they make you feel.

If someone in your circle needs to hear this, send them this post ❤️

That's a wrap.

Thank you for reading 🙏

I share career tips like this every week in my free newsletter, FrontendJoy — practical advice to go from junior to senior frontend developer. Join thousands of developers who already read it.

For daily tips, find me on X/Twitter.

6 months after starting as a frontend dev, I was staring at a piece of code.

Dumbfounded.

The logic was tangled. I couldn't find my way through it.

"Who wrote this?" 🤔

I checked git blame, ready to hunt down the culprit.

There it was, in plain sight: Blame nfdiop.

I wrote that monstrosity. And now I had to deal with it.

"Why did anyone let me merge this?" I went back to the PRs and realized why.

My PRs were massive. No one could reasonably give me a thorough review. Those big PRs cost me valuable learning.

Since then, I've reviewed over 3,000 PRs. The pattern is always the same: big PRs get shallow reviews.

Here are 7 reasons to keep yours small.

TLDR

• Small PRs get faster, more thorough reviews — you learn more

• Reviewers procrastinate on big PRs; small ones ship sooner

• Big PRs force all-or-nothing reverts when things break

• AI-generated code hides subtle bugs; smaller PRs make them easier to catch

• Splitting PRs builds your decomposition and architecture skills

• Parallel reviews from different reviewers unblock you faster

• Small PRs mean fewer merge conflicts

1. You get reviews that actually teach you

Imagine handing someone a 400-page novel and asking them to proofread it by tomorrow. Now imagine handing them a 10-page chapter. Which one gets real feedback?

Same with PRs. When a PR is big, reviewers focus on the big picture and miss the details. Those details, a cleaner pattern here, a better naming choice there, are what build your coding instincts as a junior dev.

With big PRs, reviewers get tired or miss things. With small PRs, they have the bandwidth to teach you.

Don't be "old" me 😅.

2. Small PRs ship faster

Whenever I have a big PR to review, I keep putting it off. A small PR? I knock it out in minutes.

I'm not the only one. Opening 3 small PRs gets you to production faster than 1 big one.

3. Reverts don't kill all your progress

I once had a big PR with unrelated changes finally merged, only to revert the whole thing because of one broken piece.

Most of the code was fine. But everything lived in a single PR, so all progress was lost.

With smaller PRs, the working features ship independently. Only the broken piece gets reverted.

Example:

Say you build a new filter component, update the API call, and refactor a shared utility, all in one PR.

The utility refactor breaks something. Now the filter and API work are reverted too. Three small PRs? Only the utility gets rolled back.

4. Bugs hide better in big PRs

Big PRs were already hard to test. AI makes it worse.

AI-generated code looks clean but can hide subtle bugs that aren't obvious at first glance. AI-powered review tools help, but they miss things too.

Smaller PRs mean less code to review. Fewer places for bugs to hide.

5. Splitting PRs sharpens your architecture

Striving to split my PRs improved my skills in two ways:

1. File organization — I had to structure files so different reviewers could work in parallel without conflicts. No more spaghetti files with all the logic crammed in.

2. System thinking — I had to think about all the components upfront and how they fit together. This forced better separation of concerns.

6. Parallel reviews unblock you

This is the best perk of small PRs.

Say you have three colleagues. Instead of waiting for one person to slog through your giant PR, open 3 small, independent PRs. Tag a different reviewer on each.

You move three times faster. And if one PR gets blocked by feedback, you keep working on the others instead of sitting idle.

7. Fewer merge conflicts

Big PRs sit in review for days. The longer they sit, the more your teammates' changes pile up on the target branch.

By the time your big PR is approved, you're resolving conflicts you wouldn't have had if you'd merged smaller pieces along the way.

Small PRs get reviewed fast, merge fast, and stay out of each other's way.

How small is small enough?

My rule of thumb: a PR should do only one thing. If I start writing the PR description and I use "and", "also", or "as well as", I know it's too big.

Ask yourself:

• Can I ship the refactor separately from the feature?

• Can the types or interfaces go first?

• Can the tests be their own PR?

If the answer to any of these is yes, split it.

Conclusion

When you join as a junior dev, you feel pressure to prove yourself and ship fast. I know I did.

But big PRs hurt your growth. You learn less, introduce more bugs, and wait longer for reviews.

Shipping fast and shipping big are not the same thing.

Keep your PRs small. Your future self will thank you.

That's a wrap. If this helped, share it with a junior dev who needs to hear it ❤️

💡 AI TIP

I stayed 6 months away from my computer during my parental leave.

When I came back, I was in shock.

Claude Code and Codex had gotten seriously good.

Tasks that used to require talking to three people? I could now do them with a single prompt.

I'd invested years mastering VS Code, but now most of my time was in the terminal.

Here's what I've learned since coming back, and what I'd tell any dev feeling the same confusion.

Getting hired is harder. Being a junior dev is better.

Junior dev role openings have decreased. Getting hired is harder.

But not impossible: get referrals, network, and build real projects.

But for junior devs who are employed? This is an incredible time.

Why?

• You can onboard 10x faster. Ask Claude or Codex to explain the codebase. Ask it again. And again. It never gets tired of your questions.

• You can skip straight to architecture. Instead of spending weeks learning a library's API, let AI handle that. Focus on why systems are designed the way they are.

• You can operate at mid-level speed. The gap between "junior" and "mid" just got smaller.

Soft skills are no longer optional

No one can predict the future of software engineering.

But coding won't be the main part of the job anymore. That much feels certain.

If you could get away with poor communication skills before because you were a strong IC, that's over. Communication, public speaking, writing clearly: these are the new hard skills.

If yours are weak, start improving them now. (You can even use AI tools to practice 😉)

The IC job as we knew it is gone

I loved being an IC.

Waking up, opening my IDE, shipping code all day.

No meetings. No coordination.

Just me and the problem.

That version of the job is gone.

We can no longer afford to be pure ICs. Even if you only focus on delivering features and never go into management, you'll be managing an army of AI agents instead of coding alone.

The question shifts from how to build it to what to build.

A small number of exceptional devs will remain pure ICs. For the rest of us, the role is evolving.

Everyone is becoming full-stack

Being a purely frontend or purely backend dev is a luxury of the past.

With AI tools, you can pick up backend tasks as a frontend dev and vice versa. You might prefer one side, but you can't wait for someone else to handle a simple task on the other side.

The walls between frontend and backend are thinning fast.

Senior devs are scared too

I hear junior devs say they're afraid of AI.

Senior devs are too. I know I was.

When I first discovered Claude Code, I was excited. Then scared. Then excited again. That emotional rollercoaster is completely normal.

Companies have been laying off teams to double down on AI. The fear is rational.

So I stopped being scared and started being curious. What can I build faster now? What problems were too tedious to solve before?

Fear doesn't ship code. Curiosity does.

Tech is still worth it

I hear people talking about leaving tech.

Maybe they're right for themselves. But I still think tech is an amazing field. You learn constantly, the pay is strong, you create real impact through what you build. And yes, you can dress casually 😅

If you love this work, stay. Don't let the noise push you out.

What I'd do as a junior dev right now

If I love being a dev:

• Employed: I'd sharpen my communication skills, build side projects to stretch my abilities, and read foundational books (The Pragmatic Programmer, A Philosophy of Software Design). I'd use AI as a learning partner, not a crutch.

• Unemployed: I'd build real projects with AI as my partner. I mean really building them, understanding every architectural decision. I'd also volunteer for real-world projects to get experience that stands out.

If I don't love being a dev:

I'd start looking for what I actually love.

Now.

You don't want to spend years pushing through something that doesn't excite you, only to get laid off and realise you lost time you could have spent on something meaningful.

The irony? The skills AI can't replace (communication, judgment, knowing what to build) are the ones we've been undervaluing for years.

If you're a dev reading this and feeling the heat, you're not behind. You're at the starting line of a different race.

That's a wrap.

If this resonated, share it with a dev friend who might need to hear it ❤️

💡AI TIP

Use the Claude /insights command to analyse and improve your workflow.

My first project at work was the best thing that had ever happened to me.

I loved my team. I loved the codebase. I was finally writing production code that mattered, alongside engineers I looked up to.

I felt invincible. Then I experienced my first team restructuring.

One morning, my manager called a meeting and moved me to another team. Overnight.

I didn't take it well. I cried. I complained to my friends constantly. Worse, I kept helping my old team instead of investing in my new one 😅.

This didn't work out for me. I ended up receiving my first bad feedback and had to earn trust again.

I'm not alone. Over the course of my career, I've seen many people resist team restructuring, and it almost always holds them back.

Here are the lessons that cost me a bad feedback to learn.

TLDR

1. Restructuring is strategy, not chaos — your leads are reshuffling to win

2. The wrong moves: complaining, clinging, living in the past

3. Seek understanding — find someone who can explain the "why"

4. Embrace new teammates — set up coffees, learn their strengths

5. Re-assess your work — make sure it still matters in the new context

Restructuring is strategy, not chaos

Think of your team like a basketball team.

Players get injured, new talent arrives, the league changes the rules. Coaches don't reshuffle because they want to — they do it because standing still means losing.

Your team lead is doing the same thing. Someone resigns. The business shifts. New customers arrive. Leads adapt: hiring, creating new teams, or moving people around.

As brutal as these changes feel, they keep the business alive. And more importantly, they keep you employed 😉.

You know what's worse than team restructuring? Layoffs.

When leads make changes, 99% of the time it's with the hope the business will be better. It's not incompetence. It's not carelessness. It's not a whim.

As a junior, your perspective is limited. You see your team. You don't see the full company picture.

So accept it, if you plan to stay at your company.

Don't be "old" me.

The wrong way to handle team restructuring

The wrong way is exactly what I did: fighting the change instead of leaning into it.

Here's how people fail during team restructuring:

• Complaining loudly (and constantly). Once a decision has been made, debating it changes nothing. Especially as a junior, vocal resistance won't reverse the call. It'll change how people see you.

• Working as if nothing changed. Say your team merges with another. The wrong move is to keep working with the same people on the same things. Reach out to your new teammates. Learn what they're building.

• Living in the past. Don't waste energy romanticizing the old setup, the smaller team, the colleagues who felt like friends. Time spent mourning the old world is time you could spend building in the new one.

Now, here is what actually helps.

How to thrive when team restructuring happens

I took my first team restructuring hard.

Today, whenever my manager mentions changes, I'm all in 💪. Because I learned something: restructuring is a chance to start fresh. New team, new energy.

Here's how to make it work for you:

Seek understanding (give yourself a day first)

You won't always understand why the change happened. That's OK.

But once you get over it, find someone who can explain the "why." A manager, a lead, someone who sees the bigger picture. Ask them what drove the decision and what role you play in it.

You'll often find the change makes sense. You just didn't have the full context yet.

PS: If it still doesn't make sense after asking around, you're entitled to look for a new job 😉.

Embrace your new teammates

Meeting new colleagues is exciting when you let it be. It's a chance to learn their tricks, discover how they work, even make new friends.

Set up time with them: grab a coffee, learn what they care about, ask for their best career advice. Observe their strengths. Ask them to teach you something.

This one habit changed everything for me.

For example, once I accepted that restructuring, I took the time to discuss with one of my new teammates. Turns out he was an exceptional developer with solid fundamentals and hands-on frontend experience. He shared specific Frontend resources that were the first ones I used in my learning journey.

Re-assess your work

Whenever dynamics change, check that your work still matters.

Is what you're building still the most valuable thing in the new context? If not, talk to your team and adjust. Don't keep pushing on a project that lost its purpose in the shuffle.

Restructuring is scary. I know. I cried through my first one.

But it's also the reason I met some of the best engineers I've worked with. It's the reason I learned to adapt instead of cling.

Here's your homework: if you're going through a restructuring right now, schedule a 15-minute coffee with one person from your new team this week. Ask them: "What's the most interesting thing you're working on?"

That's it. That's the start.

If you know someone going through this, send them this post ❤️.

That's a wrap.

Thank you for reading this post 🙏.

I share career tips like this every week in my free newsletter, FrontendJoy — practical advice to go from junior to senior frontend developer. Join thousands of developers who already read it.

If you want daily tips, find me on X/Twitter.

In 2019, one year after joining a dream company, I was frustrated.

I realized I wanted to switch to another area of software engineering (frontend), but I didn’t know how 🤷‍♀️.

No one would give me a step-by-step plan to achieve it.

All my life, I was used to having either my parents, teachers, or family provide me with a simple roadmap to follow.

I was expecting the same from my managers here.

Fast forward to today: I’m a Senior Frontend Engineer, and I got here by owning my growth path.

In this post, I’ll explain why you always need to own your growth as a dev — and why not doing so is reckless.

Ready? Let’s get started! 🚀

What it means to own your growth as a dev

Owning your growth as a dev, especially a junior one, means:

1. Being clear about where you want to be in 1, 3, and 5 years.

2. Sharing your goals with people who can help you.

3. Having a plan to reach your goals (and refining it with your manager).

4. Following up on the plan.

5. Re-adapting and adjusting when things change.

Why it’s essential to own your growth

As a (junior) dev, it’s way too easy to be passive and wait for opportunities.

Don’t get me wrong: that’s not always bad.

You can get pretty far with a fantastic manager and a bit of luck on projects.

But it’s dangerous to stay in the backseat of your career. Here’s why:

Reason #1: “If you don't set goals, you will always work for someone who does.”

That’s just the truth.

If you don’t have a clear idea of where you want to go, you’ll end up working for someone else’s goals.

That’s not necessarily bad if your goals align.

But when they don’t, 5 years down the road, you might realize you’re unhappy, stuck in a role that doesn’t fulfill you 🥲.

Reason #2: Working toward your goals brings you more supporters

Have you heard of the analogy about pushing a broken car?

It goes like this:

It’s much easier to help someone who’s already pushing their broken car than someone who’s just standing next to it, waiting.

Why?

Because movement attracts help.

People are far more likely to jump in and assist when they see you taking action, even if it’s messy or slow.

So if you’re stuck, start pushing.

You’ll be amazed at who shows up to give you a hand.

Reason #3: Owning your growth gives you more credibility

When you own your growth, set goals, and work toward them, it’s easy to imagine you doing the same for a team.

Owning your growth shows strong ownership — a trait that accelerates your career.

Reason #4: Other people are also trying to figure it out

As a junior dev, I used to look at folks with 3+ years of experience and think:

“Wow, they’ve figured it all out.”

Fast forward to today — after 5+ years — I’ve realized you never really figure it out 😅.

The problems get harder.

As a manager, I see this too: I can give some advice, but until someone comes to me with clear goals, it can be pretty generic.

But if you arrive with a clear goal and a rough plan, it’s much easier to provide you with tailored, helpful advice.

Reason #5: Having clear goals helps you adjust when things change

Tech changes all the time. Look at how AI is reshaping everything.

Clear goals act like a north star. They let you reassess: is this new tech going to help or hurt in reaching them?

Without that, you’ll drift wherever the wind blows — and might wake up in a place you hate.

How to own your growth

Alright, so how do you actually do it?

Let me start with a personal example.

My story:

In 2019, I wanted to transition into frontend development. So I:

1. Made this goal clear to my manager.

2. Talked to as many people as possible who’d made the switch.

3. Applied all their tips (learned JavaScript, contributed to the product, etc.).

4. Shared my progress regularly with my manager.

5. Repeated the cycle — contribute → share → repeat — until the right opportunity came up. Then I made the transition.

What you can do:

If you’re not currently owning your growth, here’s how to start:

1. Set goals (or anti-goals):

   Where do you want to be in 1, 3, 5 years? Do you want to be an IC, a manager, or earn a specific comp?
   
   Can’t come up with goals?
   
   👉 Try anti-goals: what does your nightmare life look like? (low pay, endless meetings, outdated skills). Then work backwards to avoid it.
   

2. Come up with a plan:
   Start with a simple 3-year plan, a clearer 2-year plan, and a more detailed 1-year plan.
   
   The plan doesn’t have to be perfect or set in stone. It’s mainly a conversation starter.
   
   Remember, “Complexity is the enemy of execution.”
   

3. Share and refine the plan:
   Don’t just tell your manager, “This is what I want.”
   
   Say, “This is what I want, and here’s how I plan to get there.”
   
   Then gather feedback, adjust accordingly, and ensure it aligns with the business's needs as well.
   

4. Work toward the plan every day:
   Show up consistently. Small steps daily beat occasional giant leaps.
   

5. Share your progress:
   Don’t be shy. Sharing wins builds trust and shows commitment.
   

6. Reassess and adjust:
   Plans change. Don’t abandon ship at the first hurdle — some things take time.
   
   As Warren Buffett said, “You can't produce a baby in one month by getting nine women pregnant.”.
   
   But also don’t be afraid to pivot if needed.
   

7. Keep setting goals:
   It’s easy to coast when things go well. But this is a never-ending process.

Summary

You’re cheating yourself if you’re not owning your growth as a dev.

Owning your growth means having goals (or anti-goals) and working toward them.

If you don’t, you’re 99% more likely to wake up one day in the wrong place, full of regrets.

It’s not that hard: set goals, build a plan, share it, work on it, show your progress, adjust — repeat.

That’s it.

You’ve got this.

Become the amazing developer you’re meant to be 💪.

💡 TIP OF THE WEEK

Twitter tweet

If you’ve been a frontend developer for a while, you’ve heard of React.

You might even be learning it right now and wondering — is it really worth the hype?

Short answer: It is.

Here are 7 reasons why 👇

1. Simple enough to pick up

You can build your first component in minutes.

Scaffold a new project with Vite, tweak a few lines, and you’ve got this:

function Hello() {
  return <h1>Hello world!</h1>
}

That’s the beauty of React:

React components are just JavaScript functions — no need to learn a new language.

You can start small and build from there.

All you need is:

• a good understanding of JavaScript

• the official React docs

• hands-on practice (and maybe AI to help debug)

2. Great community

Stuck on something? Someone’s been there before.

You’ll find help on StackOverflow, GitHub, Reddit, dev.to, Discord, and tons of blogs and newsletters like this one 😉.

The ecosystem is one of the most beginner-friendly out there.

3. Incredible learning resources

From the official React docs to YouTube tutorials, newsletters, and free courses…

There’s no shortage of quality content.

You can literally build a career just by learning React from free resources.

4. React gives you building blocks

React isn’t a full framework, and that’s a good thing.

It gives you the essentials: components, state, and rendering logic.

The rest? You choose:

• Router? Take your pick.

• Data fetching? Use what fits your stack.

• Styling? Go with CSS Modules, Tailwind, styled-components — whatever you like.

No lock-in. No monolith.

5. Deterministic (mostly)

React removes the guesswork from UI.

If state === x, your UI always looks like y.

That makes your app easier to reason about — and debug.

Compare that to manually manipulating the DOM... and you’ll never go back.

6. Less spaghetti, more structure

React encourages breaking your UI into small, reusable components.

That’s huge.

It’s the difference between one 1000-line file and a clean, modular codebase with clear responsibilities.

7. Constantly improving

React’s not sitting still.

From class components to hooks to server components — it keeps evolving without breaking your app.

It’s one of the rare libraries that’s both stable and moving forward.

TL;DR: Yes, React is great

It’s:

• Easy to start

• Scales well

• Backed by a world-class community

Sure, it’s not perfect. But for most web projects in 2025, it’s a smart bet.

🐞 SPOT THE BUG

Twitter tweet

New to React?

If yes, you’ve probably wondered what hooks you really need—or worse, you’ve been copying the same logic over and over without realizing it.

This post covers all the React hooks you’ll likely need in your project.

Let’s dive in.

1. useState

This hook is unavoidable.

Whenever you need dynamic state that persists across re-renders, this is the one.

const [count, setCount] = useState(0);

2. useReducer

Once your state becomes complex (e.g. multiple correlated fields), useReducer becomes your friend.

It also pairs really well with useContext, letting you update state with simple dispatch calls.

const reducer = (state, action) => {
  switch (action.type) {
    case "addTodo":
      return { todos: [...state.todos, action.todo] };
    case "removeTodo":
      // TODO: Implement logic
    case "toggleTodo":
      // TODO: Implement logic
    default:
      return state;
  }
};

const [state, dispatch] = useReducer(reducer, { todos: [] });

3. useContext

When prop drilling gets out of hand, this hook saves the day.

Use useContext to:

• manage global state in small apps

• share data like the authenticated user

• avoid passing props manually everywhere

const UserContext = createContext();

function App() {
  const user = useUser();
  return (
    <UserContext.Provider value={user}>
      {/* ... */}
    </UserContext.Provider>
  );
}

function Profile() {
  const user = useContext(UserContext);
  return <div>Hello {user.name}</div>;
}

4. useEffect

You should avoid it 99% of the time.
(See: You Might Not Need an Effect)

But in real life, you’ll still need it—especially for things like syncing with external systems.

function useSetDocumentTitle(title: string) {
  useEffect(() => {
    document.title = title;
  }, [title]);
}

5. useRef

You should never directly manipulate the DOM in React.

But when you must (e.g. for canvas, chart libraries…), useRef is the safe way.

function ExampleChart({ data }) {
  const canvasRef = useRef();

  useEffect(() => {
    const ctx = canvasRef.current;
    if (!ctx) return;

    const chart = new Chart(ctx, {
      type: "bar",
      data: {
        labels: data.map((row) => row.year),
        datasets: [{ label: "Likes", data: data.map((r) => r.count) }],
      },
    });

    return () => chart.destroy();
  }, []);

  return <canvas ref={canvasRef} />;
}

6. useMemo / useCallback

These may become optional thanks to the new React Compiler—but for now, they’re still useful.

Use useMemo when:

• an expensive computation should not re-run on every render

• you're memoizing a non-primitive dependency

• you're passing values to memo-wrapped components

Use useCallback to memoize functions.

const total = useMemo(() => computeTotal(items), [items]);

const handleClick = useCallback(() => {
  console.log("clicked");
}, []);

7. useLayoutEffect

This one is rare but useful.

It runs before paint, which helps prevent layout shifts or flickering UI.

See real examples here: No more flickering UI

useLayoutEffect(() => {
  const height = ref.current.offsetHeight;
  setHeight(height);
}, []);

8. useSWR / useQuery

SWR and TanStack Query are becoming the standard for fetching data in React.

SWR is simpler and great for most use cases while TanStack Query is more complex and powerful.

SWR

const fetcher = (url) => fetch(url).then((res) => res.json());

const { data, error, isLoading } = useSWR("/api/user", fetcher);

TanStack Query

const getUser = () => fetch("/api/user").then((res) => res.json());

const { data, isLoading } = useQuery({
  queryKey: ["user"],
  queryFn: getUser,
});

9. useSelector, useDispatch, or other state hooks

Sometimes React’s built-in state tools aren’t enough.

You’ll then see these hooks depending on the state library:

• useSelector, useDispatch from react-redux

• useAtom from Jotai

• etc.

10. useNavigate

React Router is very popular.

So is its navigation hook:

const navigate = useNavigate();
navigate("/profile");

Now, let’s talk about hooks I reach for in nearly every app—even though they’re not built into React.

11. useBoolean

One of my all-time favorites.

It makes managing boolean state super clean.

const { value: isOpen, setFalse, toggle } = useBoolean();

return (
  <>
    <button onClick={toggle}>
      {isOpen ? "Close form" : "Open form"}
    </button>
    <Dialog isOpen={isOpen} onClose={setFalse}>
      {/* Form content */}
    </Dialog>
  </>
);

12. useCopyToClipboard

Perfect for "copy" buttons.

const [copiedText, copy] = useCopyToClipboard();

const handleCopy = () => {
  copy("Hello World").catch(err => {
    errorToast("Failed to copy!", err);
  });
};

return (
  <>
    <button onClick={handleCopy}>Copy</button>
    {copiedText && <span>Copied!</span>}
  </>
);

13. usePrevious

Use this to compare current vs. previous values.

Great for triggering actions based on changes.

const prevCount = usePrevious(count);
const didIncrease = prevCount !== undefined && count > prevCount;

useEffect(() => {
  if (didIncrease) {
    console.log("Count increased!");
  }
}, [didIncrease]);

14. useDebounce

Debounce your requests to avoid unnecessary API calls.

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

const { data } = useSWR(`/api/search?q=${debouncedQuery}`, fetcher);

return (
  <> 
    <input
      value={query}
      onChange={(e) => setQuery(e.target.value)}
      placeholder="Search..."
    />
    {/* TODO: Show data */}
  </>
  
);

15. useMediaQuery

Want to render different things based on screen size? This hook is for you.

const isMobile = useMediaQuery("(max-width: 768px)");

return <div>{isMobile ? "Mobile View" : "Desktop View"}</div>;

16. useResizeObserver

Useful for responsive layouts or libraries like react-window.

const ref = useRef(null);
const { width = 0, height = 0 } = useResizeObserver({ ref });

return (
  <div ref={ref}>
    Width: {width}, Height: {height}
  </div>
);

17. useLocalStorage

Store and sync data with localStorage easily.

const [theme, setTheme] = useLocalStorage("theme", "light");

return (
  <button onClick={() => setTheme(theme === "light" ? "dark" : "light")}>
    Switch to {theme === "light" ? "dark" : "light"}
  </button>
);

Summary

That’s it!

These 17 hooks are more than enough to cover most use cases in any React app.

Pick your favorites and use them in your next project 😉.

💡 TIP OF THE WEEK

Twitter tweet

I’ve been a frontend developer at Palantir for the past 5+ years.

In this post, I’ll share habits that helped me go from overwhelmed junior dev to confident senior dev.

Ready?

Let’s get started! 🎉

Habit #1: Educate yourself outside of work

If you’re not learning outside of work, you’re falling behind.

Even if you have the best employer in the world, your education is your responsibility.

So, at least once every 2–4 weeks:

• Pick up books like The Pragmatic Programmer, Effective TypeScript, or Advanced React

• Read blog posts from experts like Matt Pocock (Total TypeScript), Josh Comeau (joshwcomeau.com), Kent C. Dodds (Epic React), etc.

• Watch courses to review your basics (Udemy, FrontendMasters, etc.)

The more you learn, the more efficient you’ll be at work.

AI-generated image of a dev reading Effective TypeScript book

Habit #2: Work on different projects and skills every month

The worst thing that can happen to a frontend dev?

👉 Getting stale.

Especially in the age of AI.

Working on the same type of project over and over slows your growth.

Why?

• You have fewer tools to solve problems

• You get less flexible and adaptable

• You become easier to replace

Try new things every month. If you can’t at work, explore with side projects.

Habit #3: Get enough rest

The less sleep I get, the more bugs I ship 😅.

Your brain needs rest. And what that looks like depends on you.

But one thing’s for sure: you can’t cheat sleep.

Getting enough rest keeps your mind sharp and your code cleaner.

Rest and recharge!

Habit #4: Stay in touch with what’s happening in the frontend world

I still see devs who ignore AI (and other new tech trends).

This breaks my heart 🥲.

Most devs who ignore change will eventually get replaced by it.

You don’t need to jump on every trend. You don’t need to use the latest framework.

But you do need to stay aware. Pay attention. Adapt when it makes sense.

Otherwise? You’ll slowly become obsolete.

Habit #5: Review code regularly

Code reviews are underrated 🙂.

Not just for the code author, but for you.

I’ve learned countless patterns and tricks just by reviewing code.

It’s a simple way to grow while helping your teammates.

No access to reviews at work? Browse open-source projects on GitHub and read PRs.

AI-generated image of two devs (one reviewing the code for the other one)

Habit #6: Teach back what you learn

Teaching forces you to understand things deeply.

I’ve often thought I knew something—until I tried to explain it.

That’s when I realize I don’t actually get it yet.

Teaching is a shortcut to mastery.

• Run internal sessions at work.

• Write on a blog.

• Record short videos.

Anything works 😉.

Habit #7: Avoid tutorials and copy/pasting

Tutorials are fine—in small doses.

But they quickly become a way to avoid learning, not to encourage it.

Instead of binge-watching, try to build something. Use tutorials only when you’re stuck.

Same with copy/pasting code.

If you don’t understand what you’re pasting, you won’t remember it. And you’ll keep repeating the cycle.

AI-generated image of a dev struggling because of tutorials

Summary

Becoming a great frontend dev takes time.

But these 7 small habits can make a huge difference over the long run.

What’s next?

Pick just one—and try it this week 🙂.

💡TIP OF THE WEEK (from Marko)

Twitter tweet

It’s easy to end up with messy frontend code.

In this post, I’ll show you 17 things to avoid if you want to keep your frontend code clean and maintainable.

Let’s dive in 👇

Mistake #1: Using too many global variables

Global variables are accessible from anywhere in your app, which makes them risky.

If you change one in a random place, you can unintentionally break something elsewhere, and that’s a nightmare to debug.

They also make testing harder, since the function's behavior might change depending on the global state.

Use function arguments or scoped variables instead.

❌ Bad:

let userRole = 'guest';

function canEditPost() {
  return userRole === 'admin';
}

userRole = 'admin'; // Changes app behavior unexpectedly

✅ Better:

function canEditPost(userRole) {
  return userRole === 'admin';
}

const role = 'admin';
canEditPost(role);

Mistake #2: Poor variable and function names

Using vague names like x, data, or handleStuff slows everyone down.

Readers (including future you) will need to guess what each thing does — or worse, scroll around to find out.

A good rule of thumb: the bigger the scope, the more descriptive the name should be.

Short loops? i is fine.

Longer scope? Use names that tell the whole story.

❌ Bad:

function d(a, b) {
  return a - b;
}

const x = d(100, 50);

✅ Better:

function calculateDiscount(originalPrice, discountAmount) {
  return originalPrice - discountAmount;
}

const finalPrice = calculateDiscount(100, 50);

Mistake #3: “God” functions

These functions try to do everything — validate input, update UI, fetch data, handle errors — all in one place.

The result? Long, messy functions that are painful to test and debug.

Instead, split logic into smaller, focused functions.

This improves readability, makes it easier to write unit tests, and helps you reuse logic in other places too.

❌ Bad:

function handleFormSubmit(event) {
  event.preventDefault();

  const name = event.target.name.value;
  const email = event.target.email.value;

  if (!name || !email.includes("@")) {
    alert("Invalid form");
    return;
  }

  setLoading(true);

  fetch("/api/submit", {
    method: "POST",
    body: JSON.stringify({ name, email }),
  })
    .then(res => res.json())
    .then(data => {
      setUser(data.user);
      navigate("/dashboard");
    })
    .catch(() => {
      alert("Something went wrong");
    })
    .finally(() => setLoading(false));
}

✅ Better:

function handleFormSubmit(event) {
  event.preventDefault();

  const formData = getFormData(event);

  if (!isValidForm(formData)) {
    alert("Invalid form");
    return;
  }

  submitForm(formData);
}

function getFormData(event) {
  return {
    name: event.target.name.value,
    email: event.target.email.value,
  };
}

function isValidForm({ name, email }) {
  return name && email.includes("@");
}

async function submitForm(data) {
  try {
    setLoading(true);
    const response = await fetch("/api/submit", {
      method: "POST",
      body: JSON.stringify(data),
    });

    const result = await response.json();
    setUser(result.user);
    navigate("/dashboard");
  } catch (e) {
    alert("Something went wrong");
  } finally {
    setLoading(false);
  }
}

Mistake #4: Functions with many same-type params

When a function has several parameters of the same type — like booleans or strings — it’s easy to mix them up.

Instead, pass an object with named keys.

That way, it’s clear what each value is for — and you don’t need to jump to the function definition to understand what’s going on.

❌ Bad:

createUser("Alice", true, false, true);

✅ Better:

createUser({ name: "Alice", isAdmin: true, isVerified: false, isActive: true });

Mistake #5: Not cleaning up resources

Whenever you add an event listener, create intervals, set timeouts, or use useEffect in React, clean them up once they’re no longer needed.

If you don’t, you could end up with memory leaks, stacked event listeners, or ghost network calls.

For frontend apps that run for a long time (such as dashboards or admin panels), these bugs can significantly impact performance — or even crash your app entirely.

❌ Bad (React):

useEffect(() => {   window.addEventListener('resize', handleResize); }, []);

✅ Better:

useEffect(() => {
  window.addEventListener('resize', handleResize);
  return () => window.removeEventListener('resize', handleResize);
}, []);

Mistake #6: Unit-less variables

If a value has a unit — like milliseconds, pixels, or megabytes — include that unit in the variable name.

Otherwise, other devs (or future you) will have to guess what the number means.

❌ Bad:

const timeout = 3000; 

✅ Better:

const timeoutMs = 3000;

Mistake #7: Nesting conditionals >3 levels deep

When your logic is nested more than 2 or 3 levels, it becomes hard to read and reason about, especially if you have lots of if/else blocks.

Instead, try to “flatten” your code:

• Return early

• Invert the conditions

• Split logic into smaller functions

That makes each block easier to read and debug.

❌ Bad:

if (user) {
  if (user.isAdmin) {
    if (user.hasAccess) {
      // do stuff
    }
  }
}

✅ Better:

if (!user || !user.isAdmin || !user.hasAccess) return;

// do stuff

Mistake #8: Hardcoding URLs or config in the code

Hardcoding things like URLs, API keys, or environment-specific config is a trap.

The moment that value changes, you’ll have to hunt it down across the codebase.

Instead, store config values in constants or environment variables, then import them where needed.

You’ll avoid bugs, desyncs, and hours of wasted time.

❌ Bad:

fetch('https://api.example.com/posts');

✅ Better:

const API_BASE_URL = process.env.API_BASE_URL;
fetch(`${API_BASE_URL}/posts`);

Mistake #9: Keeping dead code “just in case”

We’ve all done it — comment out some code and leave it there “just in case.”

But here’s the truth: 99% of the time, no one will ever use it 😅. And no one wants to scroll past it.

Use GitHub or GitLab and delete that code.

❌ Bad:

// old validation logic (maybe needed later)
// function validateInput(input) { ... }

✅ Better: Just delete it.

Mistake #10: Giant “utils” files

The classic utils.js file always starts innocent, then slowly turns into a kitchen sink of random functions.

Before you know it, it’s hundreds of lines long and impossible to navigate.

Instead, colocate utility functions near the code that uses them.

Or, split them into focused files like arrayUtils.js, dateUtils.js, etc.

❌ Bad:

// utils.js
export function doStuff() {}

✅ Better:

// listUtils.js (next to List component)
export function getVisibleItems(items, filter) {
  return items.filter(item => item.visible && item.category === filter);
}

Mistake #11: Swallowing errors

If your code might throw an error, don’t just ignore it.

Swallowed errors are a nightmare to debug, especially in production.

Even a simple console.error can save hours of guessing.

And if users are affected, show an indication in the UI so they know something went wrong (instead of a blank screen).

❌ Bad:

try {
  riskyFunction();
} catch (e) {
  // nothing
}

✅ Better:

try {
  riskyFunction();
} catch (e) {
  console.error("Error in riskyFunction:", e);
  showToast("TODO: Useful error message + actions");
}

Mistake #12: One giant file

When everything is contained in a single file — components, logic, styling, and state — the file grows rapidly.

You end up with 800+ lines of scroll hell 🔥.

Instead:

• Split things up.

• Group related code into folders and give each file a clear role.

It lowers the cognitive load and makes onboarding new devs much easier.

❌ Bad:

// App.js — 1000+ lines of code

✅ Better: Split it up into folders:

/components
/context
/pages

Mistake #13: No linter

Linters like ESLint catch issues before they hit production, from simple bugs to missing React dependencies in useEffect.

They also help standardize code style across a team.

Please ensure you read and act on the warnings: don’t just slap // eslint-disable everywhere 😉.

❌ Bad:

useEffect(() => {
  fetchData();
}, []); // missing fetchData in deps

✅ Better: Use ESLint + React hooks plugin. It will warn you:

React Hook useEffect has a missing dependency: 'fetchData'.

Mistake #14: Messy folder structure

Your project folder shouldn’t feel like a junk drawer.

When files are scattered randomly, it’s challenging to find anything, and this difficulty is compounded when scaling the app.

Instead, use a structure based on features or domains. 

Group related files together so new devs can quickly understand what’s what.

❌ Bad:

/src
  App.js
  helpers.js
  styles.css
  randomStuff.js

✅ Better:

/src
  /components
  /services
  App.js

Mistake #15: Commenting obvious code

You don’t need to explain what let count = 0 means.

Trust your reader 😉.

If something’s confusing, try simplifying the logic or using clearer names.

Comments should explain why something is done, not what a line of code does.

❌ Bad:

// Set count to 0
let count = 0;

✅ Better:

let itemCount = 0;

Mistake #16: No comments for weird logic

Sometimes you need to add a workaround or support a legacy case.

That’s fine — but explain why.

Without a comment, your teammates (or future you) will waste time trying to understand what magicFix42(data) means.

Leave a short note. You’ll thank yourself later.

❌ Bad:

const result = magicFix42(data);

✅ Better:

// Applies patch for backend bug #321. Read ticket for more context 
const result = magicFix42(data);

Mistake #17: Rewriting what already exists

Don’t reinvent the wheel.

There are tons of small, reliable libraries built by people smarter than us.

If you can solve the problem with a trusted package, use it.

Just keep your dependencies in check so your bundle size doesn’t balloon (check my post ✨ How I Reduced My React Bundle Size by 30% (With Real Examples)).

🟠 Ok:

function debounce(fn, delay) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

✅ Easier:

import { debounce} from 'lodash-es';

const debouncedFn = debounce(myFn, 300);

Summary

Frontend code can get messy fast.

Avoid these 17 mistakes, and your code will be easier to read, debug, and maintain.

Your future self—and your teammates—will thank you.

Two weeks ago, I stumbled upon this post on Reddit: Should I learn React with TypeScript or JavaScript?

I see these posts all the time—and honestly, it breaks my heart 🥲

If you’re a React dev still using JavaScript, you’re making your life harder.

The time you spend learning TypeScript will 100% pay off in the time you save debugging weird bugs.

So here’s a guide to help you make the switch.

Just the essentials. No fluff 😉.

How TypeScript works

TypeScript adds extra syntax on top of JavaScript to help catch errors early—before they crash your app.

It compiles to JavaScript in the end.

The best part? You can slowly migrate to TypeScript.

Follow this guide for more.

Why you should switch to TypeScript ASAP

Here’s why I think it’s a no-brainer:

Benefit #1: Catch bugs before they reach production

This JavaScript code looks fine… until it explodes:

function printFirstChar(users, userIndex) {
  const name = users[userIndex];
  console.log(name[0]);
}

const users = ['Fatou', 'Bob'];

printFirstChar(users, 5); // ❌ Runtime error: Cannot read properties of undefined

Here’s the TypeScript version:

function printFirstChar(users: string[], userIndex: number) {
  const name = users[userIndex];

  if (name != null) {
    console.log(name[0]);
  }
}

TypeScript doesn’t fix your logic, but it gives you early warnings like “hey, this might be undefined 👀”

Benefit #2: Get autocompletion with libraries

Especially useful when you're exploring a new library.

If that library has TypeScript types, you can get autocompletion inside most editors.

Benefit #3: Make your code more resilient to changes

When you type things properly, TypeScript acts like a safety net.

For example:

Without TypeScript, this code can break without you noticing.

function getLabel(status) {
  switch (status) {
    case 'idle':
      return 'Idle';
    case 'loading':
      return 'Loading';
    case 'success':
      return 'Success';
  }
}

getLabel('loading'); // ✅ works

// Months later...

getLabel('error'); // ❌ returns undefined, but no JS error

With TypeScript, you need to handle changes.

type Status = 'idle' | 'loading' | 'success';

function getLabel(status: Status): string {
  switch (status) {
    case 'idle':
      return 'Idle';
    case 'loading':
      return 'Loading';
    case 'success':
      return 'Success';
    case 'error':
      return 'Error';
  }
}

// Months later...
type Status = 'idle' | 'loading' | 'success' | 'error'; // added 'error'

// ✅ TypeScript will show an error for the `getLabel` function: "Not all code paths return a value"

If you forget to handle a case, TypeScript yells at you. And that’s precisely what you want 😄.

TypeScript error when we forget to handle a case

The TypeScript concepts you need for React

Let’s cover the bare minimum to get started.

✅ Types

Types let you describe the shape of your data and enforce it.

There are native types in TypeScript, and types defined by users.

Native types

These types come by default.

const name = 'Ada'; // string
const age: number = 31; // number
const isActive = true; // boolean
const scores: number[] = [90, 85, 100]; // number[]

Custom types

You can create new types using the native types.

type User = {
  id: number;
  name: string;
};

const user: User = {
  id: 1,
  name: 'Fatou',
};

❌ Avoid any

Unless you’re in the middle of a migration, don’t use any.

It’s JavaScript in disguise.

Use unknown instead—it forces you to check the type before using it.

// ❌ Bad: no warning, crashes at runtime
function logLength(value: any) {
  console.log(value.length);
}

logLength(123);

// ✅ Safer
function logLength(value: unknown) {
  if (typeof value === 'string' || Array.isArray(value)) {
    console.log(value.length);
  }
}

// ✅✅ Better: use an explicit type
function logLength(value: string | ArrayLike<unknown>){
  console.log(value.length);
}

🧩 Union & intersection types

Unions let a value be one of many types.

type Status = 'idle' | 'loading' | 'error';

let currentStatus: Status = 'idle';

Intersections combine multiple types into one.

type Name = { name: string };
type Age = { age: number };

type Person = Name & Age;

const person: Person = { name: 'Ada', age: 30 };

🧱 Interfaces

Interfaces define the structure of an object.

interface User {
  name: string;
  age: number;
}

You can extend interfaces:

interface Admin extends User {
  role: string;
}

When to use type vs interface? Doesn’t matter much.

But here’s an interesting guide:

👉 Type vs Interface: Which Should You Use?

🔁 Generics

Generics let you write reusable types with flexible data.

Let’s say you’re typing an API response.

Without generics:

type UserResponse = {
  status: number;
  data: User;
  error?: string;
};

type ProductResponse = {
  status: number;
  data: Product;
  error?: string;
};

That’s a lot of repetition.

With generics:

type ApiResponse<T> = {
  status: number;
  data: T;
  error?: string;
};

type UserResponse = ApiResponse<User>;
type ProductResponse = ApiResponse<Product>;

You can use generics in functions too:

function wrap<T>(value: T): T[] {
  return [value];
}

wrap(42); // type: number[]
wrap('hi'); // type: string[]

I like to think of generics like function parameters—but for types 😉.

🔧 Function types

You can type function parameters and return values.

You always need to type the parameters, but don’t need to type the returned value every time.

// This works
function add(a: number, b: number): number {
  return a + b;
}

// This also works: you don't need to type the returned value
function add(a: number, b: number) {
  return a + b; // inferred as number
}

You can also type the function variable:

const add: (a: number, b: number) => number = (a, b) => a + b;

Depending on the context, you may want to type the return type. When in doubt, type the return type.

You can learn more about return types here:

• TypeScript Style Guide: Return Types

• Don’t use return types, unless...

How to use TypeScript with React

Props

Props are just objects. Type them like any other object.

With type:

type GreetingProps = {
  name: string;
};

function Greeting({ name }: GreetingProps) {
  return <p>Hello {name}</p>;
}

With interface :

interface GreetingProps {
  name: string;
}

function Greeting({ name }: GreetingProps) {
  return <p>Hello {name}</p>;
}

State

useState accepts a generic type, but TypeScript can also infer it.

const [count, setCount] = useState(0); // inferred as number

But if it can’t, be explicit:

const [user, setUser] = useState<{ id: number; name: string } | null>(null);

Component variables and functions

Just like normal TypeScript:

const users: User[] = [{name: "Fatou", age: 31}, {name: "Bob", age: 25} ];
const age = 30; // inferred as number

When you have some functions like event handlers, you can hover over the DOM elements to see the types to use.

const handleClick = (event: React.MouseEvent<HTMLButtonElement>) => {
  console.log('Clicked!', event);
};

// Or:
const handleClick: React.MouseEventHandler<HTMLButtonElement> = (event) => {
  console.log('Clicked!', event);
};

Re-using types across components

You can extend or combine types/interfaces to avoid duplication.

With interfaces:

interface ButtonProps {
  label: string;
}

interface IconButtonProps extends ButtonProps {
  icon: React.ReactNode;
}

With union types:

type ButtonProps = {
  label: string;
};

type IconButtonProps = ButtonProps & {
  icon: React.ReactNode;
};

Hooks

Hooks are just functions, so you can use the same TypeScript tools that apply to functions.

Native hooks

Pretty much all the native hooks have generic params.

const [count, setCount] = useState<number>(0);
// or let TS infer:
const [count, setCount] = useState(0);

const inputRef = useRef<HTMLInputElement>(null);

const [state, dispatch] = useReducer(
  (state: number, action: 'inc' | 'dec') => {
    switch (action) {
      case 'inc':
        return state + 1;
      case 'dec':
        return state - 1;
    }
  },
  0
);

Custom hooks

function useToggle(initial: boolean): [boolean, () => void] {
  const [state, setState] = useState(initial);
  const toggle = () => setState((prev) => !prev);
  return [state, toggle];
}

const [isOpen, toggleOpen] = useToggle(false);

Where to learn more

If you want to go deeper with TypeScript, here are some great resources to explore:

• 🧠 TypeScript Official Docs: The best place to start. It’s clear, well-structured, and packed with examples. Also includes a playground to test things out.

• 🎯 Total TypeScript: A fantastic site by Matt Pocock—especially for React devs.
  It has a free beginner course, advanced patterns, and many real-world examples.

• ✨ TypeScript Style Guide: Short, practical tips on how to write clean and consistent TypeScript code. Highly recommended once you start building real apps.

• 🧩 Type Challenges: A collection of TypeScript puzzles—from beginner to insane. Great if you learn best by solving problems and want to flex your type system skills.

• 📘 Effective TypeScript: A book + blog by Dan Vanderkam. More advanced, but teaches you how to write better TypeScript. Worth it once you know the basics.

• ⚛️ React TypeScript Cheatsheets: Tailored for React devs. Covers everything from typing components to context and hooks. Very beginner-friendly, and super helpful as a quick reference.

Summary

Using TypeScript with React is one of the best upgrades you can make.

It helps you catch bugs early, gives you better tooling, and makes your code easier to maintain.

The best part? You don’t need to learn everything up front. Start with the basics—types, interfaces, generics—and grow from there.

Many examples are online if you get stuck, and AI tools can help you unblock fast.

Let me know if you have any questions 🙂.

AI-generated image showing a woman at a crossroads

3 years ago, I found myself at a crossroads.

I was enjoying the work and the learnings, but I couldn’t clearly articulate my impact—or even tell if I was heading in the right direction.

I was doing the work I was asked to do, going with the flow, not questioning anything.

After some reflection, I realized I did want to grow—both financially and technically—but my current actions wouldn’t get me there.

That’s when I saw I was making the same mistake most juniors make:

Fast forward a few months, I became the go-to dev for a product and started making real career progress.

In this post, I’ll share:

• Why it’s important to own your growth

• Why it’s so tempting to fall into the trap

• And what you can do about it

Let’s dive in 👇

What it means to own your career growth

AI-generated image showing a person climbing a staircase made of sticky notes or stepping stones labeled “Goal,” “Skills,” “Feedback,” “Growth.”

When I say “own your career growth,” I mean:

• Being intentional about your work and whether it’s taking you where you want to go

• Advocating for yourself—sharing your goals and expectations

• Having a rough vision of where you want to be in 1, 3, 5, or even 10 years

Now, let’s look at why this matters.

Why it’s important to own your career growth

AI-generated image showing a superhero version of a dev tearing open a shirt with a glowing "YOU" on the chest

Reason #1: Only you know what you truly need

Even with the best manager in the world, only you know what drives you.

Is it more pay? More ownership? More technical challenge?

Everyone’s different. So your version of growth will look different than your colleague’s.

You have to own that. No one else will.

Reason #2: “If you don't have a plan, you become part of somebody else's plan.”

The more you say “yes,” the more you risk ending up on projects that don’t serve you long-term.

Unless you want to be a “yes” person—which is totally valid 🙂—have opinions about where you want to grow.

Because if you don’t have a plan, rest assured you’ll be helping execute someone else’s. And that might not be what you want.

Reason #3: Goals make the journey more satisfying

I thrive on setting goals and reaching them.

It gives me a sense of progress. A feeling that I’m getting better.

But that feeling disappears if all I do is jump from project to project with no cohesion.

And work becomes... meh 🤣.

Why you might not be owning your growth (yet)

Especially early on, it’s easy to fall into one of these traps:

AI-generated image showing a developer snoozing at a desk while opportunities (represented by rockets or paths) fly past in the background.

Trap #1: You're just happy to be here

When I landed my first dev job, I was blown away—getting paid that much for work I mostly enjoyed? Wild.

I got comfortable. Too comfortable. I wasn’t pushing myself or questioning the work.

But eventually, I realized:

If your work feels disconnected, it’s hard to tell what you’re becoming great at—or what makes you unique.

Once the joy of simply “being in tech” disappears, start thinking about your next milestones.

Trap #2: You think learning = progress

If you want to explore and learn as much as possible, that’s 100% valid. That’s a plan in itself.

But don’t confuse learning with progress.

You can know everything in the world—but if you’re not applying it in ways that move the business or your career forward, that knowledge won’t help much.

To grow (especially in pay), you must build deep expertise in something.

T-shaped skills are a great model here.

Trap #3: You don’t know what’s possible

Good news—this one’s easy to fix.

You can:

• Talk to role models in your company. Ask how they got where they are. Or just watch them closely.

• Ask your manager about growth paths that align with your strengths.

• Start with life goals. Need to buy a house? Pay for kids’ school? Cool—reverse-engineer what you’ll need in skills, roles, and pay to get there.

How to start owning your growth

Here’s what worked for me when I decided to become a major actor in my career 😅:

AI-generated image showing a pen in someone’s hand, writing their story, with a caption bubble: “Write your own story.”

Step #1: Set goals

Set SMART goals—specific, measurable, and realistic.

I had a simple written goal: Become the go-to dev for this product.

Fast forward to today, I am the dev lead for that product.

Having that goal gave me clarity and direction.

Step #2: Track your progress

Without tracking, goals are just dreams.

Make sure you’re doing something each day that moves you toward them.

Step #3: Share your goals

Let your manager and teammates know what you’re aiming for.

They can’t help you if they don’t know what you care about.

Once you share your goals, people will start forwarding you the right projects—and stop handing you stuff that doesn't align.

Step #4: Evaluate tasks through your goals

Now that you know where you’re headed, filter your tasks through that lens.

If something doesn’t move you closer, either:

• Delegate it

• Or knock it out quickly and move on

Step #5: Take initiative when the path isn’t clear

Sometimes, no task or project helps you grow in the way you want.

That’s okay.

But don’t stay stuck.

You can:

• Push for new projects or initiatives

• Switch to a better-fit team

• Or, if needed, change companies entirely

Step #6: Copy what works

Working with great colleagues? Lucky you.

Watch them. Steal Copy their playbook.

If someone’s doing what you want to be doing, study how they act, what they prioritize, and how they communicate.

Then try those things at your level.

It works.

Summary

If you landed a job in tech—congrats 🎉
You earned it.

But don’t get stuck in “grateful mode.”

Don’t use that as an excuse to take every task, say yes to everything, or never question the direction you're headed in.

Be intentional. Be strategic. Own where your day is taking you.

Because especially in a world with AI and layoffs, you don’t want to wake up one day and realize you weren’t building the right skills.

Remember:

Ever had this happen?

You start building a new frontend app.

Everything is fast. Production builds take seconds. Users are happy 🥰.

But as time goes on…

• Build times start to drag.

• The app feels slower.

• Users complain.

You’re unsure why — you’ve just been writing “normal” code.

What’s going on?

99% of the time, it’s because your bundle size spiraled out of control.

In this post, I’ll show you 7 proven ways to reduce bundle size and speed up your builds — with a real demo you can try.

⚡️ Before vs After

By the end of this guide, we will go from:

📦 283.39 kB → 198.33 kB

That’s a 30%+ size reduction, just by applying simple tips.

🛠️ Setup

For this demo, I built a React app (generated with V0) available on GitHub:

👉 GitHub repo

Demo application

Key details:

• Run npm run build to bundle the app for production.

• Each optimization step has a dedicated branch (step-1-remove-side-effects, step-2-remove-unused-files-packages, etc.).

• The main branch contains the unoptimized version, and the fully optimized code is in the step-7-lazy-load-components branch.

Tooling

I used vite-bundle-analyzer to visualize bundle contents.

Here’s the initial bundle from the main branch:

Bundle graph generated on main branch

Step #1: Eliminate Side Effects in Files

👉 Code changes

Bundlers rely on tree-shaking to exclude unused code from the final bundle—unless a file has side effects (see #Benefit 3 in my post about bundlers).

Side effects (like modifying the window object) force the bundler to include the file, even if unused.

🧪 Example:

In our demo, the file HelloWorld.js contains a side effect:

window.someBadSideEffect =
  "I'm a side effect and I will be included inside the bundle even if not used";

Result:

Even though the file isn’t used, its code appears in the bundle file (dist/assets/index-[hash].js).

Fix: Remove the side effect. The file is now excluded from the bundle.

Demo opening the final bundle file and showing the side effect code

Image of the final bundle file without the side effect

Step #2: Hunt Down Unused Files & Packages

👉 Code changes

Unused files/packages usually don’t bloat your bundle—but they:

• Slow down bundling (more files to process).

• Risk breaking tree-shaking (if they contain side effects).

Tool Recommendation:

Run npx knip or npx depcheck to detect dead code.

In our demo:

• HelloWorld.js and lodash-es were flagged as unused.

• After removing them, the number of modules processed dropped from 44 to 42.

The impact would be more significant in more complex applications, and your app will build even faster ⚡️.

Results of running npx knip

The build results before/after the removal

Step #3: Avoid Barrel Files

👉 Code changes

Barrel files (like src/components/index.js) consolidate exports for cleaner imports:

import { Dashboard, UserManagement, Settings, Clock } from "./components";

But they introduce downsides:

• Side effects propagate: If any exported file has side effects, the bundler can include it. This is why the side effects were present in Step #1.

• More files to process: The module bundler will have to process more (or even irrelevant files if someone forgot to delete them). This results in slower builds.

In my demo app, I removed all the barrels in the step-3-remove-barrel-files branch.

Result: The number of modules transformed went from 42 → 37.

The build results before/after removing barrel files

Step #4: Export Functions Directly, Not Objects/Classes

👉 Code changes

When you export an object or class, all its methods are bundled—even unused ones.

In our demo app, the time.js file exports a utility object, but only getTimeInFormat is used. Yet, the entire object landed in the bundle.

Before: The bundle file with the unused methods

Fix: Export functions individually. Now, unused utilities are stripped automatically.

Result: There is a slight decrease in the bundle size.

After: The bundle file without unused functions

Step #5: Swap Heavy Libraries for Lighter Alternatives

👉 Code changes

This is a big one.

In the demo app, I used moment.js.

But if you check Bundlephobia, you’ll see it’s huge.

A better choice? dayjs — smaller and modern.

Swapping moment for dayjs gives you an instant bundle size drop.

Pro tip: Also check for ESM support—it helps with tree-shaking.

Bundle graph with moment.js

Bundle graph with dayjs

The build results before/after removing moment.js

Step #6: Lazy-Load Non-Critical Packages

👉 Code changes

If a package isn’t needed immediately, don’t load it at startup.

Example:
I use Fuse.js for fuzzy search, but only when the user starts typing.

Solution:
Instead of importing it statically, I load it when needed using dynamic imports:

// Lazy load Fuse.js
const Fuse = import("fuse.js").then((module) => module.default);

Result: fuse.js splits into a separate chunk, reducing the initial load.

Before: Bundle graph with fuse.js used directly

After: Bundle graph with fuse.js imported dynamically

The build results before/after importing fuse.js dynamically

Step #7: [React] Lazy-Load Non-Critical Components

👉 Code changes

Same idea — if components aren’t needed at startup, don’t load them immediately.

In my demo, files like Dashboard.jsx and Settings.jsx are only required when the user clicks a button.

So I lazy-load them using React.lazy:

const Settings = lazy(() =>
  import("./components/Settings").then((module) => ({
    default: module.Settings,
  }))
);

Result: A smaller initial bundle, which results in faster first load of your app.

Bonus 🪄

A few more ideas you could explore:

• Add "sideEffects": false in package.json to improve tree-shaking

• Use Bundlewatch or Size Limit to monitor size in CI

• Enable more code-splitting or compression with Vite plugins

✅ Cheatsheet

Quick recap of everything we did:

✅ Remove side effects from files  
✅ Delete unused files and packages  
✅ Avoid barrel files  
✅ Export functions directly  
✅ Use smaller libraries (dayjs > moment)  
✅ Lazy-load heavy packages  
✅ Lazy-load components 

👉 Code changes

Summary

Frontend apps often get slower over time — even without adding “heavy” code.

But if you apply these tips regularly, you can stay fast, keep build times short, and make life easier for your team and users.

Got other tips? I'd love to hear them 🙂.

On my first work assignment, I thought I was doing great work 😎.

I was talking to customers, handling their requirements, making them happy, etc.

However, to my surprise, my manager didn’t share my point of view.

She didn’t realize all the work I was doing and couldn’t articulate the value I was providing.

I was pretty shocked. I thought my work was speaking for itself.

We agreed that I would post a daily update in the team chat to keep them informed. I still didn’t see the need.

But hey, why not?

Fast forward to today—as a team lead, I totally get it 😅.

If I don’t hear from a junior dev on my team regularly, I start getting slightly worried that things are going wrong.

Even with meetings, it’s impossible to have an accurate picture of what everyone is doing unless they communicate it.

In this post, I’ll share why you must over-communicate as a junior dev—and how to do it properly.

What Happens When You Don’t Over-Communicate

Imagine you ask your younger sibling (3-4 years old) to help you with something.

They’ve never done it before and have no experience.

How would you feel if they stayed silent the whole day?

Chances are, you’d feel uneasy—scared they might be doing something completely wrong (and your mom will kill you 😅).

Having a junior dev on the team can feel the same way 😅.

As mentors, our responsibilities are to:

• Make sure they are doing as well as they can

• Prevent them from going down rabbit holes

• Ensure they don’t make mistakes and try to fix them in silence

So when a junior dev doesn’t communicate progress often, something feels off.

As a junior dev:

• You should have multiple questions daily.

• You should encounter blockers (and ask for help).

• You should share progress frequently.

Even if you’re amazing and don’t need help, you should communicate progress at least twice daily (personal preference).

If you don’t, your mentors will feel stressed or have to ping you regularly.

As a rule of thumb: After the first few weeks, no one should have to ask you for status updates.

How to Over-Communicate Properly

This is as easy as it gets.

It depends on your circumstances:

• If you sit next to your manager or team lead, talk to them periodically—ask questions, provide status updates, etc.

• If you’re remote, send updates using your team’s communication channels (Slack, messages, etc.).

As a junior dev staffed on a task, you should:

• Clarify how long the task is expected to take

• Work your best to meet expectations by asking for help when needed

If you can split your task into smaller steps, that would be even better. This will clearly show that you’re actively working and making progress.

In general, communicate with your manager about:

• Anything wrong—even if it’s not your fault (e.g., issues caused by another team that impact your work)

• Anything blocking or bothering you

Communication doesn’t always have to be written. Opening pull requests and writing code are also ways to show progress.

Over time, you’ll have to communicate less because your manager will trust that you can work independently.

Your Challenge This Week:

If you’re a junior developer, evaluate how often your manager has to ping you for an update.

• If they regularly ping you, start giving them updates before they ask.

• If they don’t, that’s a good sign—but it could also mean they don’t want to be intrusive or don’t care.

Either way, make sure you share daily progress on your tasks.

Summary

Even if you’re doing an excellent job as a junior dev, your main job is to reassure your manager/team lead by over-communicating.

Share updates as often as possible (at least twice daily).

The more you do this, the more trust you’ll build. Over time, you’ll have to do it less frequently 😉.

🍔 FOOD FOR THOUGHT

Twitter tweet

When I first heard module bundler as a front-end developer, I thought, “What is that magic again?” 😅

I remember trying to read about them or even use one, but I didn’t see the usefulness.

All I knew was that every article recommended using module bundlers like Webpack—and setting them up was hell 🔥.

I later realized that they’re one of the most crucial parts of modern frontend development, and you absolutely need to understand them.

In this post, I’ll share what I wish I had known about module bundlers.

Let’s get started. 🚀

First, what do module bundlers do?

Let’s start with an example.

For this post, I made a React app called demo_bundling_esbuild (Github code).

It’s a simple app that displays my name, age, and other personal information. (I know it's it's a bit self-centered 😅)

It uses esbuild as a module bundler and is structured like this:

project/
├── src/
│   ├── App.tsx
│   ├── index.tsx
│   ├── data.json
│   ├── utils.ts
│   └── constants.ts
├── index.html
├── build.js
└── package.json

Once I finished development, I needed to build the app so I could have an index.html file to load in the browser.

This is roughly what the app looks like:

Demo Application Using Bundling

But then something interesting happens...

When I open my Network tab, I don’t see the same files as in my code editor.

I can see the index.html file, but where are App.tsx, index.tsx, and constants.ts? 🤷‍♀️

Instead, I see a single file: dist/bundle.js.

When I open it (see gif below), I find the content of App.tsx, index.tsx, and utils.ts—but in a weird/minified format.

Demo opening the network tab and looking at the files loaded

Bundle size content

So, what happened?

How did I go from 5 files (index.tsx, utils.ts, constants.ts, App.tsx, data.json) to 1 file (dist/bundle.js)?

How did all these files turn into a single big file?

👉 Bundling happened.

My module bundler (esbuild) took all the .ts and .json files and compiled them into one file: dist/bundle.js.

PS: You can find the configuration here 👉 build.js.

Bundling diagram

In summary:

• Module bundlers are tools that combine multiple files in your codebase into fewer files.

And this is amazing for several reasons.

Why bundling is important

Benefit #1. It ensures your dependencies load in the correct order

If you’re using dependencies (i.e., npm packages), you probably import them like this:

import { partition } from "lodash-es";
import { v4 as uuidv4 } from 'uuid';

In the past, these imports didn’t work in all browsers.

Module bundlers solve this by ensuring that dependencies load correctly.

For example, if File A depends on File B, which depends on File C, the bundler makes sure all necessary files are present before execution.

Benefit #2. It reduces the number of HTTP requests

Without bundling, every file would need to be loaded separately.

Browsers limit the number of parallel network requests, so for large apps, this could mean waiting minutes (or even hours) just for files to download and parse.

Bundlers reduce the number of files (usually 1–2 for small apps), significantly speeding up the loading process.

Benefit #3. It optimizes the size of your files

Before bundling your files, module bundlers apply optimizations to make them as small as possible.

Some of the key optimizations include:

• 🌴 Tree-shaking: If you import a package but don’t use it, the bundler doesn’t include it in the final bundle. The bundler only consists of the code needed.

• ✂️ Minification: It removes unnecessary whitespace and comments and renames variables to make files smaller.

In our example app, I have a constant called NOT_USED_CONSTANT that I am importing inside index.tsx but not using. So it won’t be inside bundle.js.

Benefit #4. It enables dynamic imports (a.k.a. code-splitting)

Let’s say part of your app is only needed for specific users (e.g., a dashboard for logged-in users).

You don’t want to load everything upfront—you want to lazy-load that code only when needed.

You can tell your module bundler to “put some piece of code in a separate file and load it only when required.

When you do this, you increase your app speed 🚀 since there are fewer files to download.

Benefit #5. (Bonus) It supports different file types (.ts, .json, etc.)

By default, bundlers work with JavaScript files.

But they also support other formats (.ts, .json, .jsx, etc.) using loaders (Webpack, Esbuild, etc.)

Without this, you’d need to manually process these files before bundling them.

Do I need to know how to configure a module bundler?

👉 No.

Unless you’re very unlucky, you shouldn’t have to.

For this post, I asked v0.dev to generate the esbuild setup for me 😅.

In my professional life, I’ve never had to configure bundlers myself—our great infra team handles it.

If you don’t have an infra team, here are your options:

• Use tools (like Vite) that configure bundlers for you.

• Google how to do it (plenty of examples out there).

• Ask AI (which is what I did).

Summary

Module bundlers (esbuild, Rollup, Webpack, etc.) are not hard to understand.

They take many files and output fewer files.

They’re useful because they:

✅ Ensure dependencies load in the correct order.
✅ Reduce the number of HTTP requests needed.
✅ Optimize file sizes for faster downloads.
✅ Enable code-splitting for better performance.
✅ (Bonus) Support non-JS files like .ts and .json.

So, pick a bundler, play with it, and see it in action.

In my next post, I’ll share tips to optimize bundle size.

🍔 FOOD FOR THOUGHT

Twitter tweet

Do you constantly look under-confident at your job and need to be pumped?

If yes, stop.

It’s OK to feel overwhelmed, but it’s not OK to constantly show it.

In this article, I will explain why it’s important to display confidence and how to achieve it.

Table of Contents

• Why it is important to display confidence

  • Reason #1: The more confidence you display, the ea …

  • Reason #2: The more confidence you display, the mo …

  • Reason #3: The more confidence you display, the le …

• How to Build (and Show) Your Confidence

  • Hack #1: Don’t bite more than you can chew

  • Hack #2: Give yourself permission to ask for help

  • Hack #3: Take regular breaks

  • Hack #4: Track your achievements regularly

  • Hack #5: Share experiences with your peers or disc …

• Summary

THIS WEEK SPONSOR 💰

The Daily Newsletter for Intellectually Curious Readers

If you're frustrated by one-sided reporting, our 5-minute newsletter is the missing piece. We sift through 100+ sources to bring you comprehensive, unbiased news—free from political agendas. Stay informed with factual coverage on the topics that matter.

Join for free today!

Why it is important to display confidence

Have you noticed how we are all attracted to confident leaders?

Because they are reassuring and look like they know where they are going.

Well, turns out confidence is not just a good thing for leaders.

It will also tremendously help you as a junior frontend dev.

Here are 3 reasons why:

Reason #1: The more confidence you display, the easier it is to trust you

Imagine you are sick 🥴.

You go to the hospital and have the option between two doctors for your treatment.

• The first doctor talks confidently, speaks assertively and can reassure you while being honest.

• The second doctor talks tentatively, hesitates a lot, and doesn’t give you a clear answer.

Which doctor are you more likely to choose?

If you’re like me and most people, you would choose the first doctor.

Because if someone doesn’t trust themselves, why should you trust them?

This also applies to you as a junior frontend dev.

If you don’t trust yourself and make this evident to everyone, it will be harder for others to trust you.

Reason #2: The more confidence you display, the more ownership you can get

Since you get more trust, you’ll also have more opportunities than a less confident dev.

And when you can turn these opportunities around, you get even more ownership.

Reason #3: The more confidence you display, the less effort it takes to reassure you

Unfortunately, people will generally try to comfort you when you show under-confidence.

This is OK in small doses.

However, if you consistently need reassurance, it could be tiring in the long term.

Time that could have been spent mentoring you is now spent comforting you.

This is rarely sustainable.

How to Build (and Show) Your Confidence

Displaying confidence is hard.

I know because I still have to force myself to do it after 5+ years of experience 😅.

However, you can use these 5 hacks to feel and look more confident.

Hack #1: Don’t bite more than you can chew

This hack is obvious.

However, it is easy to fall into this trap 🪤.

We generally fall into it because:

• We volunteer for too many projects to show willingness

• We volunteer for projects without knowing the scale or discussing with a more senior dev first

• We suffer from people-pleasing and can’t say “No”

Unfortunately, when you bite more than you can chew, your confidence will take a toll since you are more likely to:

• underperform on tasks and lose some of your confidence

• overwork, which leads to tiredness and feeling overwhelmed

• etc.

What to do instead:

• Have a clear idea of your workload and make it clear to your manager

• Only volunteer for projects you have 100% confidence in at the beginning, then be more audacious over time

• Re-evaluate your workload with your manager regularly (and drop some tasks if needed)

Hack #2: Give yourself permission to ask for help

Whenever I felt under-confident, I wanted to do everything alone and didn’t want to ask for help.

As a result, I would get stuck and not ask for help 🤪.

This would undermine my confidence since I was expecting to do something, then realized I couldn’t.

A good remedy is to ask for help when you’re stuck after some time.

This is great because:

• It stops the stress buildup since you’re forced to stop and interact with others

• It helps you brainstorm with other people and feel less alone

• It often enables you to realize the task was more challenging than you expected

Hack #3: Take regular breaks

After working long hours, your productivity drops, and further work can become counterproductive.

Your brain is tired, and you make more mistakes than actual progress.

Unfortunately, this can break your confidence since you keep spending time on the problem without progress.

The solution is simple: take regular breaks. At least one break every 90 minutes.

Unfortunately, this can be hard to do (at least for me 😅).

What helps is to:

• Schedule catchups/meetings that force you to stop

• Interact with your colleagues

• Do something not related to coding, like code reviews

Hack #4: Track your achievements regularly

You may not realize it, but you’ve already achieved much as a junior frontend dev 👏.

Unfortunately, it’s easy to focus on what you don’t know instead of what you’ve learned.

This can undermine your confidence since you feel like you don’t know enough.

I have some good news: “None of us know enough. What we don’t know is way more than what we know.”

So don’t let this hold you back.

Have a place to track your achievements to see how far you’ve already come.

This will boost your confidence 💪.

Hack #5: Share experiences with your peers or discuss your journey with others

As soon as you talk with other junior devs or senior devs about their early experiences, you’ll realize that feeling overwhelmed is normal.

In fact, the tech space is fast-changing, complex, and varied.

It’s normal to feel overwhelmed initially, especially when navigating old code or completing your first tasks.

Instead of panicking, embrace the process 😌.

Expect discomfort to be part of the job.

Stay calm and learn.

Summary

Feeling overwhelmed as a junior frontend developer is normal.

However, just because you feel overwhelmed doesn’t mean you have to show it.

Instead, strive to display confidence so you get more opportunities and trust.

Ensure you don’t bite more than you can chew, build a support system, and interact with your peers.

I trust you’ll be successful 🚀.

Reach out to me on Bluesky/X if you have any questions.

🐞 SPOT THE BUG

Twitter tweet

🍔 FOOD FOR THOUGHT

Twitter tweet