DEV Community: Ndeye Fatou Diop

Devs: Own your growth — or regret it later

Ndeye Fatou Diop — Thu, 10 Jul 2025 10:00:00 +0000

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! 🚀

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

What it means to own your growth as a dev

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

Being clear about where you want to be in 1, 3, and 5 years.
Sharing your goals with people who can help you.
Having a plan to reach your goals (and refining it with your manager).
Following up on the plan.
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:

Made this goal clear to my manager.
Talked to as many people as possible who’d made the switch.
Applied all their tips (learned JavaScript, contributed to the product, etc.).
Shared my progress regularly with my manager.
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:

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.
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.”
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.
Work toward the plan every day:

Show up consistently. Small steps daily beat occasional giant leaps.
Share your progress:

Don’t be shy. Sharing wins builds trust and shows commitment.
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.
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 💪.

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.

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

✨ 17 React Hooks That Power 90% of Modern Components

Ndeye Fatou Diop — Tue, 20 May 2025 17:32:36 +0000

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 🎉.

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

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.

Prop drilling = passing props through multiple layers just to reach a deeply nested component.

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

If you’re not comfortable with React components lifecycle, check my post ✨ React Lifecycle in 3 Minutes 😉.

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 😉.

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.

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

✨ 7 Things I Do Regularly as a Senior Frontend Developer

Ndeye Fatou Diop — Wed, 07 May 2025 14:00:00 +0000

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! 🎉

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

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.

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.

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.

💡 Check out these examples of large, production-grade open-source React apps.

Habit #6: Teach back what you learn

“If you can't explain it simply, you don't understand it well enough.” — Albert Einstein

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.

💡 Quick tip: if it’s a piece of code you use often but don’t want to memorize, save it as a snippet (like in VS Code snippets).

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 🙂.

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.

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

✨ Don’t do this (unless you want sh*t frontend code)

Ndeye Fatou Diop — Mon, 05 May 2025 14:30:00 +0000

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

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.

<iframe src="https://embeds.beehiiv.com/4b52f101-5150-4e42-abc6-28785fdd68cd" data-test-id="beehiiv-embed" width="100%" height="320" frameborder="0" style="border-radius: 4px; border: 2px solid #e5e7eb; margin: 0; background-color: transparent;"></iframe>

That's a wrap 🎉.

Leave a comment 📩 to add one more tip.

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.

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

Typescript to Know for React

Ndeye Fatou Diop — Wed, 16 Apr 2025 11:00:00 +0000

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

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[]

💡 In some of the examples above, I typed values explicitly (like const age: number = 31).

You don’t need to do that in real code—TypeScript can infer the types by looking at the values.

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:

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.

💡 Make sure to also check out the TypeScript section of my 101 React Tips & Tricks post 😉.

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 🙂.

<iframe src="https://embeds.beehiiv.com/4b52f101-5150-4e42-abc6-28785fdd68cd" data-test-id="beehiiv-embed" width="100%" height="320" frameborder="0" scrolling="no" style="border-radius: 4px; border: 2px solid #e5e7eb; margin: 0; background-color: transparent;"></iframe>

That's a wrap 🎉.

Leave a comment 📩 to join the discussion.

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.

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

Why Junior Developers Must Seize Control of Their Growth Journey Today

Ndeye Fatou Diop — Thu, 10 Apr 2025 07:00:00 +0000

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:

Not owning your growth and just letting things be.

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

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

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:

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:

Progress is important.

Especially progress in the right direction.

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 😅:

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:

“When writing the story of your life, don't let anyone else hold the pen.”

How I Reduced My React Bundle Size by 30% (With Real Examples)

Ndeye Fatou Diop — Mon, 07 Apr 2025 13:50:00 +0000

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

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

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.

💡 Note:

- Each step builds on the previous one: branch step-3-… includes fixes from step-1-… and step-2-…

- I’m using global CSS here (for speed). In real apps, prefer CSS Modules or tools like Tailwind.

Tooling

I used vite-bundle-analyzer to visualize bundle contents.

Here’s the initial bundle from the 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.

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 ⚡️.

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.

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.

Fix: Export functions individually. Now, unused utilities are stripped automatically.

Result: There is a slight decrease in the bundle size.

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.

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.

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 🙂.

That's a wrap 🎉.

Leave a comment 📩 to share more tips.

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.

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

✨ Your Manager Should Never Have to Ping You

Ndeye Fatou Diop — Sun, 16 Mar 2025 13:37:58 +0000

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.

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

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.

Caveat: My advice applies to someone in a healthy team—which has been my case for the past six years at Palantir. If that’s not your case, frequent questions may not be welcomed.

However, you should still communicate your progress regularly, even if it’s just: “I’m blocked by A and B, but I’m currently doing X and Y to get unblocked.”

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 😉.

That's a wrap 🎉.

Leave a comment 📩 to keep the discussion going.

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.

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

🍔 FOOD FOR THOUGHT

// Detect dark theme var iframe = document.getElementById('tweet-1897195388924494128-854'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1897195388924494128&theme=dark" }

✨ Module Bundlers, Demystified: What You Actually Need to Know

Ndeye Fatou Diop — Mon, 24 Feb 2025 14:00:00 +0000

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. 🚀

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

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:

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 in this gif link), I find the content of App.tsx, index.tsx, and utils.ts—but in a weird/minified format.

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.

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).

What matters is understanding what bundlers do so you don’t get in their way.

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.

That's a wrap 🎉.

Leave a comment 📩 to keep the discussion going.

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.

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

🍔 FOOD FOR THOUGHT

// Detect dark theme var iframe = document.getElementById('tweet-1875150173443362895-292'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1875150173443362895&theme=dark" }

✨ How to Be More Confident as a Junior Dev—Even When You’re Overwhelmed

Ndeye Fatou Diop — Thu, 23 Jan 2025 08:48:18 +0000

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.

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

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 🚀.

That's it.

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.

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

🐞 SPOT THE BUG

// Detect dark theme var iframe = document.getElementById('tweet-1879498832100442408-554'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1879498832100442408&theme=dark" }

🍔 FOOD FOR THOUGHT

// Detect dark theme var iframe = document.getElementById('tweet-1879438387150811498-216'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1879438387150811498&theme=dark" }

7 Critical Pitfalls New Developers Must Avoid in Their First Weeks

Ndeye Fatou Diop — Tue, 14 Jan 2025 13:00:00 +0000

For the past 6+ years, I’ve worked across 5+ teams at Palantir.

I wish someone had warned me about these 7 mistakes at the start of my career.

Ready? Let’s get started.

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

Mistake #1: Giving strong opinions about things you don’t fully understand yet

We want to prove our value during the first days of a job.

It’s natural to want to show your colleagues that you were worth hiring 😀.

However, this can lead to giving strong opinions on things you don’t fully understand yet.

Examples

Someone asks about testing → you proclaim, “It’s criminal not to have 100% coverage.”
Someone talks about state management libraries → you question why the team uses Redux and suggest Zustand.
The team decides to cut features to meet a deadline → you talk about how this would’ve backfired at your previous company, lost users, yada yada...

I can tell you right now: this will not land well 99% of the time.

Why?

You don’t have the full context, so your input is, at best, noisy and, at worst, counterproductive.
You waste your colleagues’ time as they argue or explain things to you.
You may come across as “show-offy” without realizing it. This isn’t the best way to make friends 😅.

So, should you keep quiet during your first weeks? Absolutely not.

You were hired to contribute to the team and share your perspective. However, make sure that:

You collect as much context about the team and product as possible—ask “why” first.
You don’t get too attached to your opinions. Present them as suggestions rather than hard truths.
You “show, don’t tell” whenever possible.

Mistake #2: Trying to figure out everything by yourself

Unless you’re the only person on your team, ask for help.

Ask after trying for a reasonable amount of time. What’s reasonable depends on the type of question:

If you’re sure you won’t find a solution even after an hour—or if the issue blocks your productivity—ask immediately. For example, you should ask questions like “How do I set up this computer to work with tests?” instantly.
If it’s a technical problem you can solve by Googling or using AI tools, try that first. If it doesn’t work, ask for help after 30 minutes.

Why ask for help?

You don’t know what you don’t know.
Time spent figuring out what others already know is time you could spend on productive work.

If you’re in an environment where help isn’t readily available, you’ll have to figure things out.

Make sure to document your findings for the next person. This builds a knowledge base and earns you “good teammate” points.

Mistake #3: Focusing too much on onboarding and ignoring your colleagues’ work

I’m super introverted 🙈.

So, I find it hard to reach out randomly to new people.

However, whenever I’ve joined new teams, I’ve forced myself to talk to teammates—and it’s always paid off.

How?

Onboarding felt less intimidating when I realized my colleagues were normal people willing to help.
I gained valuable context and understood what mattered most to the team.
I built a network of people I could turn to for support.

So, as soon as you join a new team, set up 1-on-1 meetings with teammates.

Ask them about their work, the team’s history, how they see their role, and any advice they might have.

Mistake #4: Trying to memorize everything

On my first team, I felt super lost 😅.

People used acronyms in meetings, and I struggled to follow conversations. Even when I knew some of the acronyms, I still felt overwhelmed.

I tried to memorize everything.

But this was pointless.

Everything will eventually become second nature. It’s normal to feel overwhelmed at first.

The key is to keep asking clarifying questions.

Over time, you’ll understand things better and build muscle memory.

Mistake #5: Complaining excessively about your team systems

No codebase is perfect.

No team is perfect.

Books and blogs often give the impression that:

Everyone should use the latest libraries or frameworks.
All legacy code should be refactored.

When you land on a team with different practices or “messy” code, you might start complaining.

You might even make a list of everything that’s “wrong.” 🤦‍♀️

This is the worst way to start a new job.

Unless you were hired to overhaul the team and its processes (and even then), don’t do this.

Why?

You’re implying that the team is “poor” for missing things.
You’re adding unsolicited work for your colleagues.
You’re alienating people who built the systems without understanding the constraints they faced.

Instead, have a positive attitude:

Look for ways to provide value.
Show, don’t tell: introduce better patterns in your pull requests.
Open technical discussions with the team.

If you’re unhappy with the systems, consider interviewing elsewhere 😌.

Mistake #6: Attempting to refactor code without context

I’ve made this mistake.

I wanted to provide value, so I refactored code without being asked.

It didn’t go as well as I hoped.

Later, when someone joined the team and refactored my code without asking, I got a taste of my own medicine 😅.

Refactoring someone’s code without context can feel like an attack. It’s like someone spoiling your art.

Don’t @ me: I know this is not healthy😅.

Why it’s a problem:

You miss the context for why the code exists.
You overlook more essential tasks.

Instead, only refactor code if:

Someone asks for help.
You can integrate the refactor into meaningful work (e.g., a pull request).

Mistake #7: Setting unrealistic expectations

Don’t work 12–14 hours a day during your first weeks unless you plan to do so long-term.

It might seem like a good idea because:

You want to prove your value.
You feel there’s too much to learn.
You’re on probation.

But this can backfire:

It sets unrealistic expectations for your team. Scaling back later could create friction.
It’s unsustainable and might lead to burnout.

Instead:

Meet the team’s expectations first.
If you want to do more, ensure it’s sustainable and beneficial.

The first weeks are a grace period. People expect you to learn, not to immediately deliver value.

That's a wrap 🎉.

Onboarding is challenging.

But some mistakes can make it far worse:

Sharing strong opinions without context.
Taking actions without context.
Not leveraging your colleagues.

Avoid these mistakes, and you’ll settle into your new team quickly.

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.

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

💡 TIP OF THE WEEK

// Detect dark theme var iframe = document.getElementById('tweet-1877747297402142883-419'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1877747297402142883&theme=dark" }

🍔 FOOD FOR THOUGHT

// Detect dark theme var iframe = document.getElementById('tweet-1876901704563872142-960'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1876901704563872142&theme=dark" }

17 Tips from a Senior React Developer

Ndeye Fatou Diop — Tue, 07 Jan 2025 11:00:00 +0000

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

These are the 17 tips I wish someone had shared with me when I was starting.

Ready? Let's dive in! 💪

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

1. Learn JavaScript before React

When I first started, I jumped from writing functions and basic DOM manipulation to learning React.

As you can guess, it didn't go well 🤯.

This is a common mistake for junior developers: trying to learn React without a solid understanding of JavaScript.

It's a recipe for confusion:

You won't know what is React-specific and what is just JavaScript.
Debugging becomes a nightmare.

What to do instead?

Learn enough JavaScript to get comfortable (check out JavaScript to Know for React).
Then, dive into React.

2. Read the React docs

You don't need money 💰, a coach, or a fancy course to learn React.

Head to the official React website and:

Follow the Quick Start guide.
Read the learning chapters (even if they don't make sense initially, they'll click later).

3. Start building projects early

Watching tutorials won't make you a React developer.

Spending $100, $200, or even $700 on courses won't either.

What will? Building projects.

It's the best way to:

Learn by making mistakes.
Discover gaps in your knowledge.
Pick up new patterns and tips.

Stuck for ideas? Try these resources 👇:

Frontend Mentor: Projects for all skill levels.
Frontend Practice: Recreate real websites.
Frontend Projects: Varied project ideas.
JavaScript Mastery: A YouTube channel with project-based tutorials.

4. Use trusted libraries

Not all packages are safe.

For example, in 2021, a popular NPM package, ua-parser-js, was hacked, spreading malware 📛.

To minimize risks:

Use libraries from trusted authors.
Check for good download volumes and regular updates.

5. Solve problems with Vanilla JS when possible

Previously, you needed libraries like lodash for tasks like cloning, iteration, etc.

But modern JavaScript has improved a lot.

Now, you can achieve a lot with native methods.

So, don’t add a library if you don't have to.

Why?

Every library you add:

Increases your app's dependencies, making it more vulnerable to security issues.
Potentially adds to your bundle size, slowing down load times.
Increases your app’s build/compilation time
Creates maintenance overhead to keep dependencies updated.

Before reaching for a library, check if Vanilla JS can do the job. It often can 😉.

6. Optimize bundle size and lazy load as much as possible

It starts slow.

You add one package here.

Then another there.

And then another.

Before you know it:

Users complain the app takes too long to load.
Developers complain the build process is painfully slow.

Why does this happen?

Packages and heavy components were added without considering their impact on bundle size 🤦‍♀️.

How to fix it?

Lazy-load as much as possible.
Set up checks to track bundle size increases (Pull Request actions work well for this).
Use bundlephobia to check package size before adding it to your project.

7. Colocate related logic

Grouping files by type (e.g., components, utils, i18n) might seem like a good idea, but it's not.

Why?

It's harder to follow a component's logic when files are scattered.
You risk cleaning a component but forgetting related files.

Instead, keep all a component's logic and assets together in one folder.

8. Keep components simple

Avoid "God" components—those that try to do everything.

They're problematic ❌ because:

They're harder to read and understand.
They often lead to version control conflicts (Git, GitLab, etc.).
Modifying them can unintentionally impact the entire app.

What to do instead?

Think about how you'd structure your code if you were working with a teammate.
Keep your components focused on one task to minimize conflicts.

This approach keeps your code clean and helps your team work more efficiently.

9. Solve diverse problems

The more problems you solve with React, the better you get 🚀.

Every challenge you tackle teaches you something valuable:

You uncover new patterns and anti-patterns.
You add more tools to your developer toolbox.
You gain confidence in your skills.

But here's the key: don't just practice—vary your practice.

Explore different kinds of problems, projects, and solutions. That variety will help you grow faster as a React developer.

10. Learn good programming patterns

As a React dev, you should also focus on foundational programming skills:

Data Structures & Algorithms (e.g., sets, maps, recursion).
Principles like those in The Pragmatic Programmer.

11. Read a ton of React code

Building projects isn't the only way to learn—reading code is just as valuable 💪.

It helps you:

Pick up new tips and tricks.
Compare approaches to solving problems.

So, check out:

Open-source projects on GitHub.
Your teammates' code at work.

12. Use TypeScript ASAP

There's a before and an after TypeScript 😅.

Before:

You spend extra time double-checking that you've passed the correct props.
Debugging can take hours, only to realize you passed the wrong value—or worse, undefined.

After:

You focus on structuring your components and defining types.
You catch silly mistakes before they reach production.

TypeScript isn't just a tool—it's a game changer for your React workflow.

13. Avoid early abstractions

I used to be guilty of this a lot 🙈.

Whenever I designed a simple component, I'd try to make it reusable and future-proof.

The problem? I often created the wrong abstraction because there were no immediate needs.

This led to two outcomes:

I'd end up refactoring the code later.
Or worse, I'd have to live with the awkward abstraction, making development harder.

What to do instead?

Write a component that solves the problem at hand.
Extend it only if there's a clear need for reuse, and do so gradually.

For a deeper dive into this topic, check out this great video by Dan Abramov.

14. Use React's built-in state management first

You don't need Redux or Jotai right away.

React's useState, useReducer, and useContext go a long way for simple apps.

15. Don't mindlessly follow online advice

A few years ago, I read online that memoization was "evil."

So, I stopped using it in my React apps.

That was until I crashed an app in production. 😅

The advice made sense for the developer who shared it, but it backfired for me because:

I had different use cases.
I needed to use effects in my app.
I was working with large-scale components.

Main takeaway? Don't mindlessly follow the advice you find online. Instead:

Discuss it with your teammates (if you have them).
Evaluate whether it applies to your specific context.

Note: With React 19 optimization, this advice may finally be accurate 😅.

16. Make time for refactoring

“When developers are too afraid to clean bad code when they see it; then the system will start to rot. As the rot increases, so does the fear -- so the rot accelerates. At some point the code is such a horrible mess than none of the developers can estimate the effect of a particular change. Adding an icon might break other unrelated things.”

Uncle Bob Martin

Every now and then, you'll notice that:

Your React components no longer make sense.
They've grown complex or too large.
There's room for improvement.

When this happens, take 5–30 minutes to refactor.

Small, regular enhancements can make your components easier to manage and prevent headaches.

17. Only use frameworks when necessary

Spoiler: You don't need a framework to use React.

A simple React, Vite, and react-router setup can go a long way.

Use frameworks like Next.js or Remix only when your app requires their features.

That's a wrap 🎉.

Leave a comment 📩 to share your best tip.

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.

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

🐞 SPOT THE BUG

// Detect dark theme var iframe = document.getElementById('tweet-1875150173443362895-61'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1875150173443362895&theme=dark" }

DEV Community: Ndeye Fatou Diop

Devs: Own your growth — or regret it later

What it means to own your growth as a dev

Why it’s essential to own your growth

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

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

Reason #3: Owning your growth gives you more credibility

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

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

How to own your growth

Summary

✨ 17 React Hooks That Power 90% of Modern Components

1. useState

2. useReducer

3. useContext

4. useEffect

5. useRef

6. useMemo / useCallback

7. useLayoutEffect

8. useSWR / useQuery

SWR

TanStack Query

9. useSelector, useDispatch, or other state hooks

10. useNavigate

11. useBoolean

12. useCopyToClipboard

13. usePrevious

14. useDebounce

15. useMediaQuery

16. useResizeObserver

17. useLocalStorage

Summary

✨ 7 Things I Do Regularly as a Senior Frontend Developer

Habit #1: Educate yourself outside of work

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

Habit #3: Get enough rest

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

Habit #5: Review code regularly

Habit #6: Teach back what you learn

Habit #7: Avoid tutorials and copy/pasting

Summary

✨ Don’t do this (unless you want sh*t frontend code)

Mistake #1: Using too many global variables

Mistake #2: Poor variable and function names

Mistake #3: “God” functions

Mistake #4: Functions with many same-type params

Mistake #5: Not cleaning up resources

Mistake #6: Unit-less variables

Mistake #7: Nesting conditionals >3 levels deep

Mistake #8: Hardcoding URLs or config in the code

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

Mistake #10: Giant “utils” files

Mistake #11: Swallowing errors

Mistake #12: One giant file

Mistake #13: No linter

Mistake #14: Messy folder structure

Mistake #15: Commenting obvious code

Mistake #16: No comments for weird logic

Mistake #17: Rewriting what already exists

Summary

Typescript to Know for React

How TypeScript works

Why you should switch to TypeScript ASAP

Benefit #1: Catch bugs before they reach production

Benefit #2: Get autocompletion with libraries

Benefit #3: Make your code more resilient to changes

Without TypeScript, this code can break without you noticing.

With TypeScript, you need to handle changes.

The TypeScript concepts you need for React

✅ Types

Native types

Custom types

❌ Avoid any

🧩 Union & intersection types

🧱 Interfaces

🔁 Generics

🔧 Function types

How to use TypeScript with React

Props

State

❌ Avoid `any`