DEV Community: Manu Kumar Pal

Why Backend Engineers Have an Advantage in the AI Era

Manu Kumar Pal — Sat, 04 Apr 2026 03:14:09 +0000

AI is changing how software is built.

But here is something many people miss:

Backend engineers already have a huge advantage.

While others are learning prompts and tools, backend developers already understand the hard parts of real systems.

Let’s break it down in a simple way.

✅ 1. System Thinking Comes Naturally

Backend engineers don’t just write code.
They think in terms of systems.

When building AI features, this matters a lot.

You are already used to thinking about:

✔ How data flows through services
✔ How APIs interact with each other
✔ Where failures can happen
✔ How different components connect

AI is not just a model call.

It is a system with:

inputs
processing
external dependencies
outputs

If you understand systems, you already understand AI at a deeper level.

✅ 2. Debugging Is Your Superpower

AI systems are not always predictable.

Sometimes:

the output is wrong
the response changes
the bug is not obvious

This is where backend engineers shine.

You already know how to:

✔ Read logs
✔ Trace requests
✔ Break down problems step by step
✔ Find the real cause of issues

While others guess, you debug with structure.

That is a huge advantage in AI development.

✅ 3. You Already Think About Performance

AI features introduce new challenges:

Latency from model responses
High API costs
Slow user experience

Backend engineers already care about:

✔ Response time
✔ Efficient queries
✔ Caching
✔ Reducing unnecessary calls

So instead of just making AI “work,”
you make it fast and scalable.

✅ 4. Production Experience Matters Most

Many AI demos look impressive.

But production is different.

In real systems, you must handle:

✔ Failures
✔ Timeouts
✔ Rate limits
✔ Unexpected inputs
✔ Cost control

Backend engineers already work with these problems daily.

That means you don’t just build AI features.

You build AI systems that actually survive in production.

✅ 5. You Understand Data Better Than Most

AI systems depend heavily on data quality.

Backend engineers already work with:

✔ Databases
✔ Data validation
✔ Data consistency
✔ Data transformations

You know:

Bad data → bad output
Missing data → broken logic

This makes you better at designing reliable AI pipelines, not just calling models.

🎯 The Real Advantage

AI tools like GitHub Copilot or ChatGPT can help anyone write code faster.

But they don’t teach:

system design
debugging
performance thinking
production reliability

Those are backend skills.

And those skills are exactly what AI systems need.

💡 Final Thought

In the AI era:

Writing code is easier than ever.
Building reliable systems is still hard.

Backend engineers are already trained for the hard part.

That is why they have a real advantage.

🧠 How to Review AI-Generated Code Like a Senior Engineer

Manu Kumar Pal — Sun, 08 Mar 2026 05:28:55 +0000

AI can write code very fast. Tools like GitHub Copilot, Cursor, and ChatGPT can generate functions, APIs, and even full features in seconds.

But speed isn’t the hard part.

The real challenge is knowing whether the code is safe to ship to production.

Senior engineers don’t just read code.
They question the code.

Here’s a simple way experienced developers review AI-generated code.

✅ 1. Check Edge Cases First

AI usually writes code for the happy path.

But real systems fail in unexpected ways.

Review whether the code handles:

✔ Empty inputs
✔ Null or undefined values
✔ Invalid data formats
✔ Network failures
✔ Timeouts and retries

Senior engineers assume inputs will break and design the code to handle it.

✅ 2. Validate Assumptions

AI-generated code often hides assumptions.

Examples:

🔹 “The API always returns status 200”
🔹 “The list will never be empty”
🔹 “This ID always exists in the database”

Before accepting the code, ask:

✔ Where does this data come from?
✔ Is this value guaranteed?
✔ What happens if the assumption is wrong?

Many production bugs come from bad assumptions, not bad logic.

✅ 3. Verify Data Sources

Always review how data enters the system.

Ask:

✔ Is the input trusted?
✔ Is the API response schema stable?
✔ Can the database return unexpected results?

Never trust external data without validation.

✅ 4. Look for Hidden Complexity

AI sometimes produces code that looks clean but hides complexity.

Watch for:

🔹 Deeply nested conditions
🔹 Long functions doing too many things
🔹 Clever but confusing one-liners
🔹 Duplicate logic across files

If you can’t explain the code in a few seconds, it’s probably too complex.

✅ 5. Review Error Handling

Many AI snippets have weak error handling.

Check whether the code:

✔ Handles exceptions correctly
✔ Returns meaningful error messages
✔ Logs useful debugging information
✔ Prevents silent failures

Production systems should fail clearly and safely.

✅ 6. Watch for Silent Failures

Silent failures are one of the biggest risks in AI-generated code.

Examples include:

🔹 Catching errors but ignoring them
🔹 Returning default values when something breaks
🔹 Swallowing exceptions
🔹 Logging nothing

These issues don’t crash the system — they create wrong results quietly.

Senior engineers prefer visible failures over hidden ones.

✅ 7. Check Performance and Scalability

AI does not always optimize code.

Look for:

✔ Inefficient loops
✔ Repeated database queries
✔ Unnecessary API calls
✔ Memory-heavy operations

Always ask:

“Will this still work under heavy load?”

✅ 8. Review Security Risks

AI can accidentally generate insecure code.

Check for:

✔ SQL injection risks
✔ Hardcoded API keys or secrets
✔ Unsafe file operations
✔ Missing input validation

Security reviews are non-negotiable.

✅ 9. Confirm Architecture Fit

Even if the code works, it may not fit your system design.

Review whether it:

✔ Follows project structure
✔ Matches coding standards
✔ Uses approved libraries
✔ Keeps responsibilities clear

Good code must fit the existing architecture, not just the feature.

✅ 10. Add Proper Tests

AI rarely produces strong tests.

Before shipping code, add:

✔ Unit tests
✔ Edge case tests
✔ Failure scenario tests
✔ Integration tests

Testing is what turns working code into reliable code.

🎯 The Real Difference

AI can generate code.

But engineering value comes from judgment and review.

The difference between a junior and a senior developer often comes down to one question:

A junior asks: “Does it work?”
A senior asks: “What could break in production?”

That mindset is what separates code generators from real engineers.

🧠 AI Architecture for Beginners: What Goes Where (No Buzzwords)

Manu Kumar Pal — Sat, 07 Feb 2026 06:27:47 +0000

Hey devs 👋

If you're building your first AI app, you're probably not confused about the model.

You're confused about the structure.

Where does the AI call go?
Where does memory live?
What runs on the frontend vs backend?

Let’s break down AI architecture in simple steps.

🗺️ The Simple Flow

At a high level, most AI systems look like this:

User → Router → Memory → Vector DB → LLM → Response

Each piece has one job.

That’s it.

1️⃣ LLM — The Brain

The LLM (Large Language Model) is the part that:

Understands text
Generates responses
Explains code
Summarizes logs
Writes suggestions

But here’s what it does not do well:

Store long-term data
Search large datasets reliably
Remember everything forever

Think of it like:

🧠 A brilliant intern
But with short-term memory.

2️⃣ Router — The Decision Maker

The router decides:

“Does this question need external data or not?”

Example:

User asks:

“What is REST?”

Router → No data needed → Send directly to LLM

User asks:

“Why is my API returning 500 errors?”

Router → Needs logs → Query database first

Without a router:

Every request hits the LLM blindly
Costs increase
Logic becomes messy

Think of it as:

🚦 Traffic control for your AI app.

3️⃣ Memory — Short-Term Context

Memory stores recent conversation context:

Last user message
Preferences
Ongoing session data

It answers:

“What should the AI remember right now?”

It is not a database.

It’s temporary.

Think of it like:

🗒️ Sticky notes during a conversation.

4️⃣ Vector Database — Long-Term Knowledge

This is where your real data lives:

Documentation
Logs
FAQs
Internal knowledge
Support tickets

Instead of keyword matching, it searches by meaning.

So when a user asks:

“Why am I getting unauthorized errors?”

It can retrieve:

401 logs
Token expiration issues
Auth failure patterns
Even if the wording is different.

Think of it as:

📚 A smart searchable knowledge library.

🔁 How a Real Request Flows

User asks:

“Why is my order API failing with 401?”

Behind the scenes:

1️⃣ Router checks → Needs logs
2️⃣ Vector DB searches relevant entries
3️⃣ Memory adds recent conversation context
4️⃣ LLM combines everything
5️⃣ Response is generated

The user receives:

Explanation
Possible causes
Suggested next steps

No magic.
Just clean separation of responsibilities.

❌ Common Beginner Mistakes
❌ Putting everything inside one giant prompt

Leads to:

High token cost
Slow responses
Hard debugging

❌ Skipping the router

Every request becomes expensive and unnecessary.

❌ Using memory as permanent storage

Memory is temporary. Data gets lost.

❌ No retrieval layer

The AI starts guessing instead of retrieving real information.

✅ Why This Architecture Works

Easier to scale
Easier to debug
Lower cost
Clear ownership of responsibilities
Easier to extend later

You can plug in:

Authentication
Tool execution
Caching
Monitoring
Without redesigning the whole system.

🎯 Final Thought

AI systems are not complicated.

They are just organized.

If you understand:

🧠 What thinks
🚦 What decides
🗒️ What remembers
📚 What stores knowledge

You understand AI architecture.

And once you see the structure,
AI stops feeling like magic — and starts feeling like engineering.

5 AI Prompting Mistakes Developers Make

Manu Kumar Pal — Wed, 28 Jan 2026 02:36:16 +0000

Most developers don’t struggle with using AI.
They struggle with talking to it properly.

AI isn’t magic — it’s a system that responds to how clearly you think and communicate.

When prompts are unclear, rushed, or unstructured, the output feels random.
When prompts are clear, scoped, and intentional, AI suddenly feels useful.

Below are the 5 most common AI prompting mistakes developers make — and exactly how to fix them with simple before/after examples.

🧠 What Is Prompting?

Prompting = giving instructions to AI.

Just like you explain a task to:
a junior developer
a teammate
or even your future self
you explain a task to AI using text.

A prompt can include:

🧩 Context → what is this about?

🎯 Goal → what do you want?

📐 Constraints → rules, format, limits

🛠️ Examples → how the output should look

🧠 Why Prompting Matters

Think of AI like a junior developer:

🧩 It needs context

🗺️ It needs direction

🎯 It performs best with constraints

Bad prompts = bad requirements
Good prompts = predictable results

1️⃣ Being Too Vague

If your prompt is unclear, the output will be too.

❌ Bad Prompt

Optimize this code
Optimize how?
Performance?
Readability?
Memory?
Security?

AI has to guess.

✅ Better Prompt

Refactor this function to improve readability and reduce nested conditionals. Keep behavior the same.

🎯 Why this works

Clear goal
Clear constraints
Less guessing

👉 AI performs best when ambiguity is removed.

2️⃣ Asking AI to Figure Everything Out

AI is not a mind reader.
Context matters — a lot.

❌ Bad Prompt

Why is this API slow?

No logs.
No code.
No traffic data.

✅ Better Prompt

Here’s the API endpoint, recent logs, and response times. Based on this, what are the most likely causes of slowness?

🎯 Why this works

You provide evidence
AI analyzes instead of guessing
Output becomes actionable

👉 Treat AI like a teammate — give context.

3️⃣ One-Shot Prompts for Complex Tasks

Big tasks rarely work in one prompt.

❌ Bad Prompt

Design a scalable backend system for my app
That’s architecture, infra, security, scaling — all at once.

✅ Better Prompt (Step-by-Step)

Ask clarifying questions about users, scale, and data
Suggest a simple architecture
Explain tradeoffs

🎯 Why this works

Breaks complexity
Mimics real engineering discussions
Fewer hallucinations

👉 Multi-step prompting = better reasoning.

4️⃣ Not Giving Constraints or Examples

Without boundaries, AI fills gaps randomly.

❌ Bad Prompt

Write API error responses

What format?
What style?

✅ Better Prompt


Write API error responses in this format:
{ error: { code, message } }
Example:
{ error: { code: "INVALID_INPUT", message: "Email is invalid" } }

🎯 Why this works

Sets expectations
Enforces consistency
Reduces rework

👉 Examples > explanations.

5️⃣ Treating AI as a Source of Truth

AI sounds confident — even when wrong.

❌ Bad Prompt

Give me the best caching strategy for my system

AI doesn’t know:
your traffic
your data
your constraints

✅ Better Prompt

Given this system design and traffic pattern, suggest possible caching strategies and their tradeoffs.

🎯 Why this works

AI becomes a thinking partner
You stay in control
Better decisions

👉 AI suggests. Developers decide.

✅ How Good Developers Use AI

They use AI as:

🧠 A fast reader (summarize code, docs)

🧩 A thinking partner (ideas, alternatives)

✍️ A documentation assistant

🔍 A debugging helper

Not as:

❌ a source of truth

❌ a decision-maker

❌ a replacement for thinking

🎯 Final Thoughts

AI doesn’t replace your thinking — it reflects it.

The developers who get the most value from AI:

🧠 Think before they prompt

✍️ Write clear, intentional instructions

🔍 Review outputs critically

🛠️ Use AI as support, not authority

If you treat AI like:

❌ a magic box → you’ll get random results

✅ a teammate → you’ll get real productivity

Prompting is a skill.
And like any dev skill — it improves with practice.

✨Thanks for reading! Stay tuned for more full-stack + AI tips and practical lessons.

Reading Large Codebases: A Skill Every Backend Dev Needs

Manu Kumar Pal — Fri, 23 Jan 2026 03:40:18 +0000

Most backend developers think their job is about writing code.
In reality, a big part of the job is reading code written by others.

Large codebases can feel overwhelming — but learning how to read them is a skill that separates good developers from great ones.

Let’s break down how to approach large codebases without getting lost.

1️⃣ Don’t Start by Reading Everything

This is the biggest mistake.

Large codebases are not books.
They’re maps.

❌ Bad approach:

open random files
read line by line
feel overwhelmed

✅ Better approach:

understand what the system does
identify main entry points

Start with the big picture, not the details.

2️⃣ Find the Entry Points First

Every backend system has clear starting points:

Look for:

API routes / controllers
main application file
background job workers
scheduled tasks

These tell you:

how requests enter the system
what paths data takes

3️⃣ Follow One Request End-to-End

Pick one simple API.

Example:

GET /users/{id}

Then trace it:

Controller → Service → Repository → Database
Ignore everything else.
Understanding one flow gives you context for the rest.

4️⃣ Learn the Folder Structure

Good codebases are organized intentionally.

Common patterns:

/controllers
/services
/repositories
/models

This tells you:

where logic lives
where data access happens
what not to touch
Structure is documentation.

5️⃣ Use Logs and Tests as Guides

Tests show:

how the system is supposed to behave
important edge cases

Logs show:

what the system actually does in production

Read both.
They reveal more than comments.

6️⃣ Don’t Try to Understand Everything at Once

Large systems are learned in layers.

First:

happy path

Then:

edge cases

Later:

performance
failures
rare flows
Depth comes with time.

7️⃣ Let Tools Do the Heavy Lifting

Use your editor properly:

“Go to definition”
“Find references”
Search by keyword

Modern IDEs are navigation tools, not just editors.

8️⃣ Ask the Code Questions

Instead of:

“What does this system do?”

Ask:

Where is this data coming from?
Who calls this function?
What breaks if this fails?
Good questions guide your reading.

9️⃣ Write Notes (Even Temporary Ones)

Keep track of:

important files
confusing logic
TODOs to revisit

Your brain is not a long-term memory store.
Notes speed up learning.

🔟 Accept That Confusion Is Normal

Everyone feels lost at first.
Even senior engineers.

Understanding grows through:

repetition
exposure
real changes

Clarity comes after confusion.

🎯 Final Thought

Strong backend developers aren’t defined by how fast they type,
but by how well they understand systems.

If you can read a large codebase,
you can debug faster, design better, and make safer changes.

That skill travels with you — to any team, any project.

🚀 Where AI Helps Backend Developers — And Where It Doesn’t

Manu Kumar Pal — Mon, 12 Jan 2026 12:57:13 +0000

AI is everywhere in tech conversations.
But in backend work, not everything benefits from AI.

Used well, AI saves hours.
Used blindly, it creates bugs, confusion, and false confidence.

Let’s separate where AI actually helps from where it doesn’t.

✅ Where AI Helps Backend Developers

1️⃣ Understanding Existing Code

✅ AI is great at:

Explaining unfamiliar code
Summarizing large files
Walking through logic step by step

✅ Perfect for:

Legacy codebases
Onboarding to new projects
AI reduces reading time, not thinking responsibility.

2️⃣ Debugging With Context

✅ AI helps when you give it:

Error messages
Logs
Stack traces

✅ It can:

Explain what the error means
Suggest common causes
Propose debugging steps

👉 You still verify the fix.

3️⃣ Writing Boilerplate Code

✅ AI shines at:

CRUD endpoints
DTOs / schemas
Mappers
Config files

This saves time on repetitive work, not core logic.

4️⃣ Documentation & Communication

✅ AI is excellent at:

Writing API docs
Summarizing PRs
Turning code into explanations

✅This improves:

Team communication
Knowledge sharing
Onboarding speed

5️⃣ Log & Data Summarization

✅ AI is widely used to:

Summarize logs
Group similar errors
Highlight unusual patterns

✅ Especially useful for:

On-call engineers
DevOps teams

❌ Where AI Does Not Help (Much)

6️⃣ System Architecture Decisions

✅ AI can suggest patterns, but it can’t:

Understand team dynamics
Predict future growth
Feel operational pain
Architecture is about tradeoffs, not answers.

7️⃣ Business Logic & Rules

✅ AI doesn’t know:

Real business constraints
Edge cases
Legal or financial risk

✅ These must come from:

Domain experts
Product decisions
Human judgment

8️⃣ Performance Tuning at Scale

✅ AI struggles with:

Query optimization
Cache strategies
Production bottlenecks

✅ These require:

Metrics
Load testing
Experience

9️⃣ Security & Authorization Logic

✅ AI should never:

Decide permissions
Generate auth rules blindly
Handle secrets
Security requires precision, not probability.

🔟 Ownership & Accountability

AI can suggest.
It can assist.
It can explain.

✅ But it cannot:

Own failures
Take responsibility
Be on-call at 3am
That part is still human.

🧠 How to Use AI the Right Way

✅ Think of AI as:

A junior engineer
A fast reader
A tireless explainer

✅ Not as:

An architect
A decision-maker
A source of truth

AI accelerates thinking — it doesn’t replace it.

🎯 Final Thought

✅ Backend development is about:

clarity
correctness
reliability

AI helps with speed and support.
Humans handle judgment and responsibility.

Used together, they’re powerful.

API Design Basics Every Backend Developer Should Know

Manu Kumar Pal — Sun, 04 Jan 2026 04:29:13 +0000

APIs are contracts.
If the contract is unclear, things break — slowly or suddenly.

This API design covers basics that make your APIs easier to use, safer to change, and harder to break.

1️⃣ Use HTTP Status Codes Properly

Status codes are not optional metadata — they’re signals.

❌ Bad

200 OK
{
  "error": "User not found"
}

✅ Good

404 Not Found

Common codes to remember:

200 → success

201 → created

400 → bad request

401 → unauthorized

403 → forbidden

404 → not found

500 → server error

2️⃣ Keep URLs Simple and Clear

URLs should describe resources, not actions.

❌ Bad

/getUser
/createOrder

✅ Good

GET /users/{id}
POST /orders

Let HTTP methods do the work.

3️⃣ Be Consistent With Responses

Inconsistent responses confuse clients.

❌ Bad

{ "msg": "ok" }

{ "success": true }

✅ Good

{
  "data": {...},
  "meta": {...}
}

Consistency makes APIs predictable.

4️⃣ Design Errors Like a Feature

Errors should be helpful, not mysterious.

❌ Bad

{ "error": "Something went wrong" }

✅ Good

{
  "error": {
    "code": "INVALID_INPUT",
    "message": "Email format is invalid"
  }
}

Clear errors reduce support and debugging time.

5️⃣ Always Paginate Lists

Large responses hurt performance.

❌ Bad

GET /users

✅ Good

GET /users?page=1&limit=20

Response:


{
  "data": [...],
  "page": 1,
  "limit": 20,
  "total": 250
}

Pagination protects your API and database.

6️⃣ Version Your API Early

Breaking changes happen — plan for them.

✅ Good

/api/v1/users
/api/v2/users

Versioning lets clients upgrade safely.

7️⃣ Don’t Overload One Endpoint

One endpoint should do one thing well.

❌ Bad

POST /users?action=createAndSendEmailAndLog

✅ Good

POST /users
POST /emails

Simple endpoints are easier to test and maintain.

8️⃣ Secure by Default

Never assume clients behave correctly.

Basics to follow:

➡️ Validate inputs

➡️ Authenticate every request

➡️ Authorize every action

➡️ Rate limit public endpoints

Security is part of API design, not an add-on.

9️⃣ Document Everything

APIs without docs slow everyone down.

Use tools like:

➡️ OpenAPI / Swagger

Docs are part of your API.

🎯 Final Thoughts

Good API design is not about being clever.
It’s about being clear, predictable, and boring.

And that’s a good thing.

The AI Workflows That Save Me 10+ Hours a Week as a Developer

Manu Kumar Pal — Tue, 30 Dec 2025 03:08:06 +0000

AI doesn’t replace developers.
It just removes the boring, repetitive work so we can build faster.

These are the 5 simple ways I use AI every week to save time.

1️⃣ Start Projects Faster

Instead of setting up folders, configs, and dependencies manually, I ask AI to build a starter template.

What I say:

Make a project starter with:
- folder structure
- dependencies
- basic config files
- example components

Result: I start coding features immediately.
Time saved: ~1 hour

2️⃣ Debug With Context (Not Just Errors)

AI is better at debugging when it has the story, not just the problem.

What I say:

I'm getting this error.
Here’s the code, what I expected, what happened, and what I tried.
What’s the most likely cause?

Result: No more guessing or random fixes.
Time saved: ~2 hours

3️⃣ Ask for Better Code, Not Just More Code

AI can be a “review buddy” to clean your code.

What I say:

Make this code cleaner and faster.
Explain why each change is better.

Result: You learn while improving.
Time saved: ~1 hour

4️⃣ Convert Docs into Steps

Docs can be long. AI can turn them into clear action steps.

What I say:

Turn this documentation into:
- steps to follow
- commands to run
- common mistakes to avoid

Result: Quick setup → less confusion.
Time saved: 1–2 hours

5️⃣ Auto-Generate Tests

I write the feature.
AI writes tests to catch bugs.

What I say:

Write tests for this code.
Include edge cases and sample data.

Result: More coverage with less effort.
Time saved: ~3 hours

🧠 Why These Workflows Actually Work

Most people ask AI to do work.
Developers should ask AI to improve their work.

✔ context
✔ constraints
✔ examples
✔ expected outputs

🚀 Final Thought

AI doesn’t save time by doing everything for you —
it saves time by removing everything that blocks you.

Build faster. Think more. Ship more.

🚀 5 AI Prompting Tips for Developers

Manu Kumar Pal — Mon, 29 Dec 2025 12:31:49 +0000

If you want better responses from AI tools (ChatGPT, Claude, Gemini, etc.), stop typing random messages and start prompting with structure.

These 5 tips make AI work with you like an engineer-in-training you mentor, instead of a random output generator.

1️⃣ Give Context Before the Question

❌ Bad:

“Fix this code.”

✔️ Good:

Context: Next.js app with Firebase auth.
Problem: Login works locally but not in production.
Task: Identify the cause and list 2 fixes.

💡 Context = clarity.
No context = confusion.

2️⃣ Speak Like You're Writing a Function

❌ Bad:

“Make a dashboard.”

✔️ Better:

Task: Create a dashboard layout in React.
Requirements:
- Sidebar + header layout
- Dark mode toggle (state)
- Placeholder for data list
Output: Code only, no explanation.

This gives the AI inputs, constraints, and expected output.

3️⃣ Define What You Don’t Want

LLMs fill gaps. If you don’t set boundaries, they’ll invent things.

✔️ Example boundary prompt:

Do NOT:
- Add libraries I didn't mention
- Invent API endpoints
- Add animations or UI styling

🧠 Telling AI what not to do is just as important as what you want.

4️⃣ Ask for the Smallest Fix First

Don’t let AI rewrite your entire project when you only need one line changed.

Error:
TypeError: req.user is undefined

Give me:
1. Why it happens
2. 1-line patch fix
3. A long-term scalable fix

This keeps your codebase safe from guesswork.

5️⃣ Force Output Format

Pick a format: code, JSON, Markdown, or steps.

Output Format:
{
 "issue": "What caused it",
 "fix": "1-3 line patch",
 "test": "How to verify the fix",
 "future": "How to prevent it again"
}

You get structured answers instead of paragraphs of noise.

🧱 Final Thought

AI doesn’t replace developers.
It replaces the repetitive parts of development — if you guide it correctly.

Prompt like a developer.
Not like a user.

14 Design Mistakes Developers Make (and How to Fix Them With Examples)

Manu Kumar Pal — Thu, 25 Dec 2025 05:39:31 +0000

A practical guide for devs who want better UI without becoming designers.

Most developers don’t want to be designers — and that’s fine.
But a little design understanding can make your app feel 10x more professional with the same code.

Let’s get into it. 🚀

1️⃣ Using Too Many Font Sizes

📉 Problem: Random sizes make the UI feel messy and unplanned.

/* ❌ What devs often do */
h1 { font-size: 42px; }
h2 { font-size: 30px; }
h3 { font-size: 27px; }
p  { font-size: 18px; }
.small { font-size: 15px; }
.tiny { font-size: 13px; }

✅ How to Fix

Use a scale and repeat it everywhere.

h1 { font-size: 2rem; }
h2 { font-size: 1.5rem; }
h3 { font-size: 1.25rem; }
p  { font-size: 1rem; }

2️⃣ No Spacing System

📉 Problem: Everything feels cramped or uneven.

✅ Fix

Use a spacing scale:

4px → 8px → 12px → 16px → 24px → 32px → 48px

.section { padding: 24px; margin-bottom: 32px; }

3️⃣ Inconsistent Buttons

📉 Problem: Different borders, shadows, padding = unprofessional.

✅ Fix

Make a ruleset once → reuse everywhere.

button {
  padding: 10px 16px;
  border-radius: 8px;
  font-weight: 600;
  transition: 0.2s;
}
button:hover { opacity: .9; }
button:active { transform: scale(.97); }

4️⃣ Using Too Many Colors

📉 Problem: More colors ≠ better UI.

🎯 Use 5 max:

Primary

Secondary

Background

Text

Accent

5️⃣ Ignoring Hierarchy

📉 Problem: Users don’t know what to look at first.

✅ Fix

Structure your content:

Big title = what

Subtitle = why

Normal text = details

<h1>Track expenses smarter</h1>
<p>AI categories every transaction automatically.</p>
<button>Get Started</button>

6️⃣ Centering Everything

📉 Problem: Center text = okay. Center paragraphs = painful.

✅ Fix

Center = headings, hero text

Left-align = paragraphs

7️⃣ Low Contrast Text

📉 Light grey looks pretty but is unreadable.

❌ Bad
color: #999;

✅ Fix
color: #1a1a1a;

8️⃣ Inconsistent Icon Styles

📉 Mixed icon styles look amateur.

✅ Fix

Choose ONE library:

Lucide

HeroIcons

Feather

9️⃣ Full-Width Text

📉 Wide paragraphs tire the eyes.

✅ Fix

max-width: 65ch;

🔟 No Visual Grouping

📉 Everything floats = no structure.

✅ Fix with:

Cards

Background blocks

Dividers

Padding + spacing

1️⃣1️⃣ No Interaction Feedback

📉 Buttons feel dead.

✅ Fix

button:hover { opacity: .85; }
button:active { transform: scale(.97); }

1️⃣2️⃣ Popups Everywhere

📉 Popups are not a navigation strategy.

✅ Fix

Use:

inline components
drawers
side panels

1️⃣3️⃣ Only Using Color for Errors

📉 Not accessible for color-blind users.


❌ Bad

Email invalid

✅ Fix
<p class="error"><span>⚠️</span> Invalid email format</p>

1️⃣4️⃣ Not Testing on Mobile First

📉 Desktop perfect ≠ mobile usable.

✅ Fix

.container { width: 100%; }
@media (min-width: 768px) {
  .container { max-width: 700px; margin: auto; }
}

🚀 Final Thoughts

You don’t need to “be a designer.”

You need:

✅ Rules
✅ Consistency
✅ Repeated patterns

✨ Design isn’t decoration.
It’s decision-making.

⚡10 Low-Effort, High-Impact Web Performance Tips

Manu Kumar Pal — Tue, 09 Dec 2025 03:29:40 +0000

Improving web performance doesn’t have to be overwhelming.
Here are 10 simple changes that give you immediate results — no major refactor required.

🚀 1. Use Modern Image Formats (WebP / AVIF)

These formats can cut image sizes by 40–70% with no visible quality loss.

⚡ 2. Add loading="lazy" to Images

Stop loading off-screen images until they’re needed.

<img src="photo.jpg" loading="lazy" />

📦 3. Minify Your Assets

Minify HTML, CSS, and JS in your build process.
Most bundlers handle this automatically.

🧹 4. Remove Unused CSS

Use tools like PurgeCSS or Tailwind JIT to eliminate dead CSS.

✂️ 5. Ship Less JavaScript

Ask yourself: “Do I need this library?”
Heavy libraries slow parsing and execution.
Replace with native APIs when possible.

🧠 6. Use defer for Non-Critical Scripts

<script src="app.js" defer></script>

This prevents JavaScript from blocking page rendering.

📝 7. Cache Aggressively

Use:

✔ Cache-Control headers

✔ CDN caching

✔ Browser caching

This speeds up repeat visits instantly.

🔍 8. Preload Critical Assets

Fonts, hero images, or key scripts load faster with:

link rel="preload" href="/images/hero.webp" as="image">

🛠️ 9. Enable Compression

Compressing responses reduces payload sizes dramatically.
Brotli is usually the best choice.

📱 10. Optimize Fonts

Fonts can block rendering.

Use:

✔ font-display: swap

✔ Only the weights you need

🎉 Final Thoughts

You don’t have to rebuild your app to make it fast.
Start with these 10 practical tweaks, and you’ll see real improvements in load time, responsiveness, and overall UX.

✔ modern image formats
✔ lazy loading
✔ minify + cache
✔ reduce JavaScript
✔ optimize fonts

These techniques alone can reduce load times by 40–60% on real production apps.

Small fixes → big impact.

LocalStorage vs SessionStorage vs Cookies — When to Use What?

Manu Kumar Pal — Sun, 30 Nov 2025 06:14:03 +0000

Modern web apps store a lot of data in the browser — user preferences, tokens, UI states, cart items, and even feature flags.

But which storage should you use?
👉 LocalStorage? SessionStorage? Cookies? Let’s break it down in a simple!

🗃️ 1. LocalStorage

✅ Persistent storage for long-term use

Property

⏳ Lifespan -> Until manually cleared (stays even after browser restart)
📦 Capacity -> ~5–10 MB
🔐 Sent to server? ❌ No
🌐 Accessible from JS? ✔️ Yes

👍 Best for:

✔️ Saving theme preferences (dark/light mode)

✔️ User settings that don’t need to expire

✔️ Caching small API responses

✔️ Store cart items for returning users

👎 Avoid for:

Sensitive info like JWT tokens (risk of XSS)

Anything requiring expiration control

💡 Example:

localStorage.setItem("theme", "dark");
const theme = localStorage.getItem("theme");

🕒 2. SessionStorage

✅ Short-term storage tied to a single tab

Property

⏳ Lifespan -> Until the tab is closed
📦 Capacity -> ~5 MB
🔐 Sent to server? ❌ No
🌐 Accessible from JS? ✔️ Yes

👍 Best for:

✔️ Multi-step forms (wizard forms)

✔️ Temporary UI state

✔️ Session-based data that should not persist

👎 Avoid for:

Anything you want users to keep after closing the browser

Sharing data across tabs

💡 Example:

sessionStorage.setItem("step", "2");

🍪 3. Cookies

✅ Small pieces of data stored by the browser and optionally sent to the server

Property

⏳ Lifespan -> Configurable (expires in X days/minutes)
📦 Capacity -> ~4 KB (very small)
🔐 Sent to server? ✔️ Yes (unless HttpOnly is used)
🌐 Accessible from JS? Optional (depends on HttpOnly flag)

👍 Best for:

✔️ Authentication sessions

✔️ Storing secure tokens with HttpOnly + Secure + SameSite

✔️ Remember-me functionality

👎 Avoid for:

Storing large data

Anything that doesn’t need to be sent to the server

💡 Example:

document.cookie = "user=John; expires=Fri, 31 Dec 2025 23:59:59 GMT; path=/";

🧭 When to Use What?

✅ Use LocalStorage when:

You want data to persist long term

Data is non-sensitive

You don’t need the server to read it

Example: theme settings, UI preferences, cart items

✅ Use SessionStorage when:

Data should reset on tab close

You need temporary state

It’s fine the server never sees it

Example: multi-step form progress

✅ Use Cookies when:

The server needs the data

You need secure auth

You need expiration control

Example: JWT tokens stored as HttpOnly cookies

🎉 Final Thoughts

Understanding browser storage makes your app safer, faster, and more reliable.