DEV Community: gary killen

My Experience Switching from VS Code to WebStorm (And Why I Still Use Both)

gary killen — Tue, 30 Jun 2026 20:31:35 +0000

My Experience Switching from VS Code to WebStorm (And Why I Still Use Both)

For years, VS Code was my go-to editor.

Like many developers, I loved its speed, huge extension marketplace, and the ability to customize just about everything. Every new project started the same way: open VS Code, install a few extensions, and start coding.

Then I decided to give WebStorm a serious try.

I expected to spend a week with it before going back to VS Code.

That didn't happen.

Today, WebStorm has become my primary IDE for most of my projects—but I haven't completely left VS Code behind.

Here's why.

First Impressions

The first thing I noticed was that WebStorm felt... complete.

With VS Code, I was used to installing extensions before I felt productive.

Things like:

ESLint
Prettier
Auto Rename Tag
Path IntelliSense
Git integrations
Better Imports

WebStorm already had most of the features I relied on built in.

Instead of spending time configuring my editor, I was spending time writing code.

That was a surprisingly nice change.

Auto Imports Are Incredible

This is probably my favorite feature.

When building React or Next.js applications, I constantly create new components, hooks, and utility functions.

In VS Code, auto imports generally work well, but every now and then I'd find myself fixing an import path or manually searching for a module.

In WebStorm, the IDE almost always knows exactly what I'm trying to import.

It doesn't sound like a huge feature until you've experienced it every day.

When you're importing dozens of files throughout a project, those little moments add up.

Refactoring Feels Smarter

One area where WebStorm really impressed me was refactoring.

Whether I'm:

Renaming files
Moving folders
Extracting functions
Renaming variables across an entire project

Everything feels safe and intentional.

I don't have to wonder whether changing one file is going to break imports somewhere else.

The IDE takes care of that for me.

As my projects have grown larger, that's become more valuable than I expected.

Keyboard Shortcuts Make Me Faster

At first, I thought learning a completely new set of shortcuts would slow me down.

Instead, it had the opposite effect.

Once I got used to WebStorm's navigation shortcuts, I found myself touching the mouse less and less.

Some of my most-used shortcuts include:

Search Everywhere
Find Usages
Go to Definition
Navigate Between Files
Refactor This

After a few weeks, I noticed I was spending less time looking for things and more time actually building features.

Project Navigation Is Excellent

One thing I didn't fully appreciate until I switched was how much time I spent navigating a project.

Modern applications aren't small anymore.

A typical Next.js project might include:

Components
Hooks
API Routes
Server Actions
Utility Functions
Database Models
Configuration Files

WebStorm makes navigating large projects feel effortless.

Instead of wondering where something lives, I can usually find it in seconds.

Where VS Code Still Wins (For Me)

Even though WebStorm has become my main IDE, I still use VS Code.

There are a couple of reasons why.

GraphQL Development

Some of my projects use GraphQL, and I've found that my current workflow with GraphQL mutations is simply smoother in VS Code.

The extensions I'm using fit my workflow well, so I haven't felt a strong reason to move those projects over.

Sometimes the best tool is simply the one that gets out of your way.

CodeRabbit

Another reason I keep VS Code installed is the CodeRabbit extension.

I really like having AI-assisted code reviews directly inside the editor.

It's become a useful part of my workflow when reviewing changes before pushing commits.

It's Not About Picking a Side

One thing I've learned is that developers sometimes treat editors like sports teams.

You're either Team VS Code or Team WebStorm.

I don't really see it that way.

Different tools solve different problems.

For me:

WebStorm is where I build most of my React and Next.js applications.
VS Code is still my choice for GraphQL projects and when I want to use extensions like CodeRabbit.

I don't think using two editors makes me less productive.

If anything, it lets me choose the best environment for the task at hand.

Will I Go Back to VS Code Full-Time?

Probably not.

After spending enough time with WebStorm, it's hard to give up features like:

Intelligent refactoring
Project-wide navigation
Built-in tooling
Reliable auto imports
Excellent code intelligence

Those little productivity improvements add up over the course of a day.

That said, I don't see any reason to uninstall VS Code either.

It's still an excellent editor, and for certain projects it fits my workflow perfectly.

Final Thoughts

Switching editors won't magically make you a better developer.

What it can do is remove small points of friction from your daily workflow.

For me, WebStorm helped me spend less time configuring my tools and more time writing code.

At the same time, VS Code continues to earn a place on my machine because of its flexibility and extension ecosystem.

In the end, the best editor isn't the one everyone else recommends.

It's the one that helps you build software more efficiently.

What About You?

Are you using VS Code, WebStorm, Cursor, Zed, or another editor altogether?

I'd love to hear what keeps you coming back to your IDE of choice. Drop a comment below!

Common Next.js Errors (and How I Solved Them)

gary killen — Tue, 30 Jun 2026 19:21:32 +0000

Common Next.js Errors (and How I Solved Them)

If you've spent any amount of time building with Next.js, you've probably discovered that learning React is only half the battle. The other half is staring at an error message that makes absolutely no sense—until you finally figure it out hours later.

I've been building projects with Next.js over the past several months, and while the framework is incredible, I've hit my fair share of confusing errors. The good news? Every one of them taught me something valuable.

Here are some of the most common Next.js errors I ran into and how I eventually solved them.

1. `ReferenceError: document is not defined`

This was one of the first errors that completely confused me.

ReferenceError: document is not defined

At first, I thought something was wrong with my code. The problem wasn't my code—it was where it was running.

Next.js renders pages on the server before sending them to the browser. Since the server doesn't have access to browser APIs like document or window, trying to use them immediately causes this error.

What caused it?

const width = window.innerWidth;

This code executes during server-side rendering, where window doesn't exist.

How I fixed it

I moved the browser-specific code inside a useEffect() hook.

useEffect(() => {
  console.log(window.innerWidth);
}, []);

Or, if necessary, I checked whether the code was running in the browser before accessing window.

💡 Lesson Learned

If you're using browser APIs, make sure your code only runs on the client.

2. Environment Variables Returning `undefined`

Few things are more frustrating than seeing this:

process.env.MONGODB_URI

…and getting:

undefined

In my case, I had simply forgotten to create or correctly configure my .env.local file.

Other times, I changed an environment variable but forgot to restart the development server.

My Debugging Checklist

Is the variable inside .env.local?
Did I restart npm run dev?
Does the variable need the NEXT_PUBLIC_ prefix?
Did I accidentally misspell the variable name?

💡 Lesson Learned

Environment variables are loaded when the development server starts—not while it's already running.

3. Hydration Errors

Hydration errors can look intimidating.

Hydration failed because the initial UI does not match what was rendered on the server.

This usually means the HTML generated on the server doesn't match what React renders in the browser.

Common causes include:

Using Date.now()
Using Math.random()
Rendering different content on the client
Reading from localStorage during rendering

How I fixed it

Instead of rendering dynamic values immediately, I waited until the component mounted.

const [mounted, setMounted] = useState(false);

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

if (!mounted) return null;

💡 Lesson Learned

The first render should produce the same output on both the server and the client.

4. MongoDB Connection Problems

Database errors always seemed more complicated than they actually were.

Sometimes the error looked like this:

MongoServerError: authentication failed

Other times:

querySrv ECONNREFUSED

Or:

MONGODB_URI is undefined

The fixes were usually simple:

Double-check the connection string.
Verify the username and password.
Confirm your IP address is allowed in MongoDB Atlas.
Make sure your internet connection isn't blocking DNS lookups.
Verify your environment variables.

💡 Lesson Learned

Database errors are often configuration problems rather than coding problems.

5. `Module not found`

Everyone has seen this one.

Module not found

Sometimes I had:

Misspelled an import
Used the wrong file extension
Imported from the wrong folder
Forgotten to install a package

My Debugging Checklist

Does the file actually exist?
Is the import path correct?
Is the package installed?
Did I restart the development server?

💡 Lesson Learned

Most "module not found" errors are caused by simple oversights. Start with the basics before assuming something is seriously broken.

6. React Hook Errors

One of my favorites:

Invalid hook call

Usually this happened because I accidentally placed a hook:

Inside an if statement
Inside a loop
Inside another function

React hooks must always be called in the same order.

❌ Incorrect

if (loggedIn) {
  useEffect(() => {});
}

✅ Correct

useEffect(() => {
  if (loggedIn) {
    // do something
  }
}, [loggedIn]);

💡 Lesson Learned

Always call hooks at the top level of your component.

7. Importing a Server Component into a Client Component

This one took me a while to understand.

With the App Router, Next.js separates components into:

Server Components
Client Components

If I needed state, event handlers, or browser APIs, I had to mark the component with:

'use client';

Otherwise, Next.js assumed it was a Server Component.

💡 Lesson Learned

Not every component should be a Client Component. Add 'use client' only when you actually need client-side features.

8. Images Not Loading

I eventually discovered that Next.js doesn't automatically allow images from every domain.

The fix was adding the domain to next.config.js.

images: {
  remotePatterns: [
    {
      protocol: 'https',
      hostname: 'example.com',
    },
  ],
}

💡 Lesson Learned

If you're using the next/image component with external images, make sure the image domain is configured.

Final Thoughts

When I first started with Next.js, every error felt like I had broken something beyond repair.

Over time, I realized that these errors weren't telling me I was a bad developer—they were teaching me how the framework actually works.

Understanding concepts like server-side rendering, client-side rendering, hydration, and environment variables made debugging much less intimidating.

The biggest improvement in my development skills didn't come from memorizing APIs.

It came from solving bugs.

Every confusing error forced me to understand another piece of how modern web applications work.

And honestly, that's where the real learning happens.

What About You?

What's the most frustrating Next.js error you've encountered?

Share it in the comments—I’d love to hear your debugging stories and how you solved them.

How I Use AI Without Letting It Think for Me

gary killen — Mon, 13 Apr 2026 12:56:51 +0000

How I Use AI Without Letting It Think for Me

AI is one of the most powerful tools I’ve added to my workflow as a developer. It can write code, explain concepts, and even help debug errors in seconds. But I learned pretty quickly that if I rely on it too much, I stop improving.

This post isn’t about avoiding AI—it’s about using it without losing your ability to think.

The Problem: When AI Becomes a Crutch

When I first started using AI, I used it for everything.

If I got stuck on a bug, I asked AI. If I didn’t understand something, I asked AI. If I needed to build something, I asked AI.

And to be fair, it worked… at least on the surface.

But over time, I started noticing a pattern. I was solving problems without really understanding them. I was copying code that I couldn’t confidently explain. When something broke and I didn’t immediately use AI, I felt stuck. My confidence dropped because I wasn’t sure I could figure things out on my own anymore.

That’s when it clicked: AI wasn’t actually making me better—it was making me dependent.

The Shift: AI as a Tool, Not a Brain

The mindset that changed everything for me was simple:

AI should support my thinking, not replace it.

Once I started seeing AI as a tool instead of an answer machine, everything felt different. I stopped treating it like an expert I blindly trust and started treating it more like a junior assistant—helpful, but not in charge.

How I Actually Use AI (Without Losing My Skills)

I Try First, Then Ask for Help

Now, whenever I run into a problem, I don’t immediately jump to AI. I take a moment to read the error, think through what might be going wrong, and try at least one approach on my own.

Even if I fail, that effort matters. It forces me to engage with the problem instead of skipping past it.

When I finally do ask AI for help, I’m not starting from zero. I can compare its suggestions with my own thinking, and that’s where real learning happens.

I Ask for Guidance, Not Answers

I also changed the way I ask questions.

Instead of saying “fix this code,” I’ll ask things like, “What should I check here?” or “Why might this be failing?” Sometimes I’ll even ask for a hint without the full solution.

That small shift keeps me involved in the process. I’m still the one solving the problem—AI is just helping me think it through.

I Don’t Copy What I Don’t Understand

One rule I try to stick to is simple: if I don’t understand it, I don’t use it.

When AI gives me code, I slow down and go through it line by line. I try to rewrite parts of it in my own way and ask myself if I could recreate it from scratch later.

If the answer is no, I know I need to spend more time understanding it before moving on.

I Use AI to Learn, Not Replace Learning

Where AI really shines is in explaining things.

When I’m stuck on a concept, I’ll use it to break things down, simplify documentation, or show the same idea from different angles. Sometimes one explanation just clicks better than another.

But I don’t stop there. I make sure to actually apply what I’ve learned on my own, because that’s what makes it stick.

I Question What AI Tells Me

One of the most important habits I’ve built is not blindly trusting AI.

It’s helpful, but it’s not perfect. So I test its suggestions, question its reasoning, and look for edge cases where things might break.

Instead of treating AI like a source of truth, I treat it like a second opinion. That mindset alone makes a huge difference.

I Let AI Handle the Boring Stuff

There are still places where I lean on AI heavily—and that’s intentional.

I use it for repetitive or low-value tasks like writing boilerplate code, renaming variables, or generating simple functions. Things that don’t really contribute to my growth.

But when it comes to core logic, architecture decisions, or problem-solving, I try to do that work myself. That’s where the real learning happens.

The Rule I Follow

If I had to sum everything up in one sentence, it would be this:

If AI disappeared tomorrow, I should still be able to solve my problems.

That’s the line I try not to cross.

What Changed After This Approach

Since changing how I use AI, I’ve noticed a real difference.

I understand my code more deeply. I can debug issues faster, even without help. I feel more confident building things from scratch. And overall, I’m learning faster—because I’m actually thinking through problems instead of skipping them.

AI didn’t slow me down. It just stopped replacing the part that matters most: my brain.

Final Thoughts

AI isn’t the problem. Over-reliance is.

If you use it intentionally, it can speed up your learning without taking anything away from you.

So the next time you’re stuck, don’t rush to copy the answer.

Pause for a moment. Think it through. Try something.

Then, if you need it, let AI help you—not think for you.

DEV Community: gary killen

My Experience Switching from VS Code to WebStorm (And Why I Still Use Both)

My Experience Switching from VS Code to WebStorm (And Why I Still Use Both)

First Impressions

Auto Imports Are Incredible

Refactoring Feels Smarter

Keyboard Shortcuts Make Me Faster

Project Navigation Is Excellent

Where VS Code Still Wins (For Me)

GraphQL Development

CodeRabbit

It's Not About Picking a Side

Will I Go Back to VS Code Full-Time?

Final Thoughts

What About You?

Common Next.js Errors (and How I Solved Them)

Common Next.js Errors (and How I Solved Them)

1. ReferenceError: document is not defined

What caused it?

How I fixed it

💡 Lesson Learned

2. Environment Variables Returning undefined

My Debugging Checklist

💡 Lesson Learned

3. Hydration Errors

How I fixed it

💡 Lesson Learned

4. MongoDB Connection Problems

💡 Lesson Learned

5. Module not found

My Debugging Checklist

💡 Lesson Learned

6. React Hook Errors

❌ Incorrect

✅ Correct

💡 Lesson Learned

7. Importing a Server Component into a Client Component

💡 Lesson Learned

8. Images Not Loading

💡 Lesson Learned

Final Thoughts

What About You?

How I Use AI Without Letting It Think for Me

How I Use AI Without Letting It Think for Me

The Problem: When AI Becomes a Crutch

The Shift: AI as a Tool, Not a Brain

How I Actually Use AI (Without Losing My Skills)

I Try First, Then Ask for Help

I Ask for Guidance, Not Answers

I Don’t Copy What I Don’t Understand

I Use AI to Learn, Not Replace Learning

I Question What AI Tells Me

I Let AI Handle the Boring Stuff

The Rule I Follow

What Changed After This Approach

Final Thoughts

1. `ReferenceError: document is not defined`

2. Environment Variables Returning `undefined`

5. `Module not found`