I Built a Job Tracker and These Bugs Nearly Finished Me — Advice Welcome 🐛

Solomon Isu — Sun, 03 May 2026 23:18:53 +0000

Hey Dev.to community 👋

I'm a growing developer and I just finished building my first
real full-stack project — a Job Application Tracker built with
Next.js, TypeScript, MongoDB and DnD Kit.

I'm writing this partly to document what I faced, partly to
laugh about it, and mostly to ask for advice from more experienced
developers on how to handle these situations better next time.

The Project

A Kanban-style job application tracker where you can:

Add, edit and delete job applications
Drag and drop between columns
Move jobs via dropdown menu
All updates reflect immediately without page refresh

Tech stack:

Next.js 16 (App Router)
TypeScript
MongoDB + Mongoose
Better Auth
DnD Kit
shadcn/ui + Tailwind CSS

The Bugs — A Sarcastic Love Letter 💌

1. The useEffect setState Anti-Pattern

I was calling setBoard and setColumns directly inside a useEffect.
React responded with a wall of red text about cascading re-renders.
Delightful.

The fix was simple — useState already handles initial values.
The useEffect was doing the same job twice.

👉 Advice needed: Is there a pattern you follow to know when
useEffect is actually necessary vs unnecessary?

2. TypeScript's Obsession With Types

initialBoard had 3 possible values (Board | null | undefined).
setBoard only accepted 2 (Board | null). TypeScript lost its mind.
I lost my mind. Eventually we came to an agreement.

The fix was using initialBoard?.columns in the if check which
gave TypeScript enough confidence to calm down.

👉 Advice needed: How do you handle these type narrowing situations
more elegantly in large codebases?

3. The UI That Refused To Update

Server actions were saving to the database perfectly. The UI
sat there staring at me like nothing happened.

Turns out telling the database something changed and telling
the UI something changed are two completely different conversations.
I had to build a full callback chain from useBoard all the way
down to each component.

👉 Advice needed: Is this callback chain pattern the right
approach or is there a cleaner way? Should I be using something
like Zustand or React Query instead?

4. revalidatePath — The Silent Callback Killer

Just when the callback chain was working — revalidatePath was
quietly running in the background wiping all callbacks out on
every action. onJobAdded is not a function it said.

Removing revalidatePath fixed it — but now I'm handling all
UI updates manually.

👉 Advice needed: What's the best practice here? revalidatePath
vs manual state updates? Or a combination of both?

5. "use cache" — The Freshness Illusion

Next.js was serving beautifully cached stale data on every refresh.
Move a job to a new column. Refresh. Gone. Back where it started.
Like it never happened.

Removing "use cache" fixed it immediately.

👉 Advice needed: How do you properly handle caching in Next.js
App Router without breaking real-time updates?

6. The DnD Hydration Mismatch

The crown jewel. DnD Kit generating DndDescribedBy-0 on the server
and DndDescribedBy-1 on the client. A difference of exactly ONE
number causing a wall of red hydration warnings on every single
page load.

Although purely cosmetic — it's a bloody pain in the ass.

The fix was the isMounted pattern — only rendering DndContext
on the client:

const [isMounted, setIsMounted] = useState(false);

useEffect(() => {
setIsMounted(true);
}, []);

if (!isMounted) return null;

👉 Advice needed: Is there a better way to handle DnD Kit
hydration issues in Next.js? Is this a known issue with a
planned fix?

What I Learned

Building a real project teaches you things no tutorial ever will.

React is opinionated. Respect it.
TypeScript is unforgiving. Respect it more.
Next.js caching will humble you.
Purely cosmetic bugs are still a bloody pain in the ass.
Debugging at 2am builds character apparently.

My Ask

I'm a growing developer and I'd love honest feedback from the
community:

Are there better patterns for any of these solutions?
What tools or libraries would have made this easier?
What would YOU have done differently?

All advice welcome — roast me if you must. I can take it. 😂

GitHub: https://github.com/solodevx/venarium-job-application-tracker

Thanks for reading! 🚀

When AI Misses the Whole Picture: A Tailwind Debugging Story

Solomon Isu — Sun, 01 Feb 2026 01:08:25 +0000

Programming is full of surprises, but some challenges are more frustrating than others. Recently, I spent almost two days stuck on a single problem—all because the advice I got didn’t consider the full picture. I want to share this experience to help other developers avoid the same trap, and to highlight how AI, even when helpful, can sometimes mislead you if it misses context.

The npx Tailwind Install Issue

It all started with a simple command:

npx tailwindcss init -p

This command is meant to initialize a Tailwind project with a tailwind.config.js file and a postcss.config.js file. Easy, right?

Not quite. If you’re using Tailwind 4, this command doesn’t behave like it used to in Tailwind 3. Tailwind 4 does not fully support the old CLI workflow, which means the initialization might fail, or certain features may not work as expected.

My first instinct was to troubleshoot endlessly—updating dependencies, changing syntax, and even rewriting parts of my project. Nothing worked.

The simple solution? Revert to Tailwind 3 if you really need the command-line binary workflow. Tailwind 3 supports npx tailwindcss init -p perfectly, and everything works out of the box.

The Linter That Said “No”

Next came the @theme directive. Tailwind allows you to do something like:

@tailwind base;
@tailwind components;
@tailwind utilities;

@layer components {
  .btn {
    @apply px-4 py-2 bg-blue-500 text-white rounded;
  }
}

Everything is valid and works perfectly. But my linter kept throwing errors, flagging @theme as “unknown” or “invalid.”

Here’s the key takeaway: this was not a Tailwind error. It was purely a linting issue. Tools like ESLint or stylelint sometimes don’t recognize Tailwind’s newer directives or custom syntax.
The fix? Either configure the linter to understand Tailwind, or ignore the lint errors temporarily. The code will still run correctly.

The Real Lesson

The frustrating part was not the error itself—it was how easy the solution actually was:
Read the official documentation. Tailwind’s docs clearly explain the differences between versions, CLI usage, and directives like @theme.

There are also accounts of other programmers and developers who encountered - my advice read their experiences, view the codes, and deduce the breaking point in your codes.
Don’t blindly follow AI advice. AI can misinterpret your setup, skip steps, or focus on unrelated “fixes” that waste hours.
Understand what’s actually an error. Not every red underline is a bug. Sometimes it’s just a linter yelling at you.

After all the spinning in circles, I realized the solution was simple: stick with the Tailwind version that fits your workflow, and know when a lint error isn’t really a problem.

Why I’m Writing This

AI can help us code faster, suggest patterns, and explain concepts—but it doesn’t always see the full context of your project. If you rely on it blindly, you can waste days stuck on problems that have simple solutions.

Sharing my experience isn’t just about Tailwind, it’s about learning to debug effectively, understanding your tools, and knowing when to trust the documentation over automated advice.

If this story saves even one developer a couple of days of frustration, it’s worth it.

DEV Community: Solomon Isu