DEV Community: Mohit Patel

🚀 15 JavaScript Tricks I Wish Someone Had Taught Me Earlier

Mohit Patel — Wed, 15 Jul 2026 12:30:00 +0000

JavaScript is full of small features that can make your code cleaner, shorter, and easier to maintain.

Here are 15 JavaScript tricks I use almost every week while building web applications with Next.js and React.

Hopefully, you'll find at least a few that make your coding life easier.

1. Remove Duplicate Values

const numbers = [1, 2, 2, 3, 4, 4, 5];

const unique = [...new Set(numbers)];

console.log(unique);
// [1,2,3,4,5]

2. Optional Chaining

Instead of writing:

if (user && user.address && user.address.city) {
  console.log(user.address.city);
}

Use:

console.log(user?.address?.city);

Much cleaner and safer.

3. Nullish Coalescing Operator

const username = null;

console.log(username ?? "Guest");

Output:

Guest

Unlike ||, this only replaces null or undefined.

4. Object Destructuring

Instead of:

const name = user.name;
const age = user.age;

Write:

const { name, age } = user;

5. Swap Variables

Old way:

let a = 10;
let b = 20;

const temp = a;
a = b;
b = temp;

Modern JavaScript:

[a, b] = [b, a];

6. Copy Objects

const newUser = {
  ...user,
};

No loops required.

7. Merge Objects

const user = {
  name: "John",
};

const details = {
  age: 25,
};

const result = {
  ...user,
  ...details,
};

console.log(result);

8. Remove Falsy Values

const arr = [0, "", false, "Hello", undefined, 5, null];

const clean = arr.filter(Boolean);

console.log(clean);

Output:

["Hello",5]

9. Flatten Arrays

const arr = [[1], [2], [3]];

console.log(arr.flat());

Output:

[1,2,3]

10. Dynamic Property Names

const key = "email";

const user = {
  [key]: "john@example.com",
};

console.log(user);

11. Convert Object into Array

const user = {
  name: "John",
  age: 25,
};

console.log(Object.entries(user));

Output:

[
  ["name", "John"],
  ["age", 25],
];

12. Promise.all()

Instead of waiting one request after another:

await getUsers();
await getPosts();
await getComments();

Run everything together:

await Promise.all([
  getUsers(),
  getPosts(),
  getComments(),
]);

Much faster.

13. Get the Last Element

Instead of:

arr[arr.length - 1];

Use:

arr.at(-1);

Cleaner and easier to read.

14. Generate a UUID

const id = crypto.randomUUID();

console.log(id);

Example:

4c5d7d67-2a58-4b76-a52d-5b43c672b16f

Perfect for temporary IDs.

15. Use `const` by Default

Instead of writing:

var total = 100;

Use:

const total = 100;

Only use let when the value needs to change.

Avoid var in modern JavaScript.

🎯 Bonus Tip

Use Prettier and ESLint in every JavaScript project.

Good formatting and linting save hours of debugging and make your code much easier to maintain.

Final Thoughts

JavaScript continues to evolve, and even small language features can significantly improve the quality of your code.

These tricks may seem simple individually, but together they help write cleaner, more maintainable, and less error-prone applications.

If you have a favorite JavaScript trick that isn't on this list, share it in the comments. I'd love to learn something new!

Happy Coding! 🚀

Tags:

#javascript #webdev #programming #beginners

🚀 I Built 13 Free Online Tools... Then Realized Nobody Would Find Them

Mohit Patel — Tue, 14 Jul 2026 12:49:00 +0000

When I finished building my first collection of free online tools, I thought the hard part was over.

I was wrong.

I assumed:

"If the tools are useful, people will naturally find them."

Reality?

For days, my traffic was almost zero.

What I Built

I created a collection of free tools including:

JSON Formatter
QR Code Generator
Image Compressor
Color Code Converter
Text Utilities
File Conversion Tools
And several more

The focus was simple:

✅ No login
✅ No hidden paywall
✅ Clean UI
✅ Fast loading
✅ Works on mobile

I was proud of what I'd built.

But almost nobody was using it.

The Problem Wasn't the Product

The biggest mistake wasn't the code.

It was thinking that building something useful is enough.

The internet has millions of websites.

Even if your tool is better, people won't magically discover it.

That realization completely changed how I approach side projects.

What I Started Learning

Instead of adding more features, I focused on things I had ignored:

SEO fundamentals
Page speed optimization
Better page titles
Internal linking
Writing blog posts
Sharing on developer communities
Understanding what users actually search for

Ironically, I now spend almost as much time improving discoverability as I do writing code.

Small Improvements That Made a Difference

A few things that helped:

Faster Pages

Nobody likes waiting.

Reducing unnecessary JavaScript and optimizing assets noticeably improved the experience.

Better SEO

Instead of naming a page:

"Formatter"

I changed it to:

"Free JSON Formatter & Validator Online"

Simple changes like this made the pages much clearer—for both users and search engines.

Content Around the Tools

Rather than publishing only tools, I started writing articles explaining:

when to use them
common mistakes
practical examples

This gave people a reason to visit beyond a single conversion.

What I'm Still Learning

I'm far from an expert.

Every week I'm experimenting with:

improving performance
building new tools
writing better content
learning SEO
understanding user behavior

It's been much more challenging—and much more rewarding—than I expected.

My Advice to Anyone Building a Side Project

Don't wait until your product is "perfect."

Ship it.

Get feedback.

Improve it.

And remember:

Building is only half the job. Helping people discover your work is the other half.

If you're building a side project too, I'd love to hear:

What's been harder for you—building the product or getting users?

I'm always looking for ideas to improve my collection of free tools, so feedback is welcome.

I Stopped Chasing Perfect Code. My Projects Finally Started Shipping.

Mohit Patel — Mon, 06 Jul 2026 05:46:23 +0000

For years, I thought writing great software meant writing perfect code.

Every function had to be clean.

Every component had to be reusable.

Every folder structure had to be future-proof.

Every variable needed the perfect name.

It felt productive.

But I wasn't actually shipping anything.

The Perfection Trap

I would spend hours:

renaming variables
reorganizing folders
changing architectures
rewriting working code
switching frameworks

The project looked cleaner.

But it wasn't getting closer to users.

Then Something Changed

One day I asked myself a simple question.

"Would a user even notice this change?"

Most of the time...

The answer was no.

Users didn't care whether I used the latest framework.

They cared that the website loaded quickly.

They cared that the button worked.

They cared that their problem was solved.

Shipping Taught Me More Than Tutorials

The biggest lessons didn't come from another YouTube video.

They came from real users.

Real bugs.

Real feedback.

Real mistakes.

You don't learn those by endlessly refactoring.

What I Do Now

I still care about code quality.

But I care more about solving problems.

My workflow is simple:

✅ Make it work.

✅ Make it understandable.

✅ Ship it.

Only then...

Improve it.

Perfection Can Wait

I've learned that an imperfect project with real users is far more valuable than a perfect project sitting on my laptop.

The internet rewards people who finish.

Not people who endlessly prepare.

Final Thought

Your users won't remember your folder structure.

They'll remember whether your product helped them.

Ship first.

Improve later.

That's a lesson I wish I had learned much earlier.

Have you ever delayed launching a project because you wanted it to be "perfect"?

The Best Feature I Ever Built Was the One I Almost Deleted

Mohit Patel — Sat, 04 Jul 2026 08:27:52 +0000

When I first built it, I thought it was brilliant.

The UI looked polished.

The animations were smooth.

The code was clean.

I was proud of it.

Then I asked a few people to use it.

Almost nobody noticed the feature.

Some didn't even realize it existed.

At first, I thought the users weren't paying attention.

Then I realized...

The problem wasn't the users.

The problem was me.

Developers Love Features

We enjoy building.

A new button.

A new animation.

A new dashboard.

A new setting.

Every new feature feels like progress.

But users don't care how much work something took.

They care whether it solves their problem.

I Almost Kept It

Part of me wanted to keep the feature.

I'd spent hours building it.

Deleting it felt like admitting failure.

Then I remembered something.

Good products aren't defined by what they include.

They're defined by what they leave out.

So I removed it.

Something Unexpected Happened

The interface became simpler.

People completed tasks faster.

Support questions decreased.

Nobody asked where the feature went.

Nobody missed it.

That's when I learned a lesson I wish I'd known earlier.

Sometimes removing code creates more value than writing it.

Simplicity Wins

As developers, it's easy to believe that more features make a better product.

In reality...

Every new feature adds:

More code
More bugs
More maintenance
More confusion

The best products aren't always the ones with the most features.

They're the ones that make users think the least.

My New Rule

Before building something new, I ask myself:

"If I removed this tomorrow, would anyone actually miss it?"

If the answer is no...

Maybe it shouldn't exist.

Final Thought

Writing code is a skill.

Knowing what not to build is another.

And in my experience...

The second one is much harder.

What's one feature you built that users didn't care about?

Nobody Gets Paid for Knowing Syntax. They Get Paid for Solving Problems.

Mohit Patel — Tue, 30 Jun 2026 12:44:00 +0000

When I first started programming, I thought the best developers had one superpower.

They remembered everything.

Every function.

Every method.

Every API.

Every piece of syntax.

So I spent hours trying to memorize things.

JavaScript methods.

SQL queries.

Regex.

CSS properties.

I thought that would make me valuable.

I was wrong.

The Day Everything Changed

One day I watched a senior developer solve a difficult production issue.

They opened Google.

They opened the documentation.

They searched Stack Overflow.

They experimented.

They tested.

They failed.

Then they fixed it.

That's when I realized something.

They weren't valuable because they remembered everything.

They were valuable because they knew how to solve problems.

Google Doesn't Make You Less of a Developer

For a long time I felt guilty every time I searched for something.

"Real developers shouldn't need Google."

That's what I believed.

Then I realized...

Even experienced engineers search for documentation every day.

Not because they're bad.

Because technology changes constantly.

Nobody remembers every detail.

Syntax Is Temporary

Think about the last five years.

How many frameworks have changed?

How many libraries disappeared?

How many APIs were deprecated?

Technology moves fast.

Problem-solving doesn't.

If you know how to think...

You can learn any syntax.

Companies Don't Hire Human Compilers

Nobody pays you because you know where to put a semicolon.

Nobody promotes you because you memorized every React hook.

Companies pay developers who can:

understand problems
communicate clearly
debug effectively
make good decisions
work with people
deliver reliable software

Those skills don't disappear when a framework becomes outdated.

The Questions That Matter

Instead of asking:

"Do I know this syntax?"

I started asking:

Can I understand the problem?
Can I break it into smaller pieces?
Can I explain my thinking?
Can I find reliable information quickly?
Can I learn something new when I need it?

Those questions changed the way I learned.

My Biggest Career Lesson

Today, I don't try to memorize everything.

I try to understand fundamentals.

Because syntax is easy to search.

Judgment isn't.

Communication isn't.

Experience isn't.

Final Thought

The best developers I've met don't impress me because they know every answer.

They impress me because they know how to find the right one.

Technology will continue to change.

Programming languages will evolve.

AI will generate more code than ever before.

But one skill will always matter.

The ability to solve real problems.

What do you think is the most underrated skill a developer can have?

The Biggest Mistake I Made Was Waiting to Feel Ready

Mohit Patel — Sat, 27 Jun 2026 14:50:00 +0000

For years, I told myself the same lies.

"I'll start when I know more."
"I'll launch when it's perfect."
"I'll apply when I'm confident."
"I'll share my work when it's good enough."

That day never came.

Perfection Is Just Fear in Disguise

I spent weeks polishing projects that nobody had seen.

I rewrote code that already worked.

I redesigned pages that users never complained about.

I wasn't improving the product.

I was avoiding judgment.

The Internet Rewards Action

The developers who inspired me weren't necessarily the smartest.

They were the ones who kept shipping.

They launched unfinished ideas.

They collected feedback.

They improved in public.

While I was waiting for perfection, they were gaining experience.

My First Projects Were Embarrassing

Looking back, I cringe at some of the code I wrote.

The UI was rough.

The architecture was messy.

The documentation barely existed.

But those imperfect projects taught me more than any tutorial ever could.

Confidence Comes After Action

I used to think confidence came first.

Now I know it's the opposite.

You build confidence by doing the uncomfortable thing repeatedly.

Not by thinking about it.

The Lesson

Don't wait until you're ready.

Start before you feel ready.

Launch before it's perfect.

Ask questions before you know all the answers.

Because the biggest risk isn't failing.

It's spending years preparing for something you never begin.

Final Thought

The version of you that's capable of building amazing things doesn't appear overnight.

It shows up every time you decide to take one more step.

What's something you've been putting off because you're waiting for the "perfect" moment?

I Thought Senior Developers Knew Everything. I Was Completely Wrong.

Mohit Patel — Fri, 26 Jun 2026 14:39:36 +0000

When I started programming, I believed senior developers had all the answers.

I imagined they could solve any bug in minutes.

They never Googled anything.

They never made mistakes.

Then I started working with experienced engineers.

And I realized something surprising.

They weren't faster because they knew everything.

They were faster because they knew how to figure things out.

They Google. A Lot.

One of the best developers I've met searched for documentation almost every day.

Not because they were inexperienced.

Because they didn't trust memory over facts.

They Ask Better Questions

Instead of saying:

"This code doesn't work."

They ask:

What changed?
Can I reproduce the issue?
What's the smallest failing case?
What assumptions am I making?

The quality of the question often determines the quality of the answer.

They Read Error Messages

I used to skip error messages and jump straight to Stack Overflow.

Now I read them carefully.

Many bugs practically tell you what's wrong if you slow down.

They Prefer Simple Solutions

Early in my career, I wanted elegant code.

Now I appreciate boring code.

Simple code is easier to debug, easier to explain, and easier to maintain.

They Aren't Afraid to Say "I Don't Know"

This was the biggest surprise.

The strongest developers I've worked with are comfortable admitting uncertainty.

Instead of pretending, they investigate.

That's confidence.

My Biggest Lesson

Being a senior developer isn't about memorizing APIs or knowing every framework.

It's about staying calm when things break.

It's about learning continuously.

And it's about solving problems without letting your ego get in the way.

Final Thought

The day I stopped trying to know everything…

was the day I started learning much faster.

What's one lesson you learned from an experienced developer that completely changed how you write code?

I Spent 30 Days Fixing Bad Coding Habits. These 7 Changes Made the Biggest Difference.

Mohit Patel — Thu, 25 Jun 2026 13:31:00 +0000

I used to think becoming a better developer meant learning more frameworks.

I was wrong.

The biggest improvements came from fixing small habits I repeated every day.

Here are the 7 changes that made the biggest difference.

I stopped copy-pasting code without understanding it.

At first, it felt slower.

But after a few weeks, debugging became much easier.

I started reading my own code the next day.

If I couldn't understand it after one night, it probably wasn't clear enough.

I wrote variable names for humans, not for myself.

Future me was grateful.

I stopped optimizing too early.

Most performance problems never existed in the first place.

I removed unnecessary dependencies.

Less code meant fewer bugs and easier updates.

I learned to take breaks when stuck.

Some of my best solutions appeared after stepping away from the keyboard.

I stopped comparing myself to developers on social media.

People post highlights, not struggles.

The biggest lesson?

Great developers aren't the ones who know every framework.

They're the ones who build consistently, communicate clearly, and keep improving one habit at a time.

Technology changes every year.

Good habits compound for a lifetime.

What's one coding habit you wish you had fixed earlier?

I Stopped Learning New Frameworks for 6 Months. Here's What Happened.

Mohit Patel — Wed, 24 Jun 2026 13:30:00 +0000

For years, I had the same routine.

A new JavaScript framework launched?

I watched tutorials.

A new CSS library became popular?

I bookmarked it.

A new AI coding tool appeared?

I wanted to master it.

But one day I realized something uncomfortable.

I was spending more time learning new tools than actually building anything.

So I made a decision:

For six months, I wouldn't chase the latest framework.

I'd only use what I already knew.

Week 1: Fear of Missing Out

I kept seeing posts about new libraries and shiny features.

It felt like I was falling behind.

Month 2: I Became Faster

Without constantly switching stacks, I started solving problems instead of researching them.

My projects shipped faster.

My debugging improved.

I spent less time reading documentation.

Month 4: Depth Beat Novelty

I discovered features in tools I'd been using for years but never explored.

I wrote cleaner code.

I understood my stack much better.

Month 6: A Big Realization

The developers I admire most don't know every framework.

They know how to solve problems.

Technology changes every year.

Problem-solving lasts much longer.

My New Rule

Before learning something new, I ask myself:

“Do I actually need this, or am I just afraid of missing out?”

Sometimes the answer is yes.

Most of the time, it's no.

Final Thought

The tech industry moves fast.

But your career isn't a race to collect frameworks.

It's a journey to build useful things and understand them deeply.

I'd rather master one tool than barely understand ten.

What’s one technology you spent time learning but never ended up using?

The Most Dangerous Habit I See in Junior Developers

Mohit Patel — Tue, 23 Jun 2026 13:40:00 +0000

It's not using the wrong framework.

It's not choosing the wrong database.

It's not writing messy code.

The most dangerous habit is this:

Trying to look smart instead of trying to solve the problem.

I Used to Do It Too

When I started programming, I loved writing clever code.

One-liners that nobody else could read.

Nested logic that looked impressive.

Functions that felt "advanced."

I thought complexity was a sign of skill.

It wasn't.

The Best Engineers I Know Do the Opposite

They write code that's boring.

Predictable.

Readable.

Simple.

The kind of code a teammate can understand in 30 seconds.

And that's exactly why it's great.

Complexity Is Expensive

Every extra abstraction has a cost.

Every unnecessary dependency has a cost.

Every clever trick has a future maintenance cost.

Someone has to debug it.

Sometimes that someone is you.

Six months later.

Real Growth

Real growth isn't learning five new frameworks every year.

It's learning when not to add another layer of complexity.

It's knowing when a simple if statement is better than a fancy design pattern.

It's choosing clarity over ego.

My Rule Today

Before I write code, I ask:

"If someone else opens this file tomorrow, will they understand it immediately?"

If the answer is no, I simplify it.

Final Thought

The goal isn't to impress other developers.

The goal is to build software that works, lasts, and can be maintained.

Simple code rarely goes viral on social media.

But it survives in production.

And that's what really matters.

What's one programming habit you had to unlearn?

The Internet Is Full of AI Content. Can You Still Tell What's Human?

Mohit Patel — Sat, 20 Jun 2026 13:30:00 +0000

A few years ago, I could usually tell when a person wrote an article.

Today, I'm not so sure.

The grammar is perfect.

The formatting is flawless.

The structure is polished.

And yet… something often feels missing.

Personality.

The internet is filling up with content that's technically correct but emotionally empty.

That's not a criticism of AI. I use AI tools almost every day.

The problem is when we stop adding our own experiences.

People don't remember perfect sentences.

They remember stories.

They remember mistakes.

They remember opinions.

As creators and developers, I think our biggest advantage isn't writing faster.

It's sharing things only we have experienced.

AI can generate code.

AI can summarize articles.

AI can rewrite documentation.

But it can't genuinely describe the frustration of launching a project that nobody visits or the excitement of fixing a bug after hours of debugging.

Maybe the future isn't about competing with AI.

Maybe it's about being more human.

What do you think?

Can you still tell when something was written by a real person?

The Best Code I Wrote This Year Was the Code I Deleted

Mohit Patel — Thu, 18 Jun 2026 13:30:00 +0000

For years, I believed more code meant more progress.

More features.
More abstractions.
More files.
More complexity.

Then one day, I deleted nearly 800 lines of code.

Nothing broke.

In fact, the application became faster, easier to maintain, and much simpler to understand.

We Celebrate Writing Code

Developers love shipping features.

We enjoy solving problems with clever solutions.

But we rarely celebrate removing unnecessary code.

And maybe we should.

Every Line Has a Cost

Every line you write has to be:

read
tested
debugged
maintained
explained to teammates
updated in the future

That cost compounds over time.

Simplicity Is a Feature

I've started asking myself one question before adding anything:

"Can I solve this without introducing more code?"

Sometimes the answer is yes.

Sometimes the best optimization isn't a faster algorithm.

It's deleting the feature nobody uses.

The Trap of Overengineering

Many side projects start simple.

Then we add:

another library
another state manager
another abstraction
another configuration layer

Eventually the project becomes harder to understand than the problem it solves.

My New Rule

I no longer measure productivity by how much code I write.

I measure it by how much unnecessary complexity I remove.

Because clean code isn't just readable.

Sometimes it's code that no longer exists.

Final Thought

The best code I wrote this year wasn't something I added.

It was something I had the confidence to delete.

Have you ever removed a large chunk of code and realized the project was actually better without it?

DEV Community: Mohit Patel

🚀 15 JavaScript Tricks I Wish Someone Had Taught Me Earlier

1. Remove Duplicate Values

2. Optional Chaining

3. Nullish Coalescing Operator

4. Object Destructuring

5. Swap Variables

6. Copy Objects

7. Merge Objects

8. Remove Falsy Values

9. Flatten Arrays

10. Dynamic Property Names

11. Convert Object into Array

12. Promise.all()

13. Get the Last Element

14. Generate a UUID

15. Use const by Default

🎯 Bonus Tip

Final Thoughts

🚀 I Built 13 Free Online Tools... Then Realized Nobody Would Find Them

I Stopped Chasing Perfect Code. My Projects Finally Started Shipping.

The Perfection Trap

Then Something Changed

Shipping Taught Me More Than Tutorials

What I Do Now

Perfection Can Wait

Final Thought

The Best Feature I Ever Built Was the One I Almost Deleted

Nobody Gets Paid for Knowing Syntax. They Get Paid for Solving Problems.

The Biggest Mistake I Made Was Waiting to Feel Ready

I Thought Senior Developers Knew Everything. I Was Completely Wrong.

I Spent 30 Days Fixing Bad Coding Habits. These 7 Changes Made the Biggest Difference.

I Stopped Learning New Frameworks for 6 Months. Here's What Happened.

The Most Dangerous Habit I See in Junior Developers

I Used to Do It Too

The Best Engineers I Know Do the Opposite

Complexity Is Expensive

Real Growth

My Rule Today

Final Thought

The Internet Is Full of AI Content. Can You Still Tell What's Human?

The Best Code I Wrote This Year Was the Code I Deleted

We Celebrate Writing Code

Every Line Has a Cost

Simplicity Is a Feature

The Trap of Overengineering

My New Rule

Final Thought

15. Use `const` by Default