DEV Community: Programming with Shahan

How to learn to code in 2026 (dev job market is insane!)

Programming with Shahan — Wed, 22 Apr 2026 10:06:35 +0000

Learning to code in 2026 is not what it used to be.

And if you still think it is

You are already behind.

And the way you become a developer?

It's completely different.

You may ask: "should I even learn to code in 2026?"

Yes.

100% yes.

Because some people think AI replaced programmers.

It didn’t.

It removed bad programmers.

And increased demand for REAL BUILDERS.

This is still one of the highest-leverage skills.

Plus the software engineer (SWE) job market is picking up in 2026.

SignalFire reported that firms like Meta, Netflix, Uber, and Google are hiring engineers FASTER than people are leaving:

The US Bureau of Labor Statistics still expects software developer jobs to grow by about 15%, which is way faster than most other careers:

Moreover, 72% of organizations outsource software development to achieve better access to talent [32%], meet increasing customer demands more efficiently [35%], optimize spending [34%], and improve quality or performance [33%]:

Meanwhile, Python is the most sought-after programming language, with 45.7% of recruiters seeking candidates with Python skills, followed by JavaScript [41.5%], Java [39.5%], TypeScript [27.9%], and C# [24.4%].

according to devjobsscanner Python is the most in-demand language as of January 2026 with 43,300+ posted job openings:

AND

Gartner predicts that by 2027, 80% of the engineering workforce will need to upskill to keep pace with generative AI.

so if you can code in 2026 you certainly can

📲 build complex application
😴 automate your entire projects
💼 land your dream job
🦮 and instruct AI instead of being replaced by it

The good news is: learning to code today is much easier than ever before.

So in this article, I will show you:

1. 🍱 what coding looks like now in 2026
2. 🏫 what you MUST learn for the future
3. ⚡ AND how to speed up your learning massively

Let's jump in.

💊TABLE OF CONTENTS:

FIRST: Why "Vibe coding" to "Agentic Engineering" shift happened?
🍼 STEP 1: Coding Fundamentals (non-negotiable)
- Language choice
🍌 STEP 2: Software Architecture
🧪 STEP 3: Testing
🛫 STEP 4: Deployment
🛩️🎮 STEP 5: Version Control
🔐 STEP 6: Security & Privacy
🚢 STEP 7: Microservices & Containers
💪 NOW you are ready for AI coding
- ⚡ The new coding shift: Agentic Engineering
🧠 How to learn code faster
- 🤔 1. Use AI to THINK, not just code
- 🔍 2. Reverse engineer code
- 🏗️ 3. Projects = everything
- 🧠 4. Ask AI for multiple solutions
- 📄 5. Documentation shortcut
📚 Recommendation
🧭 Final thoughts

FIRST: Why "Vibe coding" to "Agentic Engineering" shift happened?

In 2025, Andrej Karpathy introduced something called

👉 “Vibe coding”

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

It meant

🤖 you talk to AI
🍎 you let it generate code
🥱 you don’t care about details

It worked for small projects.

It was fun.

But it was never serious engineering.

Then things changed in 2026.

By 2026, a new workflow became normal:

👉 Agentic Engineering

This hits different.

Now you don’t just “talk to AI”

You:

🤹 manage AI coding agents
🏗️ structure systems
🦮 guide architecture
🪸 correct mistakes
🛫 control outputs like a system designer

You are no longer a coder.

You are now a Chief of Commander of machine.

But here’s the trap:

You can’t command what you don’t understand.

So fundamentals still rule everything.

🍼 STEP 1: Coding Fundamentals (non-negotiable)

Before AI, coding fundamentals was everything.

Now?

Still everything.

You must learn:

[variables]
[data types]
conditions (if/else)
loops
[functions]
object-oriented programming
APIs
privacy & security
clean code

Because if you cannot read, scale or maintain code

You CAN'T control AI-generated code.

You become dependent.

Your software becomes useless.

Language choice

You should pick only one tech field first and go deep.

To begin with:

learn Python for AI, automation, data systems

learn JavaScript for web/mobile apps, frontend/backend

Pick ONE. Don’t jump.

🍌 STEP 2: Software Architecture

This is where beginners quit.

And professionals are built.

You must understand:

how software is structured
how systems are designed (clean code)
how tech stacks are chosen
how APIs connect systems
how data flows
where data is stored (databases)

Now think: you want to build an app.

You must answer these questions:

Where does data go?
How does it scale?
How do users interact with it?
How fast is it under load?

These are NOT coding questions.

These are engineering decisions

And AI cannot reliably decide them for you.

🧪 STEP 3: Testing

AI can write code.

But AI also makes mistakes silently.

That’s dangerous.

So you must learn:

🍽️ how to write test cases
🍳 how to verify logic
🪠 how to validate features
🫗 how to catch failures early

Concretely, without testing you are guessing.

With testing:

You are controlling your output.

🛫 STEP 4: Deployment

Code that ONLY runs locally is useless.

learn:

🪂 how to host applications
🗼 how servers work
🪟 how environments are structured
🪈 how deployment pipelines function

Job recruiters often ask about it.

You must ship to create history.

You must understand and explain WHY things does/doesn't work.

🛩️🎮 STEP 5: Version Control

Version control (e,g. Git) is not optional. Its the baseline.

You need it even if AI is knocking on your door.

Learn what version control does and master the most useful commands.

You will thank me later.

Now in AI-driven coding

This becomes even more important.

Because AI can break your project while you blink.

Git or version control system will help you tackle it.

🔐 STEP 6: Security & Privacy

This is where AI fails the most.

AI acts as a child to "security and privacy"

And that's where beginners get destroyed without knowing.

So learn

🥷 authentication
👨‍🦯‍➡️ authorization
🛟 data safety
🗝️ secure APIs
🔏 secret management

AI does NOT care about security unless you force it to.

And real engineers know this:

"Paranoia is not fear. it is protection."

Which means build a proactive security-first mindset where you assume threats exist and systems will fail.

🚢 STEP 7: Microservices & Containers

This is advanced.

But important.

You should learn:

-0 how applications are packaged
-01 how dependencies are bundled
-02 how systems run in isolation
-04 how environments stay consistent

Why does this matter now?

Because AI agents can break your projects, break environments and create unpredictable setups

Containers (e.g., Docker) protect you from drowning.

💪 NOW you are ready for AI coding

Only after all this…

You use AI properly.

But as a tool.

Now you can

📢 direct AI agents
🍔 build systems faster
🤜 correct mistakes
🏠 design architecture

⚡ The new coding shift: Agentic Engineering

Now coding looks like this:

You open your machine.

Multiple AI agents working:

One builds backend. One writes tests. One handles docs

You assign tasks, correct mistakes, guide structure, AND enforce logic.

This is not coding anymore.

This is agentic engineering.

Make sure to learn it early.

🧠 How to learn code faster

Most people fail here because they consume too much content.

or learn but never build

Before, it took 2–5 years to become solid developer

Now ~6 months if you are focused.

Because tools will multiply your output.

So here is the solid strategy to learn code faster:

🤔 1. Use AI to THINK, not just code

Don’t ask:

“write code”

Ask:

"explain this"
"break it down"
"give analogies"
"show mistakes"

🔍 2. Reverse engineer code

Take real projects.

Then: break them, modify them and ask AI to explain them

That is actual serious learning.

🏗️ 3. Projects = everything

No projects = no skill.

You must:

☑️ build APIs
☑️ build apps
☑️ build features
☑️ break and fix things

That’s how neural memory forms.

Reading or watching tutorials is another word for procrastination.

🧠 4. Ask AI for multiple solutions

NEVER accept one answer.

Ask:

“give me 3 approaches”

this way you'll learn: tradeoffs. efficiency. structure

📄 5. Documentation shortcut

Nobody likes reading documentation.

Don’t struggle through docs.

Use AI to translate them.

But still understand them.

📚 Recommendation

If you want a clean, structured path:

📘 My Clean Code Zero to One book is for you:

After reading this book you'll think like a system designer. Write clean architecture. Scale and maintain your application and avoid beginner's mistakes.

🧭 Final thoughts

Coding in 2026 is easy.

BUT its not "too easy" as 63% of non-developers so called "vibe coders" think. They all face the reality when seriously get involved in buidling softwares.

either you learn fundamentals

Or you skip fundamentals and get replaced.

There is no middle.

Now open your code editor and build something cool from scratch! 🥂

You can follow me on LinkedIn. Thanks.

learn these 12 git commands and forget

Programming with Shahan — Fri, 17 Apr 2026 22:31:10 +0000

🌱 Introduction

Most devs think they can vibe code with a few Git commands.
They run git add ., "push commit" … and start acting like they built Linux.

I’ve seen the opposite.

they trust AI agents and then the project turns into something nobody wants to touch.

I’ve done that too, early on.

The difference is that you eventually get tired of fixing avoidable problems. That’s when Git stops being a checklist of commands and starts becoming a way of working.

These 12 git commands I actually rely on when things get messy or when I want to keep things clean from the start.

now lets get started.

🎂 1) Rebasing

AI code reviewers and merge queues DO NOT babysit premature branches.

They expect discipline.

most so called git expert stack commits like this:

fix
fix again
testing
oops
final-final-v3

Then they open a PR (pull request) and hope it works.

Unfortunately it doesn’t.

🍄‍🟫 What rebase actually is

Look at the image.

Bottom = old commits
Top = latest main
Dog = your feature branch

Right now your branch is behind.

The dog is sitting somewhere in the middle.

But he wants the top.

So what does he do?

He cLimbs.

Step by step.

And then he sits on top of the latest main.

That’s rebase.

You don’t build sideways.
You don’t stay behind.

You move your work to the top.

Clean. Straight. Done.

🤔 You ask why?

Look, modern teams use AI merge queues, automated reviewers, async PR pipelines.

These systems are NOT your mother.

THey don’t review your failure.

AI pipelines don’t fix your alienated history.

They see this:

random commits
unclear changes
outdated branch

🙅‍♂️ And they reject it.

Not because you’re bad.

Because your git history is turmoil. 🧐🌡️

WitH rebase you fix everything before PR.

Now merge is simple.

🍨 Rebase workflow

This is what you actually do:

git switch feature-login
git fetch origin
git rebase origin/main

git add .
git rebase --continue

git push --force-with-lease

🏗️ Code demonstrations for beginners:

1) 🧗‍♂️ Switch to your feature branch = git switch feature-login

You move into your own work area.

2) ⛅ Get latest updates from remote = git fetch origin

You look at what changed on the server using fetch.

3) 🛟 Rebuild your work on top of latest main = git rebase origin/main

This is the core moment.

Git takes your commits and replays them one by one on top of the newest main.

So instead of:

messy branch history
outdated base

You now get:

clean linear history
same work, new foundation

If conflicts happen, Git stops here.

4) 🚤 Fix conflicts (if any)

git add .
git rebase --continue

This means:

you fix the files
you tell Git: “okay continue”

Git keeps replaying your commits until everything is applied.

5) Push updated history = git push --force-with-lease

Important part:

You are not just pushing code.

You are rewriting history.

So Git says:

“Only push if nobody else changed this branch while you were working.”

That’s what --force-with-lease protects you from.

It checks if someone else updated the branch.

If yes, it stops you.

So you don’t destroy their work.

again, rebase changes history.

That’s why you don’t just --force push blindly.

🪦 2) Reset, Revert, Restore

Mistakes will happen.

That’s normal.

Panicking is optional.

Some developers break things… then freeze.

Others fix it in 10 seconds and move on.

Read Clean Code Zero to One and become like them.

The difference is knowing which command to use.

Git gives you three weapons to reverse damage:

git revert HEAD 
git reset --hard HEAD~1
git restore --staged app.js
git restore app.js

[ code demonstration is below ]

1) 🦺 git revert | safe undo

You don’t delete anything.

git revert HEAD = Makes a new commit that cancels the last one.

History stays clean.

Nothing is hidden.

This is what serious teams want.

2) 🗑️ git reset | delete it completely

This one is different.

It moves your branch back.

The commit is gone.

Like it never happened.

git reset --hard HEAD~1 = Deletes the last commit and your changes.

Fast. Clean. But dangerous.

If someone already pulled that commit… you just created a big mess.

Use it when you’re alone on the branch.

3) 🗃️ git restore | fix files only

This doesn’t touch history.

It just fixes your working files.

git restore --staged app.js = Removes app.js from staging (undo git add). Your edits stay untouched.

git restore app.js = Deletes your changes. File goes back to last commit.

🧠 Concretely:
revert → undo safely
reset → erase history
restore → fix files

Three different jobs.

Where people mess up?

They use reset when they should use revert.

Now history is broken.

Team is confused.

Time is wasted.

🦐 2026 RRR Best Practices

git switch and git restore replaced the overloaded confusing git checkout. This isn’t optional anymore.

Modern teams would love to see you using them.

Old messy git checkout command did everything:
Switch branches. Restore files. Confuse everyone.

Now it’s split into two:

git switch: move between branches
git restore: fix files / undo file changes

ITs much cleaner and accurate.

That’s why you will never see me use checkout in this article.

It’s outdated.

Just like a serious dev who refuses to shallow AI hypes.

I will show you EXACTLY how they work in the next section (#3).

🫰3) Switch & Restore

git switch main
git switch -c feature-payment

git restore README.md
git restore --staged utils.js

👉 `git switch main`

with that, you leave your current branch and return to mission control.

Before:
You’re on: bugfix/login-issue
You’ve got random work-in-progress edits.

After running:

git switch main

You are now on the main branch.

Your files instantly match the main branch’s state.

✍️ NOTE: Uncommitted edits may follow, unless switching would create conflicts, in which case Git stops you to avoid damage. That's protection.

either way, you’ve returned to home base. You’re back to clean ground..

👉 `git switch -c feature-payment`

Result:
A new branch is created which is feature-payment
And you immediately enter that branch.

Now your payment feature lives in isolation.

No risk of breaking main.
No overlap with other features.

🪜 One branch per mission.

👉 `git restore --staged utils.js`

This is your emergency fix when you accidentally run:

git add .

and stage files you didn’t want to include.

Fix it:


git restore --staged utils.js

Result:

utils.js is unstaged which is removed from the commit list.

But your edits remain safely in your working directory.

which means, you fix the mistake without losing a single line.

🐾 4) --amend Commits [Fix Without Noise]

You forgot a file?
You wrote a typo?
You missed a small edit?

You --amend.

🧱 What “--amend” actually DOES?

Amend means:

“Take my LAST commit and update it as if the mistake NEVER existed.”

It does NOT create a new commit. It replaces the previous one.

But most commits like this:

“fix again”
“final fix”
“real final fix”

Now history looks like garbage.

No worries.. you can time travel and --amend.

Real example (this happens all the time)

You accidentally committed .env

Sensitive keys. Big mistake.

You don’t say:

“oops let me fix it in next commit”

No.

You clean it properly:

git rm --cached .env
echo ".env" >> .gitignore
git commit --amend --no-edit

Done.

That commit never had .env.

⏹️ You remove the sensitive file
and rewrite the last commit like it never existed.

Let me explain..

git rm --cached .env 👉 This removes .env from Git tracking (not your computer)

Then:

echo ".env" >> .gitignore 👉 So you don’t repeat the same mistake

Now your changes are staged.

THEN you run:

git commit --amend --no-edit

🫡 This rewrites the last commit
👉 Same message
🦵 But WITHOUT the .env file

Why --no-edit?

Because you don’t want to waste time rewriting the message.

You’re saying:

“Same commit message. Just fix the mistake.”

🤔 What if you WANT to edit?

Then DO NOT use --no-edit.

Just do:

git commit --amend

Now Git opens the editor.

You can fix the message, explain what changed and make it more professional

Now let me illustrate an everyday use case scenario:

git commit --amend
git rebase -i HEAD~5
--amend → fix your last mistake instantly
rebase -i → squash, reorder, clean commits like a surgeon

This is how you turn:

“fixed stuff lol”

into [for example]:

“Refactor auth flow + fix token expiry bug”

Now your history makes sense.

⚠️ WARNING (read twice):

Only --amend local commits.

Never --amend commits already pushed to a team branch.

Why?

Because you rewrite history.

Automated pipelines, merge queues and AI agents HATE rewritten history.

🥍 Push amended commits ONLY if you're 100% sure NO ONE else has pulled them.

🏫 5) Git Log / Learn From History

Git doesn’t lie.

Your code can lie. Your memory can lie. Your teammates can lie.

nowadays devs zombie scroll through Git logs.

They don’t understand the POWER hidden in "history".

Good history = easy debugging
Bad history = endless suffering

⚖️ The 50/72 rule

Follow 50/72 Rule for efficient bug tracing AND debugging.

keep titles under 50 characters and wrap descriptions at 72.

write messages like "Add feature" instead of "Added feature".

and do not mix code refactors with new features in the same commit.

Bad example:

commit 1: "fixed stuff"
commit 2: "final update
commit 3: "changes lol.."

Good example:

commit 1: "fix(auth): resolve token expiry issue"

Now you know what happened without opening code.

Basic survival commands

git log --oneline
git log --oneline --graph --decorate
git log --oneline --author="Shahan"
git log --oneline -- path/to/file

What they really mean:

--oneline = fast history scan + short, readable commits
--graph = see branch chaos visually
--graph --decorate → visualize merges & branches
--author = see who broke what
-- path/to/file = see only a single file’s history

This is how you stop guessing.

When things get serious you type
git log -p
git log -S "functionName"
git blame file.js
git reflog

Now you’re not reading history.

You’re hunting problems.

-p shows exact code changes
-S finds when a bug was introduced
git blame shows who touched each line
git reflog brings back “lost” commits

6) 🪝 Git Hooks to Automate Discipline

Junior devs hope code is fine.

Serious devs don’t hope anything.

They build systems that refuse bad code.

That’s what Git hooks are.

Hooks are simple:

They run automatically when you commit, push, or merge.

Without asking. Without reminders.

If something is wrong they stop you.

The idea is simple:

You try to commit.

Git says:

“Wait. Let me check that first.”

🔧 example of git hooks pre-commit (gatekeeper)

You create this file:

.git/hooks/pre-commit

Now you add rules:

#!/usr/bin/env bash

echo "Running tests..."

npm test || {
  echo "❌ Tests failed. Commit blocked."
  exit 1
}

Then activate it:

chmod +x .git/hooks/pre-commit

What just happened?

You didn’t “add a tool.”

You added a guard at the door.

Now:

tests run automatically
failure = commit rejected
broken code never enters history

Therefore, there's NO debate anymore.
No “I’ll fix it later” nap issue.

🪫2026 Git Hooks Reality

Nowadays most teams don’t hand-write hooks anymore.

They use tools:

they use Husky to manage hooks cleanly

or lint-staged to run checks only on changed files

Because raw hooks don’t scale well.

Tools make it consistent.

Important truth most tutorials skip

Local hooks are not secure.

Anyone can bypass them:

git commit --no-verify

And everything gets ignored.
So if you rely ONLY on local hooks you're mistaken.

So hooks alone are not enough.
Let me explain why..

Real system (what professionals use):

You combine two layers:

1. Local hooks (Fast feedback. Instant rejection.)

2. CI/CD pipelines (GitHub Actions, etc.)

SO
⚡Local = speed
⚖️ Server = enforcement

Local catches mistakes early.
Server enforces rules for everyone.

Together,nothing broken gets through. YOU WIN.

🍋‍🟩🪞 7) Commit References

beginners copy full commit hashes like this:

a3f9c1d8b7e...

Long. Ugly. Useless in daily work.

You don’t need that noise.

🔧 Core Commands

git diff HEAD~2..HEAD
git rev-parse --short HEAD
git tag -a v2.0 -m "Release v2.0"
git push origin v2.0

-- HEAD~2..HEAD = compare recent changes

-- rev-parse --short HEAD = quick reference (human-friendly ID)

-- tag -a = mark a stable checkpoint (this matters)

-- push origin v2.0 = share that checkpoint with the world

🧠 Understand this properly

HEAD = where you are
HEAD~1 = one step back
HEAD~2 = two steps back

You’re not memorizing hashes anymore.

You’re jumping up/down in a timeline. its super productive.

🆔 Why Tags Actually Matter??

Tags are not decoration.

They are anchors.

When you say:

git tag -a v2.0 -m "Release v2.0"

You’re declaring:

“This version is stable. This is deployable.”

Now your CI/CD pipelines + Deployment systems and AI tools

All know exactly what to ship.

NOTE: ⚠️ Fix this weak idea

“Full hashes are sh$t”

No.

Blind usage is actual sh$t.

Full hashes are for finding exact location, scripting and debugging critical issues,

Short refs are for speed.

Know both.

8) 🧳Stash [Pause Work Without Panic]

Interruptions are coming.

Boss calls. Bug report drops. Production is on fire.

And you’re sitting there with half-written code…

Now what?

Commit garbage?
Lose your work?
Panic?

NO.. professionals don’t panic

They stash.

What stash actually is?

Stash is simple:

Save everything I’m doing right now… and bring me back to a clean state.

No commit. No history pollution.

Just pause.

EXAMPLE:

Let say you’re working on a feature.

Suddenly you recieved a message from colleage:

“URGENT: Fix login bug NOW.”

You don’t argue.

You run:

git stash push -m "WIP: profile fix"

Everything disappears.

Not deleted.

Just stored safely.

Your workspace becomes clean again.

Now switch safely

git switch main
git pull

Now you fix the urgent issue without your half-work getting in the way.

See what you saved

git stash list

It’s like a small vault of paused work.

Nothing lost. Just parked.

Bring it back

When you’re ready:

git stash apply

Your work comes back exactly as it was.

Or:

git stash pop

Same thing, but removes it from stash after restoring.

Advanced move

git stash branch hotfix-auth stash@{0}

This does something smarter:

creates a new branch
restores your work there
keeps main branch clean

So you don’t mix emergency fixes with unfinished features.

No conflict with main work.

⚠️🛩️ Reality Check

Stash is NOT permanent storage.

It’s temporary.

Forget it… and it becomes a graveyard.🪦

So use it. Don’t hoard it.

When to use stash

Use it when:

you saves unfinished work safely and then switch tasks instantly

anytime create a branch from stash (stash branch) for experiment

In summary.. need to switch tasks mid-flow? Stash temporarily saves your changes.

9) Bisect 🐞

Manual bug hunting? WEAK MOVE.

Manual bug hunting is slow.

And slow means you suffer.

Bisect = sniper rifle for bug hunting.

Think now: something breaks in production.

No logs. No clear reason.

Only one truth:

It worked yesterday. It’s broken today.

And now you have 50+ commits in between.

Amateurs go to sleep.

Professionals starts hunting.

So what's the solution? you divide the problem.

you use bisect:

git bisect start      # Begin the hunt
git bisect bad        # Current version is broken
git bisect good v2.1  # Last known good version

How the process works

You test the code.

Then you answer only two things:

works = git bisect good
broken = git bisect bad

That’s it.

Git keeps cutting the search space in half.

Again. And again.

Why this is powerful?

50 commits becomes

~6 checks.

its called the power of binary search.

🔥 Now Finish the Bug Hunting mission

When the bug is found:

git bisect reset

Back to normal.

Bug identified.

Target eliminated. ☠️

💡Tips:

You can automate the entire hunt:

git bisect run npm test

Now Git runs your tests automatically on each step.

No manual checking.

No human error.

You just sit back and watch it find the culprit like quillbot ;).

NOTE:

Bisect only works if:

you hAve a known good version
your tests actually work

If your tests are broken, bisect becomes useless.

10) 🧑‍🦯‍➡️ Don’t Merge Blindly

You’ve got a feature-cat branch.

It “works on your machine.”

Now you’re about to merge into main.

And you’re thinking:

“Should be fine.”

That sentence along has destroyed more codebases than bugs ever did.

Rule #1) Check What files are changing

git diff --name-only main..feature-cat

This is your first reality check.

It shows exactly what will be affected.

Rule #2) What actually changed

git diff --color-words main..feature-cat

Now you see the real story.

Not “files changed”.

But what inside those files changed.

This is where bad merges get exposed.

Two ways to compare branches:

git diff main..feature-cat
git diff main...feature-cat

Two-dot vs Three-dot:

-- .. = direct comparison (simple view)
-- ... =true branch difference (REAL merge view)

Most people never learn this difference.

And that’s exactly why they merge wrong.

Before merge, you don’t ask:

“Will this work?”

You ask:

“What exactly am I about to change?”

To sum up, know the battlefield before the fight.

Compare first, merge second.

🫳 11) Cherry-Pick (pick ONLY What You Need)

Sometimes you only need ONE commit from another branch.

You Merging entire branches for one fix?

That’s how you import bugs you NEVER asked for.

lets cherry-pick..

Real Case scenario:

Your feature-login branch has 10 commits:

LoginUI.tsx redesign ❌
authStyles.css change UI ❌
useAuth.ts refactor ❌
✅ Fix: token refresh bug (authService.ts)

Production is breaking.

Users getting logged out every 5 minutes.

You don’t need UI changes.
You don't need refactor.

BUT you need that ONE fix: token refresh bug in authService.ts

💆 Step 1: Find the exact commit

git log --oneline feature-login

You see:

a1b2c3d fix: refresh token expiry bug in authService
f4e5d6c refactor: auth hooks
9a8b7c6 style: login UI update

You take the one that matters: 👉 a1b2c3d

🩺 Step 2: Surgical extraction

git checkout main
git pull
git cherry-pick a1b2c3d

Now only this change is applied:

authService.ts → FIXED
Everything else → untouched

No UI risk. No side effects.

🔨 Step 3: Clean it like a pro

git cherry-pick -e a1b2c3d

Update message:

fix(auth): resolve token refresh logout issue (hotfix)

Now your history makes sense to your team + your CI/CD pipeline

🙎‍♂️What just happened after that 3 steps workflow??

-- Bug reported in production
-- You located the fix commit
-- You shipped ONLY the fix
-- You avoided merging unstable work

This is how senior SWE teams move fast without breaking things.

But hey.. this is also where juniors get destroyed

Cherry-pick can bite you if you have:

-- Same fix exists in two branches later
-- Merge conflicts when syncing branches
-- Duplicate commits + confusing history

You didn’t remove the problem.

You copied the solution.

Big difference.

🧠 So when cherry-pick is the RIGHT move?

Use cherry-pick when:

🚨 Production hotfix
🎯 One isolated commit
⛔ Full merge is risky

Avoid when:

🌆 You need long-term branch sync
♾️ You’re patching randomly without plan

🧱 12) Git Add

If you think git mistakes happen during commits.

You're wrong.

They happen before that.

At staging.

You worked on:

login.js
profile.js
utils.js

Only login.js is ready.

But only amateurs do this:

git add .

And suddenly:

/ half-finished code enters history
/ unrelated changes get bundled
/ reviews become useless
/ AI gets confused
/ debugging becomes harder later

That’s how conflicts starts.

🧑‍⚕️Professional workflow

You don’t git add . everything.

You choose what deserves to exist in history.

git add -p login.js

👉 Stage only specific parts of a file
👉 Build clean, intentional commits

🔍 Preview before committing

git add -n .

👉 Shows what would be staged

⚠️ Advanced control (use carefully)

git add --force .env

👉 Used only when you intentionally need ignored files
👉 Dangerous if you don’t understand why

Staging is not “pre-commit.”

It is decision-making.

You are deciding:

“What deserves to become history?”

✍️ NOTE:

Amateurs commit everything and fix later. Professionals stage with intention and never create havoc in the first place.

Conclusion 🏁

Git is not complicated.

Most of the commands above aren’t even complicated.

They just force you to slow down at the right moments.

It becomes messy when you stop paying attention.

After a while, you stop thinking in commands and start thinking in states:

what changed, what matters, and what should actually be saved.

That’s basically it.

Hope you find this article useful. let me know in the comments section what you have learned so far. Its great to hear. Cheers 🥂

📘 Recommendations: Clean Code Zero to One

Git is a tool. it handles history. Clean Code handles everything inside that history. Developers don’t fail because of Git. They fail because the code itself becomes way too HARD to manage. If you fix that part early, Git becomes your oblige coworker.

use code: POWER40 40% OFF for one week.

👉 Clean Code Zero to One

for those building apps Bright Data takes care of your data: proxies, scraping, data pipelines, all handled. You build. It runs on your behalf.

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

DEV Community: Programming with Shahan

How to learn to code in 2026 (dev job market is insane!)

FIRST: Why "Vibe coding" to "Agentic Engineering" shift happened?

🍼 STEP 1: Coding Fundamentals (non-negotiable)

Language choice

🍌 STEP 2: Software Architecture

🧪 STEP 3: Testing

🛫 STEP 4: Deployment

🛩️🎮 STEP 5: Version Control

🔐 STEP 6: Security & Privacy

🚢 STEP 7: Microservices & Containers

💪 NOW you are ready for AI coding

⚡ The new coding shift: Agentic Engineering

🧠 How to learn code faster

🤔 1. Use AI to THINK, not just code

🔍 2. Reverse engineer code

🏗️ 3. Projects = everything

🧠 4. Ask AI for multiple solutions

📄 5. Documentation shortcut

📚 Recommendation

🧭 Final thoughts

learn these 12 git commands and forget

🌱 Introduction

🎂 1) Rebasing

🍄‍🟫 What rebase actually is

🍨 Rebase workflow

🏗️ Code demonstrations for beginners:

🪦 2) Reset, Revert, Restore

Git gives you three weapons to reverse damage:

Where people mess up?

🦐 2026 RRR Best Practices

🫰3) Switch & Restore

👉 git switch main

👉 git switch -c feature-payment

👉 git restore --staged utils.js

🐾 4) --amend Commits [Fix Without Noise]

Real example (this happens all the time)

🏫 5) Git Log / Learn From History

⚖️ The 50/72 rule

Basic survival commands

6) 🪝 Git Hooks to Automate Discipline

🔧 example of git hooks pre-commit (gatekeeper)

🪫2026 Git Hooks Reality

Important truth most tutorials skip

🍋‍🟩🪞 7) Commit References

🔧 Core Commands

🧠 Understand this properly

🆔 Why Tags Actually Matter??

8) 🧳Stash [Pause Work Without Panic]

What stash actually is?

Advanced move

⚠️🛩️ Reality Check

When to use stash

9) Bisect 🐞

How the process works

🔥 Now Finish the Bug Hunting mission

10) 🧑‍🦯‍➡️ Don’t Merge Blindly

Rule #1) Check What files are changing

Rule #2) What actually changed

🫳 11) Cherry-Pick (pick ONLY What You Need)

💆 Step 1: Find the exact commit

🩺 Step 2: Surgical extraction

🔨 Step 3: Clean it like a pro

🧠 So when cherry-pick is the RIGHT move?

🧱 12) Git Add

🧑‍⚕️Professional workflow

🔍 Preview before committing

⚠️ Advanced control (use carefully)

Conclusion 🏁

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.

👉 `git switch main`

👉 `git switch -c feature-payment`

👉 `git restore --staged utils.js`

5. `tests`