DEV Community: Programming with Shahan

10 hard truths EVERY DEV must learn in 2025

Programming with Shahan — Wed, 09 Apr 2025 17:26:43 +0000

I've been in the coding game for 5 years.

Written messy code.

Struggled with debugging nightmares.

Made dumb mistakes.

Learned the hard way.

Here are the cold, hard lessons I had to learn the hard way (every developer must learn)...

1. Looks help but they’re not everything.

I remember when I first started using AI code assistants. I thought once I had them, coding would be effortless.

They provided suggestions, completed lines... but my projects still had issues. Because I still lacked the understanding of clean code principles. AI tools got me started, but my lack of foundational knowledge closed doors just as fast.

What I learned is this: AI tools don’t just respond to what you input; they amplify your existing coding habits. A developer who codes with clarity, who structures functions with purpose, who doesn’t rely solely on AI -- that developer will outperform someone who blindly follows AI suggestions every time.

2. If you’re always chasing, you’re not in control.

This one stung. I used to think effort was everything. If I just kept tweaking and adding features, the code would improve. So, I’d refactor endlessly, integrate every new library, follow every trend... and I ended up with bloated, unmanageable codebases.

Because when you’re doing 90% of the work without a clear direction, you’re not developing; you’re floundering. Real progress is intentional. If a feature truly adds value, it will integrate seamlessly. Stop chasing every new tool or framework that barely fits your project. Start valuing simplicity and purpose.

3. Your purpose is more attractive than your tools.

I had phases where I’d focus all my energy on mastering the latest coding tools. Everything revolved around having the newest gadgets in my developer toolkit. I’d spend hours customizing my IDE, setting up complex workflows... and I got nowhere.

But when I locked in on my goals—building meaningful projects, solving real problems—when I was too busy creating to constantly tweak my setup, suddenly my work stood out.

Clients and peers would say, “You’re different,” “You’re focused,” “You’ve got something going.” That’s when I realized: developers who chase purpose attract recognition without even trying. Because that energy is rare, and people feel it.

4. I’ve learned to stop coding so much.

Early on, I thought I had to prove myself. I’d over-engineer. Add unnecessary complexity. Implement features no one asked for. It came off as overcompensation and it killed project momentum.

I started studying minimalism in code, the beauty of simplicity. I realized users notice everything.

The way an application flows. The intuitiveness of the interface. The speed of execution. A developer who can deliver powerful functionality with clean, simple code is a developer who gets attention. Simplicity is power. Let your code speak for itself.

5. Your past code matters.

I worked on projects where I ignored my previous mistakes—spaghetti code, lack of documentation, poor structure — and I told myself, “I’ll do better next time.” I wanted to move forward without addressing the past. I couldn’t. I became trapped in a cycle of repeating errors.

A developer’s past work is a preview of their future. It doesn’t mean you have to be perfect, but you do need accountability. You need to learn and grow. If all your past projects were chaotic, ask why you approached them that way. If you consistently avoided testing and documentation, ask what that means for your development process.

Don’t ignore the signs just because you’re eager to move on.

6. Not every tool is worth your time.

When I was younger, I treated every new framework or library as a must-learn. If it was popular, that was enough. I’d ignore its relevance to my work, its learning curve, its community support—just to have it on my resume. I paid for it every time.

Now? I care more about effectiveness than trendiness.

Does this tool solve a problem I have? Does it integrate well with my existing stack? Does it have long-term viability? If it’s just trendy but brings nothing substantial, I pass. My time is valuable. My focus is sacred. And not every tool deserves attention.

7. The less you rely, the better things go.

This doesn’t mean rejecting help or tools. It means independence. I used to depend heavily on AI code assistants. Let them dictate my coding style. Follow their suggestions blindly. But when I stopped relying so much—when I focused on understanding, improving, and staying grounded—things shifted.

My code became cleaner. My problem-solving skills sharpened. And ironically, that’s what made me a better developer. The one who can code without assistance holds the power. Not out of arrogance but out of competence.

Clean code isn’t optional... it’s your edge. AI can’t fix chaos. If your code is unreadable, your future’s unstable. I learned the hard way. You don’t have to. Grab my book "Clean Code Zero to One" on Gumroad and level up forever:

📘: https://codewithshahan.gumroad.com/l/cleancode-zero-to-one

8. Being a “yes developer” doesn’t work.

I used to think agreeing to every feature request was the way to please clients. I’d say yes to everything, avoid pushing back, always accommodate. It made me overworked.

Even worse—it made me look unprofessional.

Clients don’t want a pushover. They want a professional with a backbone. Someone who sets boundaries. Someone who’s accommodating but not afraid to say no. Someone who makes informed decisions.

Be a good developer but don’t be a submissive one. There’s a difference.

9. Comments are cool, but clarity is better.

“// This function calculates the sum.” Blah, blah, blah. Every developer writes that. But the one who names the function calculateSum()... who structures code so its purpose is self-evident... who doesn’t rely on excessive comments to explain convoluted logic—that’s the developer whose code is respected.

Clarity isn’t verbose. It’s in the structure, the naming, the organization. I stopped trying to explain my code with comments and started writing code that needed no explanation. That’s when my work became exemplary.

10. Your project should add to your life, not be your life.

I’ve taken on projects where I lost myself. I stopped learning new skills. Stopped networking. Stopped pursuing personal growth. And every time, it ended with regret.

That's all for today. Hope you learned something new. Feel free to follow me and subscribe to my weekly horsecoder newsletter for the latest updates.

🏖️ This article is sponsored by FN Tech Solution, where you can find people to do marketing for you: create apps/websites/designs, grow your business, and more.

🌱🗃️ More Learning Resources:
📘 My Book: Clean Code Zero to One
📹 YouTube: Programming with Shahan
🩻 𝕏: shahancd
🌐 Website: codewithshahan.com

How to land your first frontend job (11 Rules!)

Programming with Shahan — Sat, 15 Mar 2025 23:55:40 +0000

You wanna land your first front-end job in 2025? You think slapping together a few React components and calling yourself a "developer" is enough? News flash: it's not.

Most of you are out here writing spaghetti code, hoping some company will bless you with a job. Wrong. Employers want weapons—clean, scalable, maintainable code machines. You follow these 11 rules, and you’ll have hiring managers fighting over you. Ignore them? Enjoy your job at McJavaScript's.

Let’s get into it

📽️ 1. Not building projects

If you really want to know how far you have come, create real-world projects. A simple quiz app can be entertaining to start with.

Make sure to resist the temptation to copy code. Do it from scratch.

// A simple quiz app with array-based questions
const questions = [
  { prompt: "What does HTML stand for?", answer: "HyperText Markup Language" },
  { prompt: "What is the output of 2+2 in JS?", answer: "4" },
];

function startQuiz() {
  let score = 0;
  questions.forEach((q) => {
    const userAnswer = prompt(q.prompt);
    if (userAnswer && userAnswer.toLowerCase() === q.answer.toLowerCase()) {
      score++;
    }
  });
  alert(`Your score is: ${score}/${questions.length}`);
}

startQuiz();

🍽️ 2. Choose Your Learning Resources Wisely

You want to read every tutorial, watch every video, jump on every trendy platform. That’s a crime in software development.

Pick one or two solid resources/courses. Stick to them until you grasp critical concepts 100%.

You are not gonna make it unless you grasp these two principles of learning coding online:

🫗 Jumping around too much = zero progress.
🌴 A single consistent source builds a strong mental framework.

🪛 3. Start with the Basics

Most devs want to build an entire e-commerce platform on Day One.

Don’t. It’s like trying to fight a heavyweight champion before you’ve thrown your first punch.

Build hundreds of small projects with pure HTML, CSS, and plain JavaScript.

Then choose a front-end framework like Vue.js, Angular or React.js and stick with it. Master them, and everything else is easier.

🐣 4. Begin with Easy Projects

You want to jump into a giant game or a social media clone?

Resist. Start small. A to-do list, a simple calculator, or a color picker.

These little wins matter.

👇 Easy Project Example (Color Picker):

const colorInput = document.getElementById("colorInput");
const body = document.body;

colorInput.addEventListener("input", () => {
  body.style.backgroundColor = colorInput.value;
});

One input, one background change. Easy. But it cements your knowledge.

🚤 5. Take Your Time to Learn

Some of you want to “speedrun” coding. Big mistake.

This is not a race.

True mastery comes from slow, deliberate practice.

Don’t sin by rushing. That only leads to half-baked knowledge.

🎐 6. Regular Practice Is Good, But Don’t Overdo It

Coding every day is nice, but if you burn out, you’ll crash in the long run.

Pace yourself. Show up consistently, but take breaks. That’s how you stay hungry without losing your mind.

🥞/🍋 7. Stuck on Something? Take a Break

When your code refuses to work, you might feel the urge to fight it for hours. Sometimes, that’s necessary.

But other times, walk away. Let your mind breathe. Come back fresh.

🔥 Break Trick

Step away from your desk.
Drink water or take a short walk.
Eat delicious food. I personally do push-ups instead.
Fight the bug with a brand new fresh mind.

⛷️ 8. Learn by Doing

Reading docs, watching videos—good. But if you’re not coding, you’re lying to yourself. Real skill is built by typing, failing, debugging, and repeating.

💪 Mini-Challenge

Pick a small feature from any website you love.
Recreate it from scratch in your own code.
Push to github (your future self will be surprised)

📜 9. Plan Your Projects

Moving into code without a plan is a sin.

That’s how you end up with spaghetti code and random errors. Sketch a quick layout. Identify data structures. Then code.

Let me give an example of planning a Note App prior to writing code:

Data: Where to store notes (array, localStorage?).
Functions: addNote(), deleteNote(), displayNotes().
UI: Minimal HTML to show notes in a list.

🏎️ 10. Focus on Quality, Not Speed

Speed is tempting. “Let me build this in one night!” Then you brag about it. But your code is a big mess. Always breaks, and most often, the entire project collapses.

That’s the result of short-term glory.

Real devs write maintainable code. They think about the future. That's why writing clean code matters more than anything in the tech industry.

The reason most software companies fire these types of devs is clear:

Poor code 🆚 Clean Code

// Poor code: Hard-coded, zero flexibility
function calcPrice() {
  let price = 100;
  let tax = price * 0.15;
  console.log(price + tax);
}

// Clean code: Configurable, easy to adapt
function calcPrice(basePrice, taxRate = 0.15) {
  const total = basePrice + basePrice * taxRate;
  console.log(total);
}

📘 Grab my book, Clean Code Zero to One to master clean coding strategies and join a few who truly can write adaptable, maintainable software.

🧘‍♂️ 11. Be Patient with Your Learning

You see others landing big dev jobs. You panic. Stop comparing. Your path is your own. Focus on your front-end path and complete your 6-month or 1-year commitment regardless how you feel.

This is how all devs find their first life-changing job.
Consistency is the key. Be patient.

🏁. Conclusion

Coding is a journey, not a sprint.

Don’t let mistakes or slow progress discourage you.
Fight through the struggle.

🛬 The more you resist the temptation to quit, the closer you are to landing your dream job.

Now Go Build Something and build it right.
That’s the ONLY way you survive in this game.

Happy coding and share your thoughts in the comment section. I would love to hear that.

9 frontend devs mistakes

Programming with Shahan — Mon, 10 Mar 2025 18:43:06 +0000

You’re a newbie? Good.

That means you have nowhere to go BUT UP.

it can feel overwhelming. That’s natural.

Frontend development is all about [how well] you understand.

Not how [fast] you learn.

🪜 You either step up and do it right, or you watch your code breaks.

👉 Let me walk you through the biggest mistakes beginner frontend devs ever make, and how to avoid them.

1. 🤧 NOT Optimizing Images

Some of you test locally on a blazing-fast machine.

You forget real users have slower networks.

Some devs are too lazy to think about their users.

Let me get it straight: A 6MB image shrunk to 200px is a SIN.

Optimize your images. Every. Single. Time.

Some criminal devs try to reduce image file size by using CSS like this:

img {
  width: 200px;
  height: auto; /* keeps the aspect ratio */
}

👉 However, this does not reduce the ACTUAL file size.

If your image is still 6MB, it will still take a LONG TIME to download CSS just displays it smaller.

What a [BIG WASTE] of bandwidth. 🚮

🪧 So, CSS resizing is mostly for layout, not real optimization.

So what is the solution?

Well, the first solution I would suggest is to use online image compressor tools.

I found tinypng is a great tool for optimizing website images without reducing their quality.

You can see my photo file size reduced to -75% (4mb to 890kb); that's crazy.

⚡ Compressed images = faster load times = happy users.

⚠️ Warning: DO NOT compress images for [larger screens]. Use HTML srcset attribute instead:


<!DOCTYPE html>
<body>
  <h1>Responsive Images Example</h1>
  <!-- 
    The browser will pick the most appropriate image based on 
    the user's device width. 
    - "small.jpg" is for screens up to ~400px wide
    - "medium.jpg" is for screens up to ~800px wide
    - "large.jpg" is for anything bigger

    Each file is physically smaller in size, so smaller devices 
    don't waste bandwidth on huge images.
  -->
  <img
    src="images/large.jpg"
    alt="A beautiful scenic view"
    srcset="
      images/small.jpg   400w,
      images/medium.jpg  800w,
      images/large.jpg   1200w
    "
    sizes="
      (max-width: 400px)  400px,
      (max-width: 800px)  800px,
      1200px
    "
  />
</body>
</html>

🪨🔨 How to Optimize Images Using Node.js?

My second solution would be... use a trustworthy JavaScript library.

If you have some experience with Node.js, then here is a popular Node.js library to optimize image without reducing quality: Sharp

👇 Here’s how to use it:

const sharp = require("sharp");

sharp("large-image.jpg")  // The original, large file
  .resize(200, 150)       // Shrink dimensions
  .toFormat("jpeg", { quality: 80 }) // Convert to JPEG with 80% quality
  .toFile("optimized-image.jpg")
  .then(() => {
    console.log("Image optimized successfully!");
  })
  .catch((err) => {
    console.error("Error optimizing image:", err);
  });

2. 🥸 Using Inline Styles

Let's say you're working on a website that has [10 job offers] listed. You want them to be red to catch the user’s eye.

👇 You took the easy path:

<!-- Inline style approach -->
<a href="/job-offer/123" style="color: red;">Junior Developer</a>
<a href="/job-offer/456" style="color: red;">Frontend Engineer</a>
<a href="/job-offer/789" style="color: red;">Backend Specialist</a>
<!-- ...and so on for all your job offer links -->

Sure, it works. But the moment your boss says:

“Hey dude, make all those links blue instead. My wife hates red.🥱”

You’re in TROUBLE.
You’d have to edit [each] inline style to color: blue;.

If you have 100 links scattered across multiple pages,
that’s a MASSIVE chore.

That's one of the [quick-fix traps] most devs fall into.

✅ The CSS-Only Approach

Now, let’s do it the right way. You define a simple class in your CSS:

.link-job-offer {
  color: red;
  text-decoration: none;
  /* maybe other styles, too */
}
.link-job-offer:hover {
  color: darkred;
}

👇 Then, in your HTML:

<!-- Class-based approach -->
<a href="/job-offer/123" class="link-job-offer">Junior Developer</a>
<a href="/job-offer/456" class="link-job-offer">Frontend Engineer</a>
<a href="/job-offer/789" class="link-job-offer">Backend Specialist</a>
<!-- ...repeat for all job offer links -->

👉 Change one line in .link-job-offer for a global update. That’s power.

3. 🎭 Using Inadequate Heading Tags

Don’t use <h1> just because it’s [big and bold]. That’s an SEO sin.

Headings must reflect hierarchy. If it’s purely decorative, use a <div> or a CSS class:

<!-- Bad -->
<h1 style="font-size: 50px;">Promoted</h1>

<!-- Good -->
<div class="promo-text">Promoted</div>

Then style it in your CSS with .promo-text.

🔥🧯 Don’t sabotage your SEO for a cheap hack.

4. ❌📲 Ignoring Mobile Media Queries

You tested on desktop? Great. But [half] your users are on mobile.

If you skip media queries, you CHEAT half your audience.

It doesn't take much time; you just need to add the following CSS codes:

.container {
  width: 60%;
  margin: auto;
}

/* Mobile first approach */
@media (max-width: 600px) {
  .container {
    width: 95%;
  }
}

Resist the lazy mindset. Always check your phone or dev tools. Because if it breaks on mobile, you lose. Your users matter most.

5. 🪟 Not Benefitting from Flexbox or CSS Grid

It’s 2025. Floats are archaic. Resist your old habits. Use flex or grid. It’s faster, cleaner, simpler.

Flexbox Example:

.navbar {
  display: flex;
  justify-content: space-between;
  align-items: center;
}

🙅‍♂️ No more float nightmares.

6. 🗂️ Not Abstracting Elements

If you find yourself reusing .newsletter__title all over, that’s a sign of mistakes. Abstract it. Make a .section-title that you can use anywhere. That’s maintainable.


<!-- ❌ Wrong Approach: Using .newsletter__title everywhere -->
<section class="newsletter">
    <h2 class="newsletter__title">Subscribe to Our Newsletter</h2>
</section>

<section class="blog">
    <h2 class="newsletter__title">Latest Blog Posts</h2> <!-- Wrong! -->
</section>

<section class="events">
    <h2 class="newsletter__title">Upcoming Events</h2> <!-- Wrong! -->
</section>



<!-- ✅ Correct Approach: Abstracting with .section-title -->
<section class="newsletter">
    <h2 class="section-title">Subscribe to Our Newsletter</h2>
</section>

<!-- and so on... -->

7. 🧹 NOT Removing Redundant Styles

Some of you love to add display: block and float: right in the same rule. Or width: 100% on a block element.

That’s dead code. Clean it up.

Wrong:

.foo {
  display: block;
  float: right;
}

Right:

.foo {
  float: right; /* automatically block */
}

🤏 Less is more.

8. 🏯 Uppercasing Things in HTML

Typing <h2>JOB OFFERS</h2> is the easy route.

But that’s a sin against separation of concerns. Use CSS:

<h2 class="section-title">Job Offers</h2>

.section-title {
  text-transform: uppercase;
}

Done. Now, your text is uppercase only in presentation.

9. 💎 NOT Focusing on QUALITY

Speed is tempting. “Let me build this in one night!” Then you brag about it. But your code is a mess. Most often, the entire project collapses.

That’s the sin of short-term glory.

Real devs write maintainable code. They think about the future.

That's why writing clean code matters most in the tech industry. Grab my book Clean Code Zero to One to master this skill and join a few who truly understand everything about clean code.

The reason most software companies fire these types of devs is clear:

Poor code 🆚 Clean Code

// Poor code: Hard-coded, zero flexibility
function calcPrice() {
  let price = 100;
  let tax = price * 0.15;
  console.log(price + tax);
}

// Clean code: Configurable, easy to adapt
function calcPrice(basePrice, taxRate = 0.15) {
  const total = basePrice + basePrice * taxRate;
  console.log(total);
}

🏁. Conclusion

Frontend dev is a journey, not a sprint. Mistakes happen. That doesn't mean you SHOULD NOT look into them and struggle later.

🥊 Fight through the struggle NOW before it puts you in a painful punishment.

Happy coding and share your thoughts in the comment section. I would love to hear that.

🌱🗃️ More Learning Resources:

📘 My Book: Clean Code Zero to One
🌐 Website: codewithshahan.com
🩻 𝕏: shahancd

Which JavaScript framework is best (React or Vue in 2025?)

Programming with Shahan — Thu, 20 Feb 2025 13:34:41 +0000

React vs. Vue.js in 2025, Which One Should You Choose?

React remains one of the most popular JavaScript libraries for building single-page applications in 2025. Meanwhile, Vue.js continues to call itself a “progressive framework” and its popularity skyrocketing day by day. Both share more in common than, say... Angular, which is often considered a “true” framework.

In this article, I will walk you through a detailed comparison between React.js and Vue.js, updated with the latest 2025 trends, so you can decide which library or framework is best for your next project.

⚖️ Framework Overview

React was created by Jordan Walke, a software engineer at Facebook (now Meta). It’s maintained by Meta and a large community of individual developers and companies. In 2025, React’s ecosystem is richer than ever, making it a top choice for building complex user interfaces and handling data processing tasks.

Furthermore, React Native remains a popular extension of React.js, allowing developers to create hybrid mobile applications using the same skill set.

Vue.js, on the other hand, was created by Evan You after he worked on several Google projects using AngularJS. Vue focuses on simplicity and efficiency in UI design and development. By 2025, its intuitive syntax and built-in features (like transitions and official state management via Pinia) have continued to attract developers seeking a straightforward framework for building interfaces.

🍏 Reasons for Using Vue.js

Vue.js has maintained its reputation for simplicity. Developers appreciate its clear and logical design, which speeds up development workflows. Unlike some other frameworks, Vue.js retains a consistent syntax throughout UI functionality. That's why I love it personally.

Efficient Official Plugins: Vue’s core team provides well-structured solutions for common tasks like routing and state management.
No Corporate Ownership: As of 2025, Vue remains community-driven and independent, appealing to developers wary of data exploitation by large tech companies.
Great Ecosystem: Plugins like Vue Router and Pinia cover most app needs out of the box.

⚛️ Reasons for Using React

React.js brings unique features that keep it at the top of many developers’ lists (even though its popularity has been declining over time).

Here is why it is still popular nowadays:

JSX Syntax: JSX (JavaScript XML) makes creating custom components more intuitive. You can write HTML-like code within JavaScript, streamlining component creation.
SEO Support: React.js applications are relatively easy to optimize for search engines, especially when combined with frameworks like Next.js.
React Native: Developers can reuse their React.js knowledge to build native mobile apps for iOS and Android.
React Dev Tools: In 2025, the React Developer Tools are more handy than ever, offering deep insights for debugging and organizing complex apps.

🥇 Comparison of Popularity and Performance

Both React.js and Vue.js remain in high demand in 2025. React has a slight edge in terms of overall popularity, backed by its extensive ecosystem and the community around React Native.

Performance: Both use a virtual DOM for efficient rendering. Vue.js often shines in component creation and updates due to its super fast optimizations.
Usage Stats: According to a 2025 developer survey, over 45% of respondents have used React.js for web development, while around 20% have used Vue.js.

Note: The Statista survey report from previous years still shows React leading in global adoption, though Vue continues to grow steadily.

🧊 Scalability

React.js has the idea of “smart” and “dumb” components to manage complex architectures. Smart components handle data-heavy tasks, while dumb components focus on rendering.

Vue.js offers official libraries like Pinia for state management, enabling developers to handle larger applications. By 2025, Vue 3+ has proven its ability to scale effectively in enterprise projects.

📲 Adjust to Mobile Devices

Both frameworks have a growing demand for cross-platform solutions, although Vue.js is becoming more popular day by day. Let's have a brief overview:

React Native: An established leader for building native iOS and Android apps with React.js.
Weex (Vue): A mobile UI framework by Alibaba Group, allowing Vue.js components to run on mobile. While not as widespread as React Native, Weex provides a solid Vue-based mobile solution.

🚎🔩 Size and Community Support

Bundle Size: Vue.js typically ships with a smaller bundle size, making it ideal for projects prioritizing fast load times.
Community: React benefits from Meta’s backing and a massive open-source ecosystem. Vue.js, though smaller, boasts an active and dedicated community with thorough documentation and ongoing improvements. I think it's becoming more popular than React.js as recent data suggests.

🏒 Use Cases

React.js: Perfect for complex web apps, large-scale projects, and teams needing to pivot between web and mobile with React Native.
Vue.js: Ideal for small to medium-sized apps, real-time platforms, and content delivery systems where simplicity and performance are key.

🏇 Recommendation: Clean Code Book (2025)

If you’re serious about mastering clean code and taking your programming career to the next level, then my book for you: Clean Code Zero to One. I am offering 50% discount using the code "earlybird" during checkout — only for the first 50 copies! Plus, enjoy a 30-day money-back guarantee — no risk, all reward.

👏 Conclusion

I would say React.js is the first choice for developing large and complex apps. Also React Native for mobile apps is a huge plus. But you have to write separate code for web and mobile apps which is a huge downside as well. Therefore, plus-minus = zero.

Vue.js, meanwhile, is loved for its simplicity, fast performance, and smaller default size. It’s a more lightweight framework without sacrificing modern features. The great news is, you don't have to write separate code for web or mobile. Write once and now you can build desktop, mobile, or web apps in one go. So no downside. Only plus plus.

I would choose Vue.js for its simplicity and super fast performance.

Thank you for your time. For more regular posts visit: codewithshahan.com

If you enjoyed this, check out my 𝕏 (Twitter) account for more frontend development insights.

Related Articles:

Code Optimization for Game Development

Programming with Shahan — Sun, 16 Feb 2025 05:46:59 +0000

Game development is a battlefield. Either you optimize, or you lose.

I don’t care if you’re an experienced developer with 10 years of experience or 1 year of experience. If you want to make games that WORK, games people respect—you need to understand optimization.

Players demand smooth gameplay, high-quality visuals, and a flawless experience across every device. If your game stutters, crashes, or loads slower than a snail? You’re done.

Optimization isn’t magic. It’s the foundation of smooth gameplay, fast loading, and stable performance. Without it, your game will lag, crash, and be forgotten faster than you can say “game over.”

But don’t worry. In this article, I will share four effective strategies to help you with that.

Effective Strategies for Performance Optimization

🤸‍♂️ What Is Optimization? Optimization means making your game run as fast and smooth as possible. SIMPLE.

When you optimize your game, you:

🤏 Reduce loading times.
🖥️ Make the game work on weaker computers or phones.
💉 Prevent lag and crashes.

Rule 1: Memory Management

When you’re developing a game, memory is your most valuable resource.

Every player movement, every enemy on the screen, every explosion needs a little piece of memory to function. Unfortunately, memory isn’t unlimited.

If you don’t manage memory properly, your game can get slow, laggy, or even crash. That’s why memory management is a critical skill every game developer needs. Let’s break it down step by step, with detailed examples in Python.

Strategy #1: Memory Pooling

This strategy is simple: reuse Objects Instead of Creating New Ones** Memory pooling is like recycling for your game. Instead of creating new objects every time you need one, you reuse objects you’ve already created.

Creating and destroying objects repeatedly takes up time and memory. Let's say you are building a shooting game where the player fires 10 bullets per second. If you create a new bullet for each shot, your game could quickly slow down.

Here’s how you can implement memory pooling for bullets in a shooting game:

class Bullet:
    def __init__(self):
        self.active = False  # Bullet starts as inactive

    def shoot(self, x, y):
        self.active = True  # Activate the bullet
        self.x = x
        self.y = y
        print(f"Bullet fired at position ({x}, {y})!")

    def reset(self):
        self.active = False  # Deactivate the bullet so it can be reused

# Create a pool of 10 bullets
bullet_pool = [Bullet() for _ in range(10)]

def fire_bullet(x, y):
    # Look for an inactive bullet in the pool
    for bullet in bullet_pool:
        if not bullet.active:
            bullet.shoot(x, y)  # Reuse the inactive bullet
            return
    print("No bullets available!")  # All bullets are in use

# Example usage
fire_bullet(10, 20)  # Fires a bullet at position (10, 20)
fire_bullet(30, 40)  # Fires another bullet at position (30, 40)
bullet_pool[0].reset()  # Reset the first bullet
fire_bullet(50, 60)  # Reuses the reset bullet

🍵 Explanation:

The Bullet Class: Defines what a bullet does and keeps track of whether it’s active (in use) or not.
The bullet_pool: A list of 10 reusable bullets.
The fire_bullet Function: Finds an inactive bullet, reuses it, and sets its position.
Recycling Bullets: When you’re done with a bullet, you reset it so it can be reused.

Strategy #2. Data Structure Optimization

The way you store your data can make or break your game’s performance. Choosing the wrong data structure is like trying to carry water in a leaky bucket—it’s inefficient and messy.

Let’s say you’re making a game for four players, and you want to keep track of their scores. You could use a list, but a fixed-size array is more efficient because it uses less memory.

from array import array

# Create a fixed-size array to store player scores
player_scores = array('i', [0, 0, 0, 0])  # 'i' means integers

# Update scores
player_scores[0] += 10  # Player 1 scores 10 points
player_scores[2] += 15  # Player 3 scores 15 points

print(player_scores)  # Output: array('i', [10, 0, 15, 0])

🍵 Explanation:

The array Module: Creates a fixed-size array of integers ('i').
Fixed Size: You can’t accidentally add or remove elements, which prevents bugs and saves memory.
Efficient Updates: Updating scores is quick and uses minimal resources.

Strategy #3. Memory Profiling

Even if your code seems perfect, hidden memory problems can still exist. Memory profiling helps you monitor how much memory your game is using and find issues like memory leaks.

Python has a built-in tool called tracemalloc that tracks memory usage. Here’s how to use it:

import tracemalloc

# Start tracking memory
tracemalloc.start()

# Simulate memory usage
large_list = [i ** 2 for i in range(100000)]  # A list of squares

# Check memory usage
current, peak = tracemalloc.get_traced_memory()
print(f"Current memory usage: {current / 1024 / 1024:.2f} MB")
print(f"Peak memory usage: {peak / 1024 / 1024:.2f} MB")

# Stop tracking memory
tracemalloc.stop()

🍵 Explanation:

Start Tracking: tracemalloc.start() begins monitoring memory usage.
Trigger Memory Use: Create a large list to use up memory.
Check Usage: Get the current and peak memory usage, converting it to megabytes for readability.
Stop Tracking: tracemalloc.stop() ends the tracking session.

Now it’s your turn to practice these strategies and take your game development skills to the next level!

Rule 2: Asset Streaming (Load Only What You Need)

If you load the entire world at once, your game will choke and die. You don’t need that drama. Instead, stream assets as the player needs them. This is called asset streaming.

For instance, inside your game, you may have a huge open-world with forests, deserts, and cities. Why load all those levels at once when the player is only in the forest? Makes no sense, right? Load only what’s needed and keep your game lean, fast, and smooth.

Strategy #1: Segment and Prioritize

Let’s break this down with an example. Your player is exploring different levels: Forest, Desert, and City. We’ll only load a level when the player enters it.

Here’s how to make it work in Python:

class Level:
    def __init__(self, name):
        self.name = name
        self.loaded = False  # Starts as unloaded

    def load(self):
        if not self.loaded:
            print(f"Loading level: {self.name}")
            self.loaded = True  # Mark the level as loaded

# Create levels
levels = [Level("Forest"), Level("Desert"), Level("City")]

def enter_level(level_name):
    for level in levels:
        if level.name == level_name:
            level.load()  # Load the level if it hasn’t been loaded yet
            print(f"Entered {level_name}!")
            return
    print("Level not found!")  # Handle invalid level names

# Simulate entering levels
enter_level("Forest")  # Loads and enters the forest
enter_level("City")    # Loads and enters the city

⚡Explanation:

Levels Class: Each level has a name (e.g., Forest) and a “loaded” status. If it’s loaded, it doesn’t load again.
Dynamic Loading: The enter_level function finds the level the player wants to enter and loads it only if it hasn’t been loaded yet.
Efficiency: Levels not visited don’t waste memory. The game runs smoothly because it only focuses on what the player needs.

This is efficiency at its finest. No wasted memory, no wasted time. Your player moves; your game adapts. That’s how you dominate.

Strategy #2: Asynchronous Loading (No Waiting Allowed)

Nobody likes waiting. Freezing screens? Laggy loading? It’s amateur hour. You need asynchronous loading—this loads assets in the background while your player keeps playing.

Imagine downloading a huge map while still exploring the current one. Your game keeps moving, the player stays happy.

Here’s how to simulate asynchronous loading in Python:

import threading
import time

class AssetLoader:
    def __init__(self, asset_name):
        self.asset_name = asset_name
        self.loaded = False

    def load(self):
        print(f"Starting to load {self.asset_name}...")
        time.sleep(2)  # Simulates loading time
        self.loaded = True
        print(f"{self.asset_name} loaded!")

def async_load(asset_name):
    loader = AssetLoader(asset_name)
    threading.Thread(target=loader.load).start()  # Load in a separate thread

# Simulate async loading
async_load("Forest Map")
print("Player is still exploring...")
time.sleep(3)  # Wait for loading to finish

🍵 Demonstration:

Separate Threads: The threading module creates a new thread to load assets without freezing the main game.
Simulated Delay: The time.sleep function fakes the loading time to mimic how it works in a real game.
Smooth Gameplay: The player can continue playing while the new level or asset loads in the background.

With asynchronous loading, your player stays in the zone, and your game feels seamless. Pro-level stuff.

Strategy 3: Level of Detail (LOD) Systems – Be Smart About Quality

Not everything in your game needs to look like it’s been rendered by a Hollywood studio. If an object is far away, lower its quality. It’s called Level of Detail (LOD), and it’s how you keep your game’s performance sharp.

Example: Using LOD for a Tree

Here’s a Python simulation of switching between high and low detail:

class Tree:
    def __init__(self, distance):
        self.distance = distance

    def render(self):
        if self.distance < 50:  # Close-up
            print("Rendering high-detail tree!")
        else:  # Far away
            print("Rendering low-detail tree.")

# Simulate different distances
close_tree = Tree(distance=30)
far_tree = Tree(distance=100)

close_tree.render()  # High detail
far_tree.render()    # Low detail

🍵 Explanation:

Distance Matters: The distance property determines how far the tree is from the player.
High vs. Low Detail: If the tree is close, render it in high detail. If it’s far, use low detail to save memory and processing power.
Optimized Performance: The player doesn’t notice the difference, but your game runs smoother and faster.

This is how you keep the balance between beauty and performance. Your game looks stunning up close but doesn’t waste resources on faraway objects.

🧳To Summarize

Efficiency Wins: Only load what you need, when you need it. No wasted memory.
Player Satisfaction: Smooth gameplay keeps players engaged and avoids frustration.
Professional Quality: These techniques are how AAA games stay fast and responsive.

🫵 Your move now: Go apply these strategies, keep your game lean, and make sure your players never even think about lag.

Rule 3: Frame Rate Stabilization

The frame rate is how many pictures (frames) your game shows per second. If it’s unstable, your game will stutter and feel broken.

The secret? Keep the workload for each frame consistent.

🚦Here’s how you can control the timing in a game loop:

import time

def game_loop():
    fixed_time_step = 0.016  # 16 milliseconds = 60 frames per second
    last_time = time.time()

    while True:
        current_time = time.time()
        elapsed_time = current_time - last_time

        if elapsed_time >= fixed_time_step:
            # Update game logic
            print("Updating game...")
            last_time = current_time

# Run the game loop
game_loop()

⚖️ The game updates at a steady rate (60 times per second).
🪂 This make smooth gameplay, no matter how slow or fast the computer is.

🎯Techniques to EXCEL:

Optimize Rendering Paths: Fewer draw calls. Smarter culling. Simplicity wins.
Dynamic Resolution Scaling: When the pressure’s on, scale down resolution to maintain the frame rate. Players won’t even notice.
Fixed Time Step: Keep your physics and logic consistent. Frame rate fluctuations shouldn’t mean chaos.

Rule 4: GPU and CPU Optimization

Your computer has two main processors:

CPU: Handles logic, like moving a character or calculating scores.
GPU: Handles graphics, like drawing your game world.

👇 Here's what you have to do for GPU/CPU optimization:

Profile Everything: Use tools to pinpoint bottlenecks and strike hard where it hurts.
Shader Optimization: Shaders are resource hogs. Simplify them, streamline them, and cut the fat.
Multithreading: Spread tasks across CPU cores. Don’t overload one and leave the others idle.

If one is working too hard while the other is idle, your game will lag.

Solution? Multithreading.
Let’s split tasks between two threads:

import threading

def update_game_logic():
    while True:
        print("Updating game logic...")
        time.sleep(0.1)

def render_graphics():
    while True:
        print("Rendering graphics...")
        time.sleep(0.1)

# Run tasks on separate threads
logic_thread = threading.Thread(target=update_game_logic)
graphics_thread = threading.Thread(target=render_graphics)

logic_thread.start()
graphics_thread.start()

🎰 One thread handles logic.
🛣️ Another thread handles graphics.
⚖️ This balances the workload and prevents bottlenecks.

👏 Conclusion

Optimization isn’t just for “smart” people. It’s simple if you take it step by step:

Manage memory like a pro. Don’t waste it.
Stream assets. Load only what you need.
Keep the frame rate stable. No stuttering.
Balance the workload. Use the CPU and GPU wisely.

Start optimizing NOW. Your future self will thank you.

Visit my website codewithshahan to grab my book "Clean Code Zero to One" to improve your game optimization skills.

How to Write Better Code for Agile Software Development (Handbook)

Programming with Shahan — Thu, 06 Feb 2025 14:10:12 +0000

Building scalable software applications requires writing clean code that’s so simple that any dev can understand it.

In this article, I’ll explain and demonstrate what clean code is. Then I’ll share my favorite clean code patterns for building modern Agile applications.

I won’t use complex jargon. I’ll hit you with simple, clear JavaScript examples that focus on the core concepts. Straight to the point, no nonsense – that’s how I roll.

Let’s get started.

In Agile, where change is the only constant, clean code is your armor. It makes you adaptable, swift, and, most importantly, in control.

Here’s the truth: writing clean code is not optional if you want to survive in the software development industry. Fortunately, we human beings are able to master clean code with some effort and practice.

The Cost of Bad Code

To explain this stack bar graph, in the initial development phase, bad code is slightly more costly to change than clean code.

But as we move into the maintenance and refactoring phases, the gap widens significantly, with bad code costing nearly twice as much as clean code.

By the legacy phase, bad code reaches 100% cost – now it’s extremely expensive to update, while clean code remains more manageable at 45%.

As of now, the most recent analysis on the cost of poor software quality in the U.S. is the 2022 report by the Consortium for Information and Software Quality (cisq.org). This report estimates that poor software quality cost the U.S. economy at least $2.41 trillion in 2022, with technical debt accounting for about $1.52 trillion of this amount.

You can read more about that here.

Recent discussions continue to highlight the significant impact of technical debt on software quality and business performance.

For instance, a 2024 survey indicated that for more than 50% of companies, technical debt accounts for greater than a quarter of their total IT budget. And this can really hinder innovation if it’s not addressed.

As you can see, there’s no doubt that bad code is a costly problem in software development.

Clean Coder vs. Messy Coder

Here’s a graph that shows the journey of two types of coders:

⚠️ The Messy Coder (Red line): Starts fast but crashes hard. The more lines they write, the more trouble they make.
⚡ The Clean Coder (Blue line): Starts slow but stays consistent. Growth doesn’t stop — it accelerates.

🫵 Now, you decide which line you want to follow.

AI Can’t Save You If Your Code is a Mess 🗑️

When you get stuck writing code, you might turn to AI. But let me tell you something: AI can’t save you if your code is a mess.

It’s like building a house on sand. Sure, it stands for a while, but one strong gust of wind or big wave, and it collapses.

Remember: AI is just a tool. If you don’t know how to write clean, scalable applications, you're setting yourself up for failure.

If you can’t maintain the code you write, you’re in trouble.

I’ve seen it over and over again: developers who know five programming languages. They can build apps, websites, software. They know algorithms and data structures like the back of their hand.

But when faced with a large project or someone else’s messy code, they crumble.

They’re like an aerospace engineer who designs and builds their own planes but doesn’t know how to fly them. They crash into their own code.

This was me...once upon a time. I’d write thousands of lines of code, only to realize I couldn’t even understand what I wrote last week. It was chaos for me.

But then it hit me — every developer struggles with this. It wasn't about how much I knew. It was about how I organized and structured what I knew. In other words, it was about knowing the art of programming itself.

I decided to escape this trap. After five months of intense work — four to five hours a day writing, designing, and researching — I created something I wish I had when I started programming. A book that’s a complete beginner’s guide: Clean Code Zero to One.

If you want to learn more about the book, I give you all the details at the end of this tutorial. So read on to learn more about writing clean code.

12 Clean Code Design Patterns for Building Agile Applications ⚖️

If your code doesn’t follow these modern clean code design patterns, you could be creating a ticking time bomb. These patterns are your tools. Master them and enjoy the success of your projects. Let me show you one by one.

🌿 Use Names That Mean Something

Naming your variables or functions b or x is not helpful. Call them what they are so they’re easier to understand. Here’s an example of both a bad and good variable name:

// Weak and vague
let b = 5;

// Strong and clear
let numberOfUsers = 5;

People who write unclear names don’t want to own their mistakes. Don’t be that person.

🔨 Keep Functions Laser-Focused (SRP)

A function should do one thing—and do it perfectly. This is called the Single Responsibility Principle (SRP).

Good code is like a hammer. It hits one nail, not ten. For example, if you are hiring someone to do everything in your company — finance, sales, marketing, janitorial work, and so on — they’ll likely fail miserably because they can’t focus one one thing. The same goes for your classes in code.

🚧 When a class or function does more than one thing, it becomes a tangled mess. Debugging it feels like solving a puzzle upside down. If your class handles both user input and database operations, for example, it’s not multitasking — it’s madness. Break it up. One method, one job.

🔥 My Rule: Your code works for you. Keep it sharp, focused, and controllable, or it’s going to control you. Here is how to make that happen:

// Clean: One job, one focus
function calculateTotal(a, b) {
    return a + b;
}

function logTotal(user, total) {
    console.log(`User: ${user}, Total: ${total}`);
}

// Messy: Trying to do EVERYTHING
function calculateAndLogTotal(a, b, user) {
    let total = a + b;
    console.log(`User: ${user}, Total: ${total}`);
}

🪧 When you mix tasks, you mix in confusion. As simple as that.

🚪 Use Comments Thoughtfully

There is a great saying among professional developers:

“ Code speaks for itself. ”

You don’t explain what a door does every time someone walks into a room, do you? Your code should work the same way.

Comments aren’t bad, but if your code can’t stand on its own, then you may have a problem.

🪧 A good comment should tell “why” not “how or what”. If a developer doesn’t understand “how” something works, then they likely aren’t going to understand “why” either.

Here are some short examples of good comments vs bad comments. I’ll also show you a real-world project for writing clean comments.

Example 1: Bad Comment 👎

// Multiply the price by the quantity to calculate the total
const total = price * quantity;

This is a bad comment because it simply repeats what the code already says. The code price * quantity is self-explanatory, so the comment doesn’t add anything useful.

Good Comment: 👍

If the code is clear and simple, you don’t need a comment.

const total = price * quantity;

Example 2: Bad Comment 👎

// Check if the user logged in
function isUserLoggedIn(session) {
    return !!session.user;
}

This comment is bad because it doesn’t explain why the isUserLoggin() exists. It just explains what happens. But we already know that this is an auth function. This comment is a waste of time.

Good Example 👍

// The user is authenticated before accessing protected resources
function isUserLoggedIn(session) {
    return !!session.user;
}

This is a good comment because it explains why the code exists. It tells us that the function checks if the user is authenticated before allowing access to sensitive parts of the app. It focuses on the bigger picture.

⚡ Best Practices for Writing Good Comments

Explain the “Why,” not the “What”:

Write comments to explain the purpose or context of the code, not what the code is doing.
Avoid obvious comments:

Don’t write comments for things the code already makes clear.
Keep them short and precise:

Write concise comments that are easy to read and directly explain the purpose.
Update comments regularly:

Outdated comments can mislead developers, so always update them when the code changes.

Real-World Example (with Good Comments) 🛒

Let’s implement these practices into a real-world project: a large e-commerce application. One function calculates shipping costs based on the order details. Here's the full code, I will explain each comment below:

// Shipping rules:
// - Free shipping for orders over $100
// - Standard shipping ($10) for orders below $100
// - Additional $5 for international orders

function calculateShipping(order) {
    let shippingCost = 0;

    // Check if the order qualifies for free shipping
    if (order.total >= 100) {
        shippingCost = 0; // Free shipping
    } else {
        shippingCost = 10; // Standard shipping cost
    }

    // Add additional cost for international orders
    if (order.isInternational) {
        shippingCost += 5;
    }

    return shippingCost;
}

// Example usage
const order1 = { total: 120, isInternational: false };
const order2 = { total: 80, isInternational: true };

console.log(calculateShipping(order1)); // Output: 0
console.log(calculateShipping(order2)); // Output: 15

At the start of the function, we include a comment explaining the rules for shipping costs. This gives the reader an overview of the logic without needing to read the full code.

// Shipping rules:
// - Free shipping for orders over $100
// - Standard shipping ($10) for orders below $100
// - Additional $5 for international orders

Then, the first condition checks if the order total is greater than or equal to $100. A comment here clarifies why free shipping is applied.

// Check if the order qualifies for free shipping
if (order.total >= 100) {
    shippingCost = 0; // Free shipping
}

The second condition applies an additional charge for international shipping. The comment explains why the extra cost is added.

// Add additional cost for international orders
if (order.isInternational) {
    shippingCost += 5;
}

Why are these comments good?

Imagine you’re working in a team of 20 developers. Someone reads the calculateShipping function six months later. Without these comments, they might waste time guessing why international orders have an extra fee. Good comments clarify the why and save hours of frustration.

🧩 Make Your Code Readable

If someone reading your code feels like they’re solving a riddle, you’ve already become a troublemaker. Here is the proof:

// Clean: Reads like a story
if (isLoggedIn) {
    console.log("Welcome!");
} else {
    console.log("Please log in.");
}

// Messy: Feels like chaos
if(isLoggedIn){console.log("Welcome!");}else{console.log("Please log in.");}

If your code is messy and hard to read, it will confuse others—and even yourself later! Imagine coming back to your own code after six months and feeling like you’re reading a foreign language. Readable code saves time, reduces bugs, and makes everyone’s life easier.

🍵 Why is Readability Important?

For yourself: When you revisit your code after weeks or months, clean code helps you pick up where you left off without wasting time figuring out what you did.
For your team: If someone else reads your code, they shouldn’t have to solve a puzzle. Clean code makes teamwork smoother and prevents miscommunication.
Fewer bugs: Clear code is easier to debug because you can quickly spot mistakes.

🧙‍♂️ How to Write Readable Code

Let’s build a simple program to manage books in a library. We’ll make it clean and readable and then I will break down this code below:

// A class to represent a book
class Book {
    constructor(title, author, isAvailable) {
        this.title = title;
        this.author = author;
        this.isAvailable = isAvailable;
    }

    borrow() {
        if (this.isAvailable) {
            this.isAvailable = false;
            console.log(`You borrowed "${this.title}".`);
        } else {
            console.log(`Sorry, "${this.title}" is not available.`);
        }
    }

    returnBook() {
        this.isAvailable = true;
        console.log(`You returned "${this.title}".`);
    }
}

// A function to display available books
function displayAvailableBooks(books) {
    console.log("Available books:");
    books.forEach((book) => {
        if (book.isAvailable) {
            console.log(`- ${book.title} by ${book.author}`);
        }
    });
}

// Example usage
const book1 = new Book("The Clean Coder", "Robert Martin", true);
const book2 = new Book("You Don’t Know JS", "Kyle Simpson", false);
const book3 = new Book("Eloquent JavaScript", "Marijn Haverbeke", true);

const library = [book1, book2, book3];

displayAvailableBooks(library); // Show available books
book1.borrow(); // Borrow a book
displayAvailableBooks(library); // Show available books again
book1.returnBook(); // Return the book
displayAvailableBooks(library); // Final list

We created a Book class to represent each book. It has properties like title, author, and isAvailable to track its status.

The borrow method checks if the book is available. If yes, it marks it as unavailable and prints a message.
The returnBook method makes the book available again.
The displayAvailableBooks function loops through the library and prints only the books that are available.
We create three books (book1, book2, book3) and store them in a library array.
We borrow and return books, showing how the list of available books changes.

As you can see, readable code is not just about style. It saves time, prevents bugs, and preserves your code as useful for years to come.

🏌️ Test Everything You Write

If you don’t take the time to write tests, you shouldn’t be surprised if your code breaks. If you do want to write tests, follow this unit testing strategy to catch problems ahead.

What Is Unit Testing?

Concretely, unit testing checks individual parts of your code (like functions or classes) to ensure they work correctly. Just like checking each brick of your house for soundness before building the walls.

Let me give you an example of how unit testing works:

class Calculator {
    add(a, b) { return a + b; }
    subtract(a, b) { return a - b; }
}

// Test it (Unit Test)
const calculator = new Calculator();
console.assert(calculator.add(2, 3) === 5, "Addition failed");
console.assert(calculator.subtract(5, 3) === 2, "Subtraction failed");

Here’s what’s going on in this code:

First, we create the calculator class:

class Calculator {
    add(a, b) { return a + b; }
    subtract(a, b) { return a - b; }
}

The Calculator class has two methods: add and subtract.

add(a, b) takes two numbers and returns their sum.
subtract(a, b) takes two numbers and returns their difference.

Next, we set up the tests:

const calculator = new Calculator();

Here, we’re creating an instance of the Calculator class to test its methods.

Then we write test cases:

console.assert(calculator.add(2, 3) === 5, "Addition failed");
console.assert(calculator.subtract(5, 3) === 2, "Subtraction failed");

console.assert(condition, message) checks if the condition is true. If it’s false, the message ("Addition failed" or "Subtraction failed") is displayed in the console.

First test: calculator.add(2, 3) === 5
- Calls the add method with 2 and 3.
- Checks if the result is 5.
Second test: calculator.subtract(5, 3) === 2
- Calls the subtract method with 5 and 3.
- Checks if the result is 2.

So what happens if something breaks? It’s pretty simple to solve any issues that arise here. In this case, if the add or subtract method doesn’t work correctly, the test will fail. For example:

console.assert(calculator.add(2, 3) === 6, "Addition failed");

The condition calculator.add(2, 3) === 6 is false.
The console will display: "Addition failed".

Real-World Example: Testing a Login System 👥

Let’s test a simple login system to see how unit testing works in a real-world scenario.

class Auth {
    login(username, password) {
        return username === "admin" && password === "1234";
    }
}

// Test the Auth class
const auth = new Auth();
console.assert(auth.login("admin", "et5t45#@") === true, "Login failed for valid credentials");
console.assert(auth.login("user", "wrongpassword") === false, "Login succeeded for invalid credentials");

First, create the Auth class:

class Auth {
    login(username, password) {
        return username === "admin" && password === "1234";
    }
}

The login method checks if the username is "admin" and the password is "1234". If both match, it returns true – otherwise, false.

Next, set up the tests:

const auth = new Auth();

Create an instance of the Auth class. Then write the test cases:

console.assert(auth.login("admin", "1234") === true, "Login failed for valid credentials");
console.assert(auth.login("user", "wrongpassword") === false, "Login succeeded for invalid credentials");

First test: Checks if valid credentials ("admin", "1234") succeed. If not, "Login failed for valid credentials" is displayed.
Second test: Checks if invalid credentials ("user", "wrongpassword") fail. If not, "Login succeeded for invalid credentials" is displayed.

🌱 Why testing results in clean code:

You naturally write smaller, more focused functions to make your code testable
Tests verify that your code behaves as expected under different conditions.
With tests in place, you can confidently update your code, knowing the tests will catch any mistakes.

💉 Use Dependency Injection

Hardcoding dependencies is like tattooing someone’s name on your forehead — it’s permanent, can be abrasive, and locks you in.

So, what does Dependency Injection do? It lets you manage your code's relationships by passing dependencies as arguments. It’s flexible, adaptable, and maintainable.

To demonstrate how it works, here I’m using the Nodemailer dependency for sending emails to users:

// Dependency: Sending emails with Nodemailer
const nodemailer = require('nodemailer');
function sendEmail(to, subject, message) {
    const transporter = nodemailer.createTransport({ /* config */ });
    return transporter.sendMail({ from: "programmingwithshahan@gmail.com", to, subject, text: message });
}

⚠️ To save yourself from risk, make sure to avoid hardcoding dependencies. Use abstraction or configuration files for secure maintenance.

This is just one example. As a developer, you may use hundreds of libraries or dependencies.

I’m not saying you shouldn’t rely on dependencies/libraries at all, as nowadays it is hard to avoid them. But you should be very careful before installing them in your coding projects.

You should check the security, performance, quality, or functionality of an organization's software systems. Because they sometimes contain risks that can ruin your entire project.

🚧 Always control your tools, don't let them control you.

📂 Clean Project Structures

A well-organized project is the difference between a trash heap and a high-end boutique.

Here is how each folder should be organized:

If your codebase looks like a junk drawer, you’ve already caused trouble for your future self.

Let’s go through the clean project structure you can see above to better understand it:

1. myProjet/src

This is the main container for your entire application. Everything your app needs is stored inside this folder. It has subfolders to keep things tidy and managed in one place.

2. components

This is where you keep all the reusable pieces of your app. You can use these components in multiple places without building them again.

3. services

This is the "brain" of your app. It handles all the work behind the scenes for both the frontend and backend. emailService.js, userService.js and productService.js are some of the example files for your services folder.

4. utils

This contains all the small, handy tools you need to make your application run smoothly and make your life easier. For example, formatedate.js, validateEmail.js and generateId.js are some of the common utils files to make reusable pieces of components for your entire project.

5. `tests`

Conventionally, test files are typically located outside the src folder, at the project root level. This keeps your production code (src) separate from your test code (tests), making it cleaner and easier to manage. Have a look:

myProject/
├── src/              # Production code
│   ├── components/
│   ├── services/
│   └── utils/
├── tests/            # Test files
│   ├── components/
│   ├── services/
│   └── utils/
├── package.json      # Project configuration
└── README.md         # Documentation

Some developers may prefer creating one testing file inside the test folder to test everything in one place. Unfortunately, it may feel clean at first, but as your project grows, you’ll have to find and search for specific code blocks. It’s ugly and can produce unexpected testing results. So breaking them into multiple testing files inside the tests folder is highly recommended.

Real-world example 📧

So let me create a clean, durable project structure for you to apply in any future projects you might work on. Needless to say, clean project structure is the foundation of building a maintainable project.

From our previous email sending application example, we will write a clean project structure for this app. We want to build an application that sends emails to users. Your clean project structure for this app should look like this:

As you can see, I packed every subfolder and file inside the src folder which is the main container of our application. Inside the src folder, we created components, services, utiles. Finally, we have a manageable test folder outside the src folder to test each component independently. This test folder has nothing to do with our production code that is located inside the src folder.

🤹‍♂️ Be Consistent with Formatting

Don’t write code like you’re 10 different people. Be consistent with your formatting.

Use tools like Prettier or ESLint to enforce a consistent style. If every file looks different, you’re creating chaos that no one wants to fix.

I would say that consistency in formatting is one of the most important aspects of writing clean code.

Have a look...

// Always use 2 spaces for indentation
function calculateArea(width, height) {
  if (width <= 0 || height <= 0) {
    throw new Error("Dimensions must be positive numbers.");
  }
  return width * height;
}

// Add meaningful whitespace for readability
const rectangle = {
  width: 10,
  height: 20,
};

// Clear separation of logic
try {
  const area = calculateArea(rectangle.width, rectangle.height);
  console.log(`Area: ${area}`);
} catch (error) {
  console.error(error.message);
}

Let’s examine some of the aspects of this code that make it clean:

1️⃣ Consistent Indentation

Why 2 or 4 spaces? It’s clean, minimal, and universally accepted in many JavaScript style guides. It doesn’t overwhelm the eyes, and the code structure stands out clearly. When you mix inconsistent indentation (2 spaces here, 4 spaces there), you confuse people—and confused people make mistakes.

2️⃣ Meaningful Whitespace: Giving Code Room to Breathe

That extra line break between the rectangle definition and the try block is like a pause in a sentence — it gives the reader time to process.

3️⃣ Clear Separation of Logic: Modular Thinking

try {
  const area = calculateArea(rectangle.width, rectangle.height);
  console.log(`Area: ${area}`);
} catch (error) {
  console.error(error.message);
}

Look at how the logic is divided into clear sections:

First, the calculation (calculateArea function).
Then, the output (console.log).
Finally, error handling (catch block).

Each task has its own space and purpose.

4️⃣ Readable Error Handling

When you throw errors or log messages, you format them cleanly. No vague or cryptic messages here. A developer seeing this will immediately know the problem.

throw new Error("Dimensions must be positive numbers.");

🐦‍⬛ General tips for consistent formatting:

Use 2 or 4 spaces for indentation consistently throughout your codebase. Avoid tabs to maintain uniformity across different editors.
Keep lines to a maximum of 100-120 characters to prevent horizontal scrolling and improve readability.
Group related logic together and separate blocks of code with blank lines to highlight their purpose.
Finally, avoid over-aligning code. Instead, let indentation naturally guide the flow of logic.

✋ Stop Hardcoding Values

Hardcoding values is a lazy way to code. Here is the proof:

// Bad: Hardcoded and rigid
function createUser() {
    const maxUsers = 100;
    if (currentUsers >= maxUsers) throw "Too many users!";
}

// Clean: Dynamic and flexible
const MAX_USERS = 100;
function createUser() {
    if (currentUsers >= MAX_USERS) throw "Too many users!";
}

You see, changing this variable won’t surprise you in the future. You know exactly where to find it to change uncertain values.

Its best to store your fixed values in the global configuration (config) file.

🪧 So, avoid hardcoding values at all costs. Hardcoding is the shortcut that may drive your future self (or others) crazy.

🤏 Keep Functions Short

If your function is longer than 20 lines, it’s probably trying to do too much_._

Short functions are sharp functions. They hit their mark every time.

Long, bloated functions are messy and hard to read, but short functions are clear and focused. Here is how your large functions should break down:

function updateCart(cart, item) {
    addItemToCart(cart, item);
    let total = calculateTotal(cart);
    logTransaction(item, total);
    return total;
}

function addItemToCart(cart, item) {
    cart.items.push(item);
}

Let me explain this code so you understand why breaking down large functions is a winning strategy.

The Main Function: updateCart() calls smaller helper functions to handle specific tasks like:

-  Adds the item to the cart.

-  Calculates the total price.

-  Logs the details of the transaction.

-  Finally, it returns the total price.

Instead of one long block of code that tries to do everything, it delegates tasks to helper functions.

Helper Function: addItemToCart() This function only handles adding the item to the cart. if you need to change how items are added (for example, checking for duplicates). You could just edit this small function instead of digging through a giant block of code in updateCart. That’s how you write clean code functions that’s a joy to read and easy to maintain.

What Happens If Functions Are Too Long? 💤

Let’s say you didn’t break down the updateCart function. Here’s what it might look like:

function updateCart(cart, item) {
    cart.items.push(item);
    let total = 0;
    for (let i = 0; i < cart.items.length; i++) {
        total += cart.items[i].price;
    }
    console.log(`Added ${item.name}. Total is now ${total}.`);
    return total;
}

What are the problems here?

It’s trying to do everything.
It’s hard to read, especially if it grows bigger.
If something breaks, you’ll waste time figuring out which part is the problem.

Now the choice is yours: stick with the messy all-in-one approach or practice the clean one function one job mindset.

⛺ Follow the Boy Scout Rule

Always leave your campsite cleaner than you found it.

Let me break it down for you. You don’t just use something and leave it worse than before. That’s inconsiderate behavior. Real professionals leave things better than they found them.

In coding terms, every time you touch the codebase, make it better. Clean it up, refactor messy parts, and improve readability. If you don’t, you’re just piling on garbage that will eventually collapse on your head.

Here is an example. Instead of improving it, we’re just adding more layers of complexity:

// Original code: Hard to read, poorly named variables
function calc(a, b) {
  let x = a + b;
  let y = x * 0.2;
  return y;
}

// We're adding to it but not cleaning it up
function calcDiscount(a, b, discountRate) {
  let total = calc(a, b);
  let final = total - discountRate;
  return final;
}

After: it gets better every time. Here’s how a disciplined coder works — they improve as they go:

// Improved code: Clear names, refactored for clarity
function calculateSubtotal(price, quantity) {
  return price * quantity;
}

function calculateDiscountedTotal(price, quantity, discountRate) {
  const subtotal = calculateSubtotal(price, quantity);
  const discount = subtotal * discountRate;
  return subtotal - discount;
}

Now, anyone can tell what’s happening at a glance. Because we’ve broken down the code into smaller, more focused functions. Thus, adding new features won’t break existing functionality. 🏕️

🏟️ Follow the Open/Closed Principle

This design principle suggests your code should be designed to allow extensions without changing the existing foundation.

You want to add features — not rip it apart every time you upgrade_._ Modifying old code to fit new requirements is exactly like trying to rebuild your house every time you buy new furniture. It’s not sustainable.

Let’s see how you can build smarter, scalable code that lets you add features without breaking everything else.

Before: Violating the principle

You’ve got a class to handle payments — simple enough. At first, it just handles credit cards.

But then your boss shows up and says, “Hey, now we need PayPal support.”

And because you didn’t bother learning clean code, your code looks like a spaghetti monster straight out of a legacy enterprise system from 1995. Here’s the masterpiece you’ve crafted:

class PaymentProcessor {
  processPayment(paymentType, amount) {
    if (paymentType === "creditCard") {
      console.log(`Processing credit card payment of ${amount}`);
    } else if (paymentType === "paypal") {
      console.log(`Processing PayPal payment of ${amount}`);
    } else {
      throw new Error("Unsupported payment type");
    }
  }
}

const paymentProcessor = new PaymentProcessor();
paymentProcessor.processPayment("creditCard", 100);
paymentProcessor.processPayment("paypal", 200);

Alas! Every new payment type (like Apple Pay, Google Pay, and so on) requires modifying the processPayment method. Needless to say, you risk breaking existing functionality while adding new features. If you had learned this principle, you might not be in this mess.

Don’t worry: I’ll help you to fix this. First, we need to refactor the code. Instead of modifying the existing class, we’ll extend its functionality using polymorphism:

javascriptCopy code// Base class
class PaymentProcessor {
  processPayment(amount) {
    throw new Error("processPayment() must be implemented");
  }
}

// Credit card payment
class CreditCardPayment extends PaymentProcessor {
  processPayment(amount) {
    console.log(`Processing credit card payment of ${amount}`);
  }
}

// PayPal payment
class PayPalPayment extends PaymentProcessor {
  processPayment(amount) {
    console.log(`Processing PayPal payment of ${amount}`);
  }
}

// Adding a new payment type? Just extend the class!
class ApplePayPayment extends PaymentProcessor {
  processPayment(amount) {
    console.log(`Processing Apple Pay payment of ${amount}`);
  }
}

// Usage
const payments = [
  new CreditCardPayment(),
  new PayPalPayment(),
  new ApplePayPayment(),
];

payments.forEach((payment) => payment.processPayment(100));

Now, adding new payment methods doesn’t require changing the existing PaymentProcessor class. You just created a new subclass. So the original code remains untouched, meaning there’s no risk of breaking existing features.

Each payment type has its own class, and adding PayPal payment support, for example, doesn’t break the code. Now you can reply to your boss: “Of course, I will add this feature in 5 minutes.” Your promotion is waiting for you to accept it.

I share even more tips in my book Clean Code Zero to One.

Modern Best Practices to Help You Write Clean Code: A Summary 🥷

Now let me show you the best practices and summarise our 12 Clean Code design principles to help you write clean code for agile application development.

🔎 Common Code Smells and How to Fix Them

💊 Duplication: If you're copying code, you’re creating more work for yourself. Extract it into a function, and do it right.
🛤️ Long methods: If your method needs a scroll bar, it's doing too much. Break it down, keep it focused.
👑 King objects: No class should be doing everything. Simplify responsibilities, or your codebase will become messy.

💬 Effective Commenting Practices

💭 When to comment: Only comment if the code isn't clear. If it is, comments are just clutter.
🫗 Clarity: Comments should tell why, not what. If your code needs explaining, it might be too complex.
🌴 Avoid redundancy: Don't comment what's obvious. If your function is addNumbers, don't comment it does that.

🧼 Refactoring Techniques for Clean Code

🏭 Extract methods: Big methods? Break them down. It's not just about cleanliness –– it's about control.
🫕Rename variables: If your variable names don’t shout their purpose, change and improve them. Precision in naming is precision in thought.
🍃 Simplify conditionals: If your conditionals look like algebra, simplify them. If a == true, just write if(a).

🧪 Testing and Clean Code

🧙 Unit tests: Test every piece of code like you're interrogating a suspect. No stone unturned.
🏇TDD (Test Driven Development): Write tests first. It's not just about catching bugs, it's about knowing exactly what your code should do before you write it.
🧽 Clean tests: Your tests should be as clean as your code. If they're messy, they’re not going to be helpful.

🐛 Error Handling and Clean Code

⁉️ Exceptions: Use them. They're not just for errors, they're also for keeping your code clean from error clutter.
🖍️ Fail fast: If something's wrong, stop right there. Don't let errors add up. Deal with them immediately.
🚨 Logging: Log like you're documenting a crime scene. Clear, precise, and only what's necessary.

🌱 Code Reviews and Clean Code

🚢 Process: Have a system. No cowboy coding. Review, critique, improve.
🔪 Tools: Use tools that make reviews easy. They're not just for catching mistakes, they're also for teaching discipline.
🧦 Culture: Cultivate a culture where feedback is gold. Help your team learn how to handle and receive critiques.

Automated Tools for Maintaining Clean Code ⚓

Tools and automation techniques can be really helpful in writing clean code. If you’re not using the right tools and automating things to save yourself time, you’re missing out.

You think you can "eyeball" your way through code quality? Guess again. Without automation, this is what happens:

👎 You miss obvious mistakes because you're "too busy."
🤕 Your code looks different in every file, making collaboration a headache.
🪦 Deployment breaks because you skipped a critical test.

Successful developers use the right tools to automate code and get things done. Here are four strategies for maintaining clean code using modern tools.

1️⃣ Static Analysis

Static analysis is actually a code inspector that reads through your code and points out potential issues early on. The best part? It works before runtime, catching errors that could otherwise lead to crashes, downtime, or embarrassing bugs.

How does it work?

Syntax checking: It looks at your code to analyze everything written in the correct syntax. If you misspell a variable or forget a closing bracket, it’ll call you out instantly.
Code quality rules: Tools like ESLint enforce rules like consistent indentation, avoiding unused variables, and sticking to best practices.
Error prevention: It identifies logic errors, such as using variables that haven’t been defined, or making comparisons that don’t make sense.

Here’s how static analysis works in action:

🚨 Before static analysis:

let sum = (a, b) => { return a + b; }
console.log(sume(2, 3)); // Typo, unnoticed until runtime

Problem: The typo in sume will only cause an error when the code runs, and that could lead to frustrating debugging sessions or worse — breaking the app in production.

🚑 After static analysis (using ESLint):

codeError: 'sume' is not defined.

Solution: ESLint immediately flags the typo before you even run the code. The error is caught early, saving you time and headaches.

2️⃣ Automated Code Formatting

Before Formatting:

function calculate ( x , y ){ return x+ y;}
console.log( calculate (2,3 ) )

Problem: Inconsistent spacing and formatting make the code harder to read.

After using Prettier:

function calculate(x, y) {
  return x + y;
}
console.log(calculate(2, 3));

Solution: Clean, consistent, and professional formatting is applied automatically. No more nitpicking over spaces or alignment.

Pretty basic stuff though. I covered this in case you write code in notepad or something where IDE is not provided (for example, a job interview).

3️⃣ Continuous Integration (CI) Testing

CI testing make sure every new change to your code is verified automatically. It’s like a safety net that catches bugs introduced during development. CI tools run your tests every time you push code, so nothing breaks after deployment.

How Does CI Testing Work?

Triggers on change: Each time code is committed, the CI tool (like GitHub Actions, Jenkins) runs automated tests.
Feedback: It gives you instant feedback if something fails.
Prevents broken code: Commits only clean, and the working code gets merged into the main branch.

4️⃣ CI/CD pipelines

We also use CI/CD pipelines as a continuous process that includes code building, testing, and deployment, while CI testing is a part of that process that focuses on automating the testing of code changes.

Differece between CI/CD pipelines vs CI testing:

CI/CD pipelines: A CI/CD pipeline combines code building, testing, and deployment into a single process. This process make sure that all changes to the main branch code are releasable to production. CI/CD pipelines can reduce deployment time, decrease costs, and improve team collaboration.
CI testing: CI testing is the process of automatically testing code changes that are integrated into a central repository. CI testing focuses on making sure the codebase is stable and that integration issues are resolved. CI testing help developer build software that is stable, bug-free, and meets functional requirements

🚧 This is what CI testing CI/CD pipelines concepts are really about. Not as complex as it seems. So let me elaborate more on CI testing with GitHub Actions, as we usually run tests through automated tools nowadays.

⚡ Continuous Integration (CI) Testing with GitHub Actions

As I said earlier, CI tools run automated tests every time you push code or open a pull request. This guarantees that only working, bug-free code gets merged into the main branch.

How to Set Up CI Testing with GitHub Actions

Step 1: Create Your Repository

Set up a GitHub repository for your project. Then, push your code to GitHub using the following commands:

git init
git add .
git commit -m "Initial commit for CI Testing"
git branch -M main
git remote add origin https://github.com/codewithshahan/codewithshahan.git
git push -u origin main

Or you can create a new repo from your GitHub account without using the command. Just login to your GItHub account and visit dashboard. Here you will find a “New” button to create a brand new repo:

Step 2: Add a GitHub Actions Workflow

Navigate to your repository’s Actions tab. To do this, first, you have to visit your repo on Github (you will find the link after creating your repo). In this case, I created a new repo called “codewithshahan”. Here, look for the Actions tab on the right side of the navigation bar.

After navigating the Actions tab, scroll down a little and you will find the continuous integration section:

Choose a setup workflow yourself. I will use Node.js for this project.

After clicking the configure button, a node.js.yml file will be created automatically, and you can adjust the code depending on your goals.

I won’t go into detail about how should modify your .yml file. It depends on your project goals and personal preference. Also, it is a whole different broader topic and as this article has already become quite long, so I’ll explain it in a future article. For now, just stick with this foundational knowledge.

This CI Testing workflow is best for modern application development. Your app remains stable while incorporating key features including testing (e,g. Dark Mode), Building and deploying applications directly within your GitHub repository. This way, you can push your code confidently, knowing your code is always clean and ready for production.

The Role of Documentation in Agile Software Development 🚣

If you want your code to be top-notch, you need to understand how to write good documentation. If you think documentation is just about scribbling down how the code works, you’re wrong. It's about explaining why it works, not just how it works. That’s where most people miss the mark.

1. 🚡 Create Useful Docs (Explain Why, Not Just How)

When you write documentation, you're not just throwing down some instructions for how to use the code. You're telling the next person (or even yourself in the future) why this piece of code exists in the first place. That’s the difference between good and bad documentation.

Bad docs leave people scratching their heads. They’re too vague, too simple, and they don’t answer the big questions. If your documentation is unclear, that likely means your thinking is unclear. You’re basically saying, "I don’t care if you understand this, it works, just use it." That’s not helpful.

Great documentation answers the tough questions:

✅ Why did you choose this approach over another?
✅ Why does this function exist? What problem does it solve?
✅ Why did you write this code the way you did?

If your docs are just regurgitating how to use the code, you’re not being as helpful as you can be. Start thinking deeper and explaining the reasoning behind everything.

2. ⏳ Keep the Docs Updated (Outdated Docs Are Worse Than No Docs)

Outdated documentation is the worst. In fact, it can be worse than having no docs at all. When you leave documentation that’s out of sync with the code, you’re doing your future self — or whoever has to deal with it next — a huge disservice.

Every time your code changes, your documentation needs to change too. It has to reflect the current state of things. Don’t mislead future developers (or yourself) by leaving outdated info that will only confuse them and waste their time. If something is no longer relevant, delete it. Outdated documentation is the equivalent of a cluttered mind — it holds you back.

Make it a habit to check and update your documentation regularly. The minute a line of code changes, so should your documentation. Period.

3. 🚆 Integrate Comments (Good Comments in Code Are Part of Documentation)

Here’s the deal — comments in your code should integrate with your documentation. Good comments aren’t just a crutch for developers who can’t explain their code elsewhere. They should improve your docs, not replace them.

Comments are supplements to your documentation. You write clean, understandable code that needs minimal explanation, but when something isn’t crystal clear, throw in a comment. Remember the rule for comments in your code: explain the why, not the how. It’s the same here. Don’t repeat yourself. Let your code do the talking. Comments should complement the bigger picture of your documentation, not act as a band-aid for sloppy code.

🪧 Great code should be self-explanatory. Fix the code, then add comments for clarification if necessary. Keep comments clean, short, and to the point.

If you want to write clean, efficient, and maintainable code, documentation is key. Stop thinking of docs as an afterthought or something you do to fill space. It’s an extension of your code — your way of communicating clearly and effectively. It’s your roadmap for future developers, and it’s a reflection of your thought process.

Conclusion 🏁

Clean code isn't a nice-to-have –– it's a must-have for those who aim to lead. It's about control, efficiency, and improvement over time in the long run. And ultimately, it’ll help you succeed in the game of agile software development.

🪧 If you want to truly master your craftsmanship, write clean code, and let the efficiency speak for itself.

Frequently Asked Questions About Clean Code 🧯

What is clean code? It's code that doesn't make you want to throw your laptop out the window.
Why is clean code important in Agile? Because Agile is about speed and change, and you can't be quick with a mess.
What are code smells? Signs that you're about to lose control of your codebase.
How can I improve commenting? Only comment on what's necessary, and make sure each comment adds value, not noise.

Thank you for being with me. You can visit my Twitter account or my website to read more posts about clean code and Agile application development. Until next time… keep improving your codebase.

If you’re serious about mastering clean code and taking your programming career to the next level, then my book is for you: Clean Code Zero to One. This book is your full guide from zero to one in clean code, from messy code to masterpiece. I am offering a 50% discount using the code "earlybird" — only for the first 50 copies. Plus, there’s a 30-day money-back guarantee — no risk, all reward.

Other Trending Handbooks

Building clean reusable React components 🌱

Programming with Shahan — Sat, 04 Jan 2025 13:40:25 +0000

What are reusable React components? They are independent pieces of code that can be reused throughout your website to save you time and effort.

They can be anything from simple buttons to complex forms. 🦋

🙎 Why Use Clean Reusable Components?

As your website grows, you can easily add new features by combining existing components. This makes your code more scalable and adaptable.

Plus, you can use your clean reusable code in future projects without writing it again from scratch. Any doubt? keep reading...📖

🏭 How to Make Clean Reusable React Components

Here are the two most important things to keep in mind when creating clean reusable React components:

1. 🩼 Avoid Side Effects

Don't put logic that interacts with external data (like making API calls) directly inside a reusable component. Instead, pass this logic as props to the component.

For example, if a button does more than just looking pretty, like fetching data from the internet, it might not be reusable. 👎

🪧 This is a reusable button component. But it lacks best practices.

I will show you why in the example section.

// This is a reusable button component (bad practice!)
const Button = () => {
  return (
    <button> Click Me </button>
  );
}

2. 🗃️ Use Props

Props are arguments you pass to a component to customize its behavior and appearance. This allows you to use the same component for different purposes.

// This is a button component that can change its color
const Button = ({ color }) => {
  return (
    <button style={{ backgroundColor: color }}> Click Here </button>
  );
}

This is still a bad practice because you have a fixed label called "Click Here". If you want to change the text on your button to, let's say: "Sign Up", then you would have to go back to the button component and make that change. 🙎

That means every time you want to use a different text, we'd have to go back and edit the code. In other words, it's NO longer reusable. 🪦

💪 Challenge: So what's the solution?
You already have the answer. But if you don't, I am going to show you in the example section.

🌴 Hint: Think about how you might want to use the component in different situations and design it to be flexible and adaptable.

🍃Examples of Reusable React Components

Here are some common examples of reusable React components, along with some code examples to get you started:

Buttons

Basic buttons with different styles and functionalities.

// Button component
import React from "react";

const Button = ({ color, label, onClick }) => {
  return (
    <button
      className={`padding-2 shadow-none hover:shadow background-light-${color} hover:background-dark-${color}`}
      onClick={onClick}
    >
      {label}
    </button>
  );
};

export default Button;

// Using the Button component
<Button color="blue" label="Click Here" onClick={() => console.log("Button clicked!")} />

As you can see, I did not write "Click Here" in the button component. I want to make my button reusable, and thus it doesn't know anything about custom styles or texts.

So, I passed them as props (i.e., color, label, and onClick) to change them in the future without touching the original button components. Hope that makes it clear.

🪜Solution: You need to pass each functionality as props in the reusable component.

Navbars

Navigation bars that provide consistent navigation across your website.

// Navbar component
import React from "react";

const Navbar = ({ isLoggedIn }) => {
  return (
    <div className="navbar">
      <div className="navbar-container">
        <div className="navbar-logo">
          <img src={logo} alt="logo" />
        </div>
        <div className="navbar-links">
          <a href="/">Home</a>
          <a href="/about">About</a>
          <a href="/contact">Contact</a>
          {isLoggedIn ? (
            <a href="/profile">Profile</a>
          ) : (
            <a href="/login">Login</a>
          )}
        </div>
      </div>
    </div>
  );
};

export default Navbar;

// Using the Navbar component
<Navbar isLoggedIn={true} />

As you can see, I passed <Navbar isLoggedIn={true} />

This line triggers the Navbar component and passes the isLoggedIn prop with a value of true, indicating the user is logged in. This will display the "Profile" link and hide the "Login" link.

Similar to the button component, the Navbar component is reusable and accepts props to customize its behavior. Perfect! 👏

🤙 Why API Calls in a Button Component is a Bad Practice

Now, you understand everything about reusable components in React.

Let's dig deeper by solving a complex problem.

Consider the scenario where you have a button that does an API call. The code for the button component can be the following:

import React from "react"; 
import doAPICall from "../api"

const SaveButton  = () => {
  return (
    <button
      onClick={() => {
        doAPICall();
      }}
    >
      Save
    </button>
  );
}

export default SaveButton

It is quite clear that you can’t reuse the above button in_ multiple_ places as this button component contains a side-effect (doAPICall()) inside it. ⚠️

You can make this component reusable. First, you'll have to extract the side-effect and pass that as a prop to the button component like this:

const App = () =>  {
  function doAPICall() {
    // Does an API call to save the current state of the app.
  }

  return (
    <div>
      <SaveButton onClick={doAPICall}/>
    </div>
  )
}

The button component should look like this:

const SaveButton  = ({
  onClick
}) => {
  return (
    <button
      onClick={onClick}
    >
      Save
    </button>
  );
}

As you can see, the above button can now be reused anywhere you want to save data with the click of a button. The button can now be used like this in multiple places: 🏗️

const App = () =>  {
  function saveUser() {
    // Does an API call to save the user.
  }

  function saveProject() {
    // Does an API call to save the project.
  }

  return (
    <div>
      <SaveButton onClick={saveUser}/>
      <SaveButton onClick={saveProject}/>
    </div>
  )
}

You can also make the button component more reusable by using a prop to control the label:

const App = () =>  {
  function saveUser() {
    // Does an API call to save the user.
  }

  function saveProject() {
    // Does an API call to save the project.
  }

  return (
    <div>
      <SaveButton onClick={saveUser} label="Save user"  />
      <SaveButton onClick={saveProject} label="Save project" />
    </div>
  )
}

The button component should look like this:

const SaveButton  = ({
  onClick,
  label
}) => {
  return (
    <button
      onClick={onClick}
    >
      {label}
    </button>
  );
}

🚨 Early Bird Offer 🚨

If you’re serious about mastering clean code and taking your web development career to the next level, then this book is for you. Grab Clean Code Zero to One today with a 50% discount using the code "earlybird" — only for the first 50 developers! Plus, enjoy a 30-day money-back guarantee — no risk, all reward.

👏 Conclusion

Congratulations! You've successfully learned how to build clean reusable React components.

Remember, reusable components are the building blocks of robust React development. By practicing clean React components, you can build cleaner, more efficient, and more maintainable React applications.

The more you practice, the better you'll become at identifying opportunities to use them in your projects!

📖 Read More: 10 bulletproof rules for writing clean code

Thank you for taking the time to read this article. Until next time.. Keep learning and you can follow me on 𝕏 for the latest updates on programming and clean code.

The future of frontend development (2025)

Programming with Shahan — Tue, 31 Dec 2024 15:08:19 +0000

The environment of front-end development is CHANGING dramatically.

Thanks to technological developments, artificial intelligence (AI), and the growth of no-code/low-code platforms.

Let's look at the new trends and examine the future of frontend developers.

🤖 Machine Learning (AI)

One popular concern in the technology world is whether artificial intelligence (AI) will replace front-end developers over the next decade.

The answer is simple: No. AI won’t replace you, but it will replace those who fail to adapt.

AI is actually changing the way we work. Tools like GitHub Copilot, CodeGeeX, and Figma’s FigJam AI are automating repetitive tasks, such as writing boilerplate code or generating designs.

Here’s the truth:

👀 AI isn’t here to steal your job; it’s here to amplify your capabilities.
⌛ It saves up your time for creative, high-impact tasks that AI can’t handle.

Sam Altman, CEO of OpenAI, said it best:

“If AI can do most jobs better than humans, we need to figure out how to share those resources so everyone has a good life.”

😨 Concerns About Losing Your Job?
While AI and automation are expected to impact certain aspects of front-end development, the fear of job displacement is largely unfounded.

AI is a tool, and its effectiveness depends on the person using it.

Developers who use AI creatively and make the most of its potential will be in the new era of innovation. They can hold a stable and dynamic career.

💼📈 Job Outlook and Opportunities

Frontend developers are still in high demand in 2025. The numbers speak for themselves.

Here are some average salaries for front-end developers based on their job titles in the USA:

🤳 Mobile Applications Developer: $99,257/year
🧑‍💼 Web Application Developer: $85,840/year
🧑‍✈️ Software Developer: $87,521/year
👨‍🔬 Lead Web Developer: $108,800/year

(Source: Zippia)

Front-end developers make $44.3 an hour on average, with the finance sector paying the highest wages for these professionals.

What does this mean for you?
If you keep up with the latest coding techniques, frameworks, and trends, your earning potential will only grow.

🪴 No-Code/Low-Code Platforms

Platforms like Webflow, Bubble, and Squarespace are allowing non-developers to create functional websites without writing a single line of code.😨

Wait a minute...does this mean frontend development is dead?

Absolutely NOT.

Here’s why:

🔫 These platforms are tools, NOT replacements. They simplify basic tasks, but they can’t handle complex, custom-built systems.
🦸‍♂️ As a developer, you’ll still be needed to build efficient scalable and maintainable applications by following Clean Code principles

In fact, knowing HOW to integrate no-code/low-code tools into your workflow will make you even more valuable.

🌱 Writing Clean Code

Messy code = wasted time and broken projects.
Clean code = scalable, maintainable software.

Let’s be honest—AI and automation are making it easier to write code, but they’re also making it easier to write messy, unmanageable code.

If you don’t know how to write clean code:

🤦 You’ll spend hours fixing bugs and refactoring.
🩼 Your projects will break under the weight of complexity
💔 Your development organization will be at its knees
🤜 or even getting rejected in the job interview

Clean code isn’t an optional. It’s the foundation of building scalable, maintainable software.

“The only way to make the deadline — the only way to go fast — is to keep the code as clean as possible at all times. Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way ” — Uncle Bob

That’s why I wrote Clean Code Zero to One—a beautifully design, very easy-to-understand textbook to master clean code principles that no one has ever written like this before (thousands of digital illustrations and real-world graphical examples).

🐦 Early Birds Sell: 50% OFF

Start your 2025 with the most valuable skills you need: learning how to write Clean Code first.

That literally separates amateur developers from true professionals.

👏 Conclusion

The future of front-end development is bright, but only for those willing to adjust their skills. Use AI as an improvement but not as a liability. And most importantly, learn to write clean, maintainable code that AI can't handle

Your career doesn’t depend on how fast you code — it depends on how well you code.

Front-end developers need to adapt to these developments and keep learning new skills in order to remain competitive in a field that offers creativity and flexibility.

Overall, front-end developers are in high demand, and those who can adjust to the changing market will have many chances to succeed in the years to come.

Thanks for taking the time to read this article.

Stay tuned for more valuable content, and if you ever wondered why we need to learn Clean Code first? You can look at this article: Clean Code Zero to One

10 Bulletproof Rules for Writing Clean Code 🔥

Programming with Shahan — Fri, 27 Dec 2024 15:49:32 +0000

If you're in a messy room, you can’t find your keys. Clothes everywhere, books piled up.

That applied to messy code. It’s the SAME disaster, except now it’s your brain that’s LOSING its energy.

Clean code, on the other hand, is like walking into a spotless room. Everything is exactly where it should be. No stress. No confusion. Just clarity.

Here’s the truth: writing clean code is NOT optional if you want to survive in software development. AI already writes cleaner code than you.

Fortunately, as the best creation on earth, we human beings are able to master clean code.

You can write messy code and be the person who struggles to fix every bug, getting rejected from the job interview and failing to build a manageable startup, or you can master clean code and DOMINATE every project you touch.

Clean Coder vs. Messy Coder

Here’s a graph that shows the journey of two types of coders:

⚠️ Bad Coder (Red line): Starts fast but crashes hard. The more lines they write, the more trouble they make.
⚡ Clean Code (Blue line): Starts slow but stays consistent. Growth doesn’t stop—it accelerates.

🫵 Now, you decide which line you want to follow.

🐦 Early Bird Sells: 50% OFF 🚨

If you’re serious about mastering clean code and taking your programming career to the next level, then this book is for you: Clean Code Zero to One. I am offering 50% discount using the code "earlybird" — only for the first 50 copies! Plus, enjoy a 30-day money-back guarantee — no risk, all reward. Or KEEP struggling with your buggy code. I can't visit your desk to fix it for you.

Cost of Bad Code

To demonstrate this chart, in the initial development phase, bad code is slightly more costly to change than clean code.

However, as we move to the maintenance and refactoring phases, the gap widens SIGNIFICANTLY, with bad code costing nearly TWICE as much as clean code.

By the legacy phase, bad code reaches 100% cost, now its EXTREMELY expensive to update, while clean code remains more manageable at 45%.

No doubt, bad code is a COSTLY problem in software development.

10 Bulletproof Rules for Writing Clean Code

1. Use Names That Mean Something

Naming your variables or functions b or x is a crime. Call them what they are.

// Weak and vague
let b = 5;

// Strong and clear
let numberOfUsers = 5;

People who write unclear names DON'T want to own their mistakes. Don’t be that person.

2. Keep Functions Laser-Focused (SRP)

A function should do one thing—and do it perfectly. This is called the Single Responsibility Principle (SRP).

Good code is like a hammer. It hits ONE nail, not ten.

// Clean: One job, one focus
function calculateTotal(a, b) {
    return a + b;
}

function logTotal(user, total) {
    console.log(`User: ${user}, Total: ${total}`);
}

// Dirty: Trying to do EVERYTHING
function calculateAndLogTotal(a, b, user) {
    let total = a + b;
    console.log(`User: ${user}, Total: ${total}`);
}

When you mix tasks, you mix CONFUSION with disaster.

3. Silent Comments

You don’t explain what a door does EVERY time someone walks into a room. Your code should work the same way.

// Clean: Self-explanatory
let userAge = 25;

// Messy: Needs an explanation
let a; // This means "age of the user"

Comments aren’t bad, but if your code can’t stand on its own, you’ve already failed.

4. Make Your Code Readable

If someone reading your code feels like they’re solving a riddle, you ALREADY became a troublemaker.

// Clean: Reads like a story
if (isLoggedIn) {
    console.log("Welcome!");
} else {
    console.log("Please log in.");
}

// Messy: Feels like chaos
if(isLoggedIn){console.log("Welcome!");}else{console.log("Please log in.");}

Readable code isn’t just for others—it’s for you six months from now.

5. Test Everything You Write

If you’re too lazy to write tests, DON'T complain when your code breaks.

class Calculator {
    add(a, b) { return a + b; }
    subtract(a, b) { return a - b; }
}

// Test it (Unit Test)
const calculator = new Calculator();
console.assert(calculator.add(2, 3) === 5, "Addition failed");
console.assert(calculator.subtract(5, 3) === 2, "Subtraction failed");

Tests are your insurance policy. Ignore them, and you’re gambling with your time.

6. Beware of Dependencies

Dependencies are like DEALS. Get the RIGHT ones, and you WIN. Choose badly, and you’re locked into something you’ll regret.

// Dependency: Sending emails with Nodemailer
const nodemailer = require('nodemailer');
function sendEmail(to, subject, message) {
    const transporter = nodemailer.createTransport({ /* config */ });
    return transporter.sendMail({ from: "you@example.com", to, subject, text: message });
}

Avoid hardcoding dependencies. Use abstraction or configuration files for secure maintenance.

This is just one example. As a developer, you may use HUNDREDS of libraries or dependencies.

I am not saying you should not rely on them, nowadays it is hard to avoid them. But you should be very careful BEFORE installing them in your coding projects.

You should check the security, performance, quality or functionality of an organization's software systems. Because they sometimes contain risks that can ruin your ENTIRE project.

Always CONTROL your tools, don't let them control YOU.

7. Organize Project Like a Boss

A well-organized project is the difference between a garage sale and a high-end boutique.

Here is how EACH folder should be organized:

If your codebase looks like a junk drawer, you’ve already lost the respect of your future self.

An Email App's Clean Project Structure:
Let's say you are building an application that sends emails to users. Your clean project structure should look like this:

8. Be Consistent with Formatting

Don’t code like a person with 10 personalities. Be consistent with your formatting.

Use tools like Prettier or ESLint to enforce your CONSISTENT style. If every file looks different, you’re creating chaos that NO ONE wants to fix.

I would say, consistency in formatting is one of the most important aspects of clean coding.

Have a look...

Use 2 or 4 spaces for indentation consistently throughout your codebase. Avoid tabs to maintain uniformity across different editors.

Keep lines to a maximum of 100-120 characters to prevent horizontal scrolling and improve readability.

Group related logic together and separate blocks of code with blank lines to highlight their purpose.

Finally, avoid over-aligning code; instead, let indentation naturally guide the flow of logic.

9. Stop Hardcoding Values

Hardcoding is laziness disguised as effort.

// Bad: Hardcoded and rigid
function createUser() {
    const maxUsers = 100;
    if (currentUsers >= maxUsers) throw "Too many users!";
}

// Clean: Dynamic and flexible
const MAX_USERS = 100;
function createUser() {
    if (currentUsers >= MAX_USERS) throw "Too many users!";
}

So, avoid it at all costs. Hardcoding is the shortcut that sends you off a cliff.

10. Keep Functions Short

If your function is longer than 20 lines, it’s probably trying to do too much. Break it down.

function updateCart(cart, item) {
    addItemToCart(cart, item);
    let total = calculateTotal(cart);
    logTransaction(item, total);
    return total;
}

function addItemToCart(cart, item) {
    cart.items.push(item);
}

Short functions are sharp functions. They hit their mark EVERY time.

Master the art of programming!

Programming with Shahan — Thu, 26 Dec 2024 09:17:45 +0000

Programming with Shahan

Dec 26 '24

Clean Code Zero to One

#webdev #javascript #programming #beginners

Comments 8

3 min read

Clean Code Zero to One

Programming with Shahan — Thu, 26 Dec 2024 08:30:58 +0000

When you get stuck writing code, you might TURN to AI.

But let me tell you something.

AI can’t SAVE you if your code is a MESS.

It’s like building a house on sand.

Sure, it stands for a WHILE, but one gust of wind, and it collapses.

AI is just a tool.

If you don’t know HOW to write clean, manageable code, you’re wasting your time and let the AI take your job.

Please don't teach your children AI first, teach them HOW to learn CLEAN CODE first. Don't let their beautiful creative mind die in the garbage robotics world. We're life. We're the highest creation on earth.

You think knowing a programming language and building a website makes you a programmer?

If you can't maintain the code you wrote, you’re NO better than someone who made vaccines and unfortunately vaccines KILLED them.

There’s no difference between the person eating bugs and the one writing them—they both thrive in chaos.

I’ve seen it over and over again.

Developers who know five programming languages.

They can build apps, websites, software.

They know algorithms and data structures like the back of their hand.

But when faced with a LARGE project, they crumble.

They’re like pilots who design their own planes but don't know HOW TO FLY them.

They CRASH into their OWN creation.

That was ME... once.

I’d write thousands of lines of code, only to realize I couldn’t EVEN understand what I wrote LAST week.

It was chaos for me.

But then it hit me—EVERY developer struggles with this.

I decided to ESCAPE this trap. I had to unlearn what I learned and make a fresh start.

By the grace of God, after five months of intense work, — four to five hours a day writing, designing, and researching — I created something I wish I had when I started learning programming.

A book.

A guide.

An un-learn to re-learn.

Clean Code Zero to One.

This isn’t just another book about coding.

It’s built on Robert C. Martin’s (Uncle Bob) Clean Code principles and modern best clean code practices, but with a twist.

Thousands of digital illustrations. Every word, every concept, every chapter is so easy to understand.

Graphical examples that feel alive.

This book doesn’t just teach clean coding; it immerses you in it.

It takes you out of the confusion and places you in real-world scenarios where clean code thrives.

NO ONE has written a book like this in the clean software development field after Martin.

WHY?

Because it takes enormous research.

Because it takes time and the ability to demonstrate in the best way.

And because most people aren’t willing to put in the effort.

But I DID.

Every line of code we write reflects how we think — not just about the problem at hand but about programming as an art.

ANYONE can write code (zero).

Even AI.

But only THOSE who write clean, maintainable code (one) will survive in the software development jobs.

This book is your FULL guide from zero to one in Clean Code.

It’s more than a textbook — it’s your pathway to land your dream job.

It’s a chance to write code you can be proud of and to join the few who TRULY understand what clean code means.

After finishing this book you will NEVER write premature code in any programming language ... again.

Because now you know the foundation. You are now the architect itself. Not a builder.

Start your 2025 with the most valuable skills you need: learning how to write Clean Code first.

That literally separates amateur developers from true professionals.

Get Clean Code Zero to One to master this valuable skill and save 20% with the promo code: HAPPYNEWYEAR.

🎁 Claim your copy:

https://codewithshahan.gumroad.com/l/cleancode-zero-to-one

🕒 Offer valid until January 14, 2025.

or KEEP struggling with your garbage code. The choice is yours.

Add Passwordless Facial Authentication on Your Website! (FACEIO)

Programming with Shahan — Fri, 25 Oct 2024 11:03:25 +0000

What is FaceIO, and Why Use It? 🤳

FaceIO is a service that allows websites and apps to recognize a person by their face using a webcam.

Instead of typing a password or using a fingerprint, users can just look at the camera, and the app can confirm who they are.

This is helpful because:

⚡ It's faster than typing passwords.
🔐 It's more secure because only the person with that face can access the app.
🧠 Users don’t need to remember complicated passwords.

Learn more on FaceIO’s documentation about why facial recognition with FaceIO is a go-to method for developers.

How FaceIO Works 🔮

There are two main actions with FaceIO:

⛳ Enrolling a User: This means recording the user’s face for the first time.
🪪 Authenticating a User: This means checking if the person in front of the camera is the same as the person who enrolled earlier.

Setting Up FaceIO on a Web Page 🏗️

To use FaceIO, you need to add their JavaScript library (a special code that does the face detection) to your website. Here's how you do it:

1. Include the Script:
Add a script tag in your HTML file that points to FaceIO’s library:

   <script src="https://cdn.faceio.net/fio.js"></script>

🫗 This script allows your website to use FaceIO's features.

Visit FaceIO’s NPM page to explore the package and get updates on installation details.

2. Create Buttons for Enroll and Authenticate:
In your HTML, add two buttons:

   <button onclick="enrollNewUser()">Enroll New User</button>
   <button onclick="authenticateUser()">Authenticate User</button>

🪤 When a user clicks these buttons, they will either enroll (save their face) or authenticate (check their face).

Enrolling a User 👤

The process of saving a new user’s face is called enrolling. Here’s the JavaScript code for it:

function enrollNewUser() {
    const faceio = new faceIO("app-public-id"); // Replace with your app's ID

    faceio.enroll({
        locale: "en", // This sets the language to English
        payload: {
            email: "user@example.com" // Link this user's email or any other unique ID
        }
    }).then(userInfo => {
        console.log("User enrolled successfully!");
        console.log("User ID: " + userInfo.facialId);
        console.log("Enrollment Date: " + userInfo.timestamp);
        alert("Enrollment successful! Welcome, user.");
    }).catch(err => {
        handleError(err);
    });
}

🤷‍♂️ What Does This Code Do?

It calls the enroll() function from FaceIO to start the process.
locale means the language that the user prefers.
payload is extra information about the user (like their email or ID).
If it works, it shows a message saying "Enrollment successful!" and logs details like the user's ID and the date.
If it doesn’t work, it calls the handleError() function to check what went wrong.

Authenticating a User 🤐

This is how you check if a user is who they say they are using their face:

function authenticateUser() {
    const faceio = new faceIO("app-public-id"); // Replace with your app's ID

    faceio.authenticate({
        locale: "en"
    }).then(userInfo => {
        console.log("User authenticated!");
        console.log("User ID: " + userInfo.facialId);
        alert("Authentication successful! Welcome back.");
    }).catch(err => {
        handleError(err);
    });
}

🤷‍♂️ What Does This Code Do?

It uses the authenticate() method from FaceIO.
If successful, it logs a message and welcomes the user back.
If not, it calls handleError() to understand the problem.

To get the API key (also known as the **App Public ID) in FaceIO, follow these simple steps:**

Sign Up for FaceIO:
- Go to the FaceIO website and sign up for an account if you don’t have one yet.
- Log in with your new account.
Create a New Application:
- Once logged in, go to the Dashboard.
- Click on "Create New Application".
- Fill in the required details like your app name and description, and then click "Create".

Find the App Public ID:
- After creating the app, you’ll see it listed on your "Applications" section on your dashboard.
- Here, you’ll find your App Public ID. This is the API key you will use in your JavaScript code to connect your website with FaceIO.
Copy the App Public ID:
- Click the copy icon next to the App Public ID to copy it.
- Now, you can paste this key into your code where it says "app-public-id".

Example: Replace "app-public-id" in the JavaScript code with your actual App Public ID:

const faceio = new faceIO("your-unique-ID inside this quotation");

Now, your app is connected to FaceIO and ready to use facial recognition features!

Security Features and Privacy Best Practices 🔒

FaceIO emphasizes security with features such as multi-factor authentication, data encryption, and access management. For more on the security standards, visit FaceIO Security Best Practices.

FaceIO’s approach to privacy includes secure storage and minimal data handling. Read more on how FaceIO protects user data here: Privacy Best Practices for Applications.

Handling Errors 🏇

Not everything goes smoothly all the time, so we need to handle errors when they occur. Here’s a function that does that:

function handleError(errCode) {
    switch (errCode) {
        case "PERMISSION_REFUSED":
            console.log("You didn't allow access to the camera.");
            break;
        case "NO_FACES_DETECTED":
            console.log("No faces detected. Make sure your face is in the frame.");
            break;
        case "UNRECOGNIZED_FACE":
            console.log("This face doesn't match any user we know.");
            break;
        case "MANY_FACES":
            console.log("Please make sure only one face is in front of the camera.");
            break;
        case "TIMEOUT":
            console.log("The operation took too long. Please try again.");
            break;
        default:
            console.log("An unknown error occurred.");
    }
}

Why Does FaceIO Need an HTTP Server? 🤔

You might wonder why this code needs to run on a server instead of just opening it as a regular file in your browser. Here’s why:

🧑‍💻 JavaScript and Security:
- JavaScript code runs in your browser (client-side). But for security reasons, it can’t talk directly to a server that’s not the one it came from.
- This is called the same-origin policy. It keeps your data safe from being accessed by websites that you didn't open.
🗃️ FaceIO Needs to Talk to Its Server:
- When you enroll or authenticate a face, the FaceIO library sends information to their server to compare or save data.
- To do this safely, it must come from a proper web address (like http://yourwebsite.com) and not just a local file on your computer.

Managing Your App with the FaceIO Console 🥣

FaceIO offers a web-based Application Manager. This is like a dashboard where you can control everything about your app:

👤 User Management: Add, edit, or delete users.
👥 Group Management: Put users in groups to manage them better.
🎐 Permission Management: Decide who can do what in your app.
📏 Monitoring Analytics: Check how many users are using your app and how they interact with it.
🪠 Security Features: Use things like multi-factor authentication to make your app safer.

Join the FaceIO community forum to connect with others and ask questions.

Recap of Key Points ♻️

FaceIO helps websites recognize users using facial recognition, making login faster and more secure.
To use FaceIO, you need to include their JavaScript library, create buttons, and set up the functions for enrolling and authenticating users.
Error handling is important to guide users when something goes wrong.
An HTTP server is needed to bypass browser security rules and communicate properly with FaceIO's servers.
The Application Manager helps you control users, settings, and security.

I hope this explanation was helpful! It covers everything from how FaceIO works to setting it up and managing it. Let me know if you have any more questions!

DEV Community: Programming with Shahan

10 hard truths EVERY DEV must learn in 2025

1. Looks help but they’re not everything.

2. If you’re always chasing, you’re not in control.

3. Your purpose is more attractive than your tools.

4. I’ve learned to stop coding so much.

5. Your past code matters.

6. Not every tool is worth your time.

7. The less you rely, the better things go.

8. Being a “yes developer” doesn’t work.

9. Comments are cool, but clarity is better.

10. Your project should add to your life, not be your life.

How to land your first frontend job (11 Rules!)

📽️ 1. Not building projects

🍽️ 2. Choose Your Learning Resources Wisely

🪛 3. Start with the Basics

🐣 4. Begin with Easy Projects

🚤 5. Take Your Time to Learn

🎐 6. Regular Practice Is Good, But Don’t Overdo It

🥞/🍋 7. Stuck on Something? Take a Break

⛷️ 8. Learn by Doing

📜 9. Plan Your Projects

🏎️ 10. Focus on Quality, Not Speed

🧘‍♂️ 11. Be Patient with Your Learning

🏁. Conclusion

9 frontend devs mistakes

1. 🤧 NOT Optimizing Images

🪨🔨 How to Optimize Images Using Node.js?

2. 🥸 Using Inline Styles

3. 🎭 Using Inadequate Heading Tags

4. ❌📲 Ignoring Mobile Media Queries

5. 🪟 Not Benefitting from Flexbox or CSS Grid

6. 🗂️ Not Abstracting Elements

7. 🧹 NOT Removing Redundant Styles

8. 🏯 Uppercasing Things in HTML

9. 💎 NOT Focusing on QUALITY

🏁. Conclusion

Which JavaScript framework is best (React or Vue in 2025?)

⚖️ Framework Overview

🍏 Reasons for Using Vue.js

⚛️ Reasons for Using React

🥇 Comparison of Popularity and Performance

🧊 Scalability

📲 Adjust to Mobile Devices

🚎🔩 Size and Community Support

🏒 Use Cases

🏇 Recommendation: Clean Code Book (2025)

👏 Conclusion

Code Optimization for Game Development

Effective Strategies for Performance Optimization

Rule 1: Memory Management

Strategy #1: Memory Pooling

Strategy #2. Data Structure Optimization

Strategy #3. Memory Profiling

Rule 2: Asset Streaming (Load Only What You Need)

Strategy #1: Segment and Prioritize

Strategy #2: Asynchronous Loading (No Waiting Allowed)

Strategy 3: Level of Detail (LOD) Systems – Be Smart About Quality

🧳To Summarize

Rule 3: Frame Rate Stabilization

Rule 4: GPU and CPU Optimization

👏 Conclusion

How to Write Better Code for Agile Software Development (Handbook)

The Cost of Bad Code

Clean Coder vs. Messy Coder

12 Clean Code Design Patterns for Building Agile Applications ⚖️

🌿 Use Names That Mean Something

🔨 Keep Functions Laser-Focused (SRP)

🚪 Use Comments Thoughtfully

⚡ Best Practices for Writing Good Comments

🧩 Make Your Code Readable

🏌️ Test Everything You Write

💉 Use Dependency Injection

📂 Clean Project Structures

5. tests

🤹‍♂️ Be Consistent with Formatting

1️⃣ Consistent Indentation

2️⃣ Meaningful Whitespace: Giving Code Room to Breathe

3️⃣ Clear Separation of Logic: Modular Thinking

4️⃣ Readable Error Handling

5. `tests`