DEV Community: Balraj Singh

Your Context Window Is Not a Knowledge Base

Balraj Singh — Sat, 27 Jun 2026 21:46:47 +0000

Part 2 of Practical AI Engineering: Beyond the Demo

Bigger context windows create a tempting idea:

Put everything in. Let the model work it out.

That is not context engineering. It is moving the junk drawer closer to the model.

An AI system can receive a huge amount of text and still miss the one fact that matters. The problem is not only how much context fits. It is whether the right information reaches the model at the right moment.

Context is an attention budget

A context window is the information available to the model for the current call. It may contain:

system instructions,
the user’s task,
examples,
retrieved documents,
tool descriptions,
tool results,
conversation history,
project notes,
intermediate plans.

All of these compete for attention.

More context can help when it adds missing evidence. It can hurt when it adds stale, repeated, conflicting, or irrelevant material.

The useful question is not:

How much context can this model hold?

It is:

What is the smallest high-signal context that makes the next decision easier?

The seven layers of useful context

I use this mental model when deciding where information belongs.

1. System instructions: stable behaviour

Put durable rules here:

safety boundaries,
output conventions,
non-negotiable policies,
the broad responsibility of the assistant.

Do not turn the system prompt into a company wiki. Stable behaviour and changing knowledge have different lifecycles.

2. Task contract: the current job

The task should contain:

the goal,
relevant local context,
constraints,
expected output,
acceptance checks.

This layer should answer: What are we trying to accomplish now?

3. Examples: the quality bar

Examples are useful when the desired behaviour is easier to show than describe.

One good code-review finding can teach evidence, severity, and scope better than several vague adjectives.

Examples should be representative. A misleading example can anchor the model in the wrong direction.

4. Retrieval: changing evidence

Use retrieval when the answer depends on information that is:

too large to keep in every prompt,
frequently updated,
specific to the current question,
expected to be cited or verified.

Retrieval is not memory. It is a search step that selects evidence for this task.

5. Working memory: state that must survive

Long-running work creates facts that are not part of the original documents:

decisions already made,
files changed,
tests that failed,
unresolved questions,
the next planned step.

Store these outside the context window, then bring back the relevant parts.

A simple NOTES.md can be more useful than replaying an entire conversation.

6. Tools: possible actions

A tool description is also context. It tells the model:

what action exists,
when to use it,
what arguments are valid,
what result to expect,
what side effects it may cause.

Poor tool descriptions create poor tool use. Ten overlapping tools with vague names can be worse than three clear ones.

7. Recent history: local continuity

Recent messages can preserve the flow of a task. Old raw history often becomes noise.

Keep decisions and unresolved items. Compress repeated explanations, large tool outputs, and dead ends.

A simple context compiler

Instead of building one permanent mega-prompt, assemble context for each step.

type AgentTask = {
  goal: string;
  projectId: string;
  query: string;
};

async function buildContext(task: AgentTask) {
  const policy = await loadStablePolicy();
  const projectState = await loadRelevantProjectNotes(task.projectId);
  const evidence = await retrieveEvidence(task.query);
  const recentDecisions = await summarizeRecentDecisions(task.projectId);

  return {
    policy,
    task,
    projectState,
    evidence,
    recentDecisions,
  };
}

The important idea is not this exact code. It is that context should be selected, not dumped.

Five common context failures

1. Context omission

The model never receives the fact needed to make the right choice.

Symptom: confident but generic answers.

Fix: trace the answer back to the evidence available at that step.

2. Context pollution

The prompt contains too much low-value material.

Symptom: the model follows an old detail and ignores the current goal.

Fix: remove repeated history, raw logs, and unrelated documents.

3. Context conflict

Two instructions or sources disagree.

Symptom: inconsistent behaviour across similar runs.

Fix: define precedence. Prefer current, authoritative sources and expose the conflict when it cannot be resolved.

4. Context staleness

The retrieved or remembered information is no longer true.

Symptom: a well-written answer based on an old policy or obsolete API.

Fix: attach source dates, versions, and expiry rules. Retrieval needs freshness, not only similarity.

5. Context leakage

Sensitive information reaches a model, tool, or sub-agent that does not need it.

Symptom: excessive data exposure and a larger security boundary.

Fix: apply least privilege to context. Redact, scope, and route sensitive tasks deliberately.

Long tasks need context management, not just a larger window

For work that spans many steps, three patterns are especially useful.

Compaction

Summarise the important state and discard bulky history.

Keep:

architectural decisions,
current failures,
requirements,
next actions.

Drop:

repeated tool output,
abandoned paths,
conversational filler.

Structured notes

Let the agent write durable state outside the context window.

For a coding task, that might be:

Goal:
Migrate the retry path without changing the public API.

Decisions:
- Reuse the original idempotency key.
- Keep the existing timeout value.

Open issues:
- Integration test fails only on Windows.

Next:
- Inspect path handling in test fixtures.

Context isolation

Use a focused sub-agent for a bounded investigation, then return a short result to the main agent.

The main agent does not need every search query and failed attempt. It needs the conclusion, evidence, and uncertainty.

The four-C filter

Before adding any context, ask whether it is:

Correct: Is it trustworthy?
Current: Is it still valid?
Compact: Can it be made smaller without losing meaning?
Connected: Will it change the next decision?

If it fails the fourth test, it probably does not belong in the current context.

Context engineering in one sentence

Prompt engineering focuses on what we say to the model.

Context engineering focuses on what the system lets the model know at each step.

That includes retrieval, memory, tools, history, and the rules that decide what gets included.

A large context window is useful capacity. It is not an information architecture.

Where is your current AI workflow using “paste everything” as a substitute for context selection?

Stop Writing Bigger Prompts. Start Writing Better Task Contracts

Balraj Singh — Thu, 25 Jun 2026 20:02:47 +0000

Part 1 of Practical AI Engineering: Beyond the Demo

Most developers think better prompting means finding better words.

Add a role. Add more detail. Ask the model to “think step by step.” Keep extending the prompt until it becomes a small novel.

That can improve an answer. It does not make the workflow reliable.

After years of working on large software systems, I trust explicit contracts more than clever wording.

For serious work, a prompt should look less like a clever question and more like a good engineering task. It should tell the model what success means, what evidence it can use, and where it must stop.

I call this a task contract.

A prompt asks. A task contract defines success.

Compare these two requests.

Prompt A

Review this pull request and find any issues.

The model must guess:

What kind of issues matter?
Which files are in scope?
Is it allowed to suggest a redesign?
How should it report uncertainty?
What does a useful answer look like?

Now consider this version.

Prompt B

Goal:
Review this pull request for correctness and regression risk.

Context:
- This is a TypeScript service that processes subscription renewals.
- The diff changes retry handling after a payment timeout.
- Duplicate charges are the highest-risk failure.

Scope:
- Review the changed code and directly connected call paths.
- Do not comment on formatting or unrelated refactors.

Deliverable:
Return a table with:
1. severity,
2. file and line,
3. failure scenario,
4. evidence from the code,
5. smallest safe fix,
6. test that would catch it.

Acceptance checks:
- Do not report an issue without code evidence.
- Separate confirmed defects from possible risks.
- Say "not enough evidence" when the diff cannot support a conclusion.

The second version is not better because it sounds smarter. It is better because it reduces hidden decisions.

That is the real job of a useful prompt.

The five parts of a task contract

1. Goal

State the outcome, not merely the activity.

Weak:

Look at this API.

Better:

Find behaviours that could cause an existing mobile client to break after this API change.

“Look at” describes effort. “Find breaking behaviours” describes value.

2. Context

Give the model the facts that change the answer.

Useful context can include:

the user or system affected,
the current architecture,
known constraints,
the highest-risk failure,
decisions already made.

Do not paste everything you know. Add only information that should alter the model’s judgement.

3. Constraints

Constraints define the edges of the problem.

Examples:

Do not change the public API.
Use only libraries already in package.json.
Keep the migration reversible.
Do not include personal data in logs.

Without constraints, an AI can produce a technically valid answer that is useless in your environment.

4. Deliverable

Specify the shape of the result.

You might ask for:

a patch,
a decision table,
three options with trade-offs,
a test plan,
a JSON object matching a schema,
a short recommendation followed by evidence.

A clear output format makes the response easier to review and easier to feed into the next step.

5. Acceptance checks

This is the part most prompts miss.

Acceptance checks let the model inspect its own work before returning it.

For example:

Before answering, verify that:
- every recommendation maps to a stated requirement,
- every factual claim has a source,
- the code compiles conceptually with the types shown,
- unresolved assumptions are listed,
- no out-of-scope files are changed.

These checks are not a guarantee. They are a lightweight test suite for the response.

One good example can beat another paragraph of instructions

Developers often use vague role prompts:

Act as a world-class senior software architect.

The model still has to guess what “world-class” means.

A short example is often more useful:

Good finding:
HIGH: retryPayment.ts:84
A timeout after the provider accepts payment can trigger a second charge.
Evidence: the retry path creates a new idempotency key.
Fix: reuse the original key until the operation reaches a terminal state.
Test: simulate provider success followed by a client-side timeout.

Bad finding:
"Improve error handling."
This is too broad and has no failure scenario or code evidence.

The example teaches the model your standard, not merely your aspiration.

Do not solve every AI problem inside the prompt

A prompt becomes bloated when it absorbs responsibilities that belong elsewhere.

Use this simple placement guide:

Information	Better home
Stable rules that apply to every request	System instructions
The current goal and constraints	User prompt or task contract
A reusable procedure	Skill, template, or workflow
Changing facts from documents	Retrieval
Previous decisions and project state	Memory
An action such as searching or running tests	Tool
Proof that the result is acceptable	Evaluator or deterministic check

This matters because each layer changes at a different speed.

Your security rules may stay stable for months. The current task may last ten minutes. A product document may change tomorrow. Mixing all three into one giant prompt makes the system harder to update and debug.

Treat prompts like code

A production prompt deserves the same habits as production software.

Keep representative cases

Collect a small set of real tasks:

a normal case,
an ambiguous case,
a missing-information case,
an adversarial case,
a high-risk case.

Define what good looks like

Do not use “the answer feels better” as your only measure.

Check things such as:

Did it follow the requested format?
Did it use evidence?
Did it respect scope?
Did it expose uncertainty?
Did it avoid a known failure?

Change one thing at a time

When you change the prompt, model, retrieval, and tool set together, you do not know what caused the result.

Prompt work becomes engineering when changes are testable.

A reusable template

GOAL
What outcome should be produced?

CONTEXT
Which facts materially affect the answer?

CONSTRAINTS
What must the model do, avoid, or preserve?

DELIVERABLE
What exact form should the output take?

ACCEPTANCE CHECKS
How should the result be tested before it is returned?

UNCERTAINTY
What should the model do when evidence is missing?

You do not need every heading for every request. The point is to remove the decisions that matter most.

What changes

The future of prompting is not memorising magic phrases.

It is making intent, constraints, and quality visible.

A strong model can fill small gaps. It should not have to invent the definition of success.

What is one prompt you keep making longer when the real problem is a missing acceptance check?

5 Underrated NPM Packages You’re Not Using (But Should Be)

Balraj Singh — Tue, 04 Mar 2025 09:58:50 +0000

The world of NPM is massive. Over 2 million packages, and yet, most developers end up using the same 20-30 over and over again.

React, Lodash, Express. The usual suspects.

But what about the hidden gems? The ones that could make your workflow easier, cleaner, and smarter?

Here are five underrated NPM packages that deserve more attention.

1. `date-fns-tz`

Time zones are annoying. This makes them less so.

If you’ve ever scheduled an event across time zones, you know how quickly things get messy. Moment.js? Bloated. Manually handling offsets? A disaster waiting to happen.

Enter date-fns-tz.

Why it deserves more love:

Built on date-fns, so it’s modular and tree-shakable.
Does one thing well: time zone management.
No unnecessary overhead.

Where it helps:
When you’re building apps that handle scheduling for users in different time zones.

Example:

import { formatInTimeZone } from 'date-fns-tz';

const timeZone = 'America/New_York';
const date = new Date();

const formattedDate = formatInTimeZone(date, timeZone, 'yyyy-MM-dd HH:mm:ssXXX');
console.log(formattedDate); // 2024-11-25 10:00:00-05:00

2. `clsx`

Writing messy className logic? Stop. Use this.

If you’ve written dynamic className logic in React, you’ve probably seen something like this:

const buttonClass = `btn ${isActive ? 'btn-active' : ''} ${isDisabled ? 'btn-disabled' : ''}`;

It works. But it’s ugly.

Enter clsx. A tiny utility that makes class name logic elegant.

Why you need this:

Handles conditional logic, arrays, and objects effortlessly.
Automatically ignores falsy values.
Makes your UI code cleaner and more readable.

Example:

import clsx from 'clsx';

const isActive = true;
const isDisabled = false;

const buttonClass = clsx('btn', { 'btn-active': isActive, 'btn-disabled': isDisabled });
console.log(buttonClass); // "btn btn-active"

3. `ow`

Validation that doesn’t make you want to quit coding.

If you’ve written input validation manually, you know it gets repetitive fast.

ow, by Sindre Sorhus, makes it simple and declarative.

Why it’s underrated:

TypeScript-friendly with strong error messages.
Expressive syntax that reads like English.
Handles complex validations in a single line.

Where it helps:
Validating API responses, CLI inputs, or function arguments.

Example:

import ow from 'ow';

const validateUser = (user) => {
  ow(user, ow.object.exactShape({
    name: ow.string.minLength(3),
    age: ow.number.integer.positive,
    email: ow.string.url,
  }));
};

validateUser({ name: 'John', age: 25, email: 'example@example.com' }); // Passes

4. `npm-check`

Your node_modules is a mess. This fixes it.

Have you ever wondered:

Which dependencies are outdated?
Which ones are unused?
Which ones you accidentally forgot to install?

npm-check gives you an interactive way to clean things up.

Why it’s useful:

Finds outdated, unused, or missing dependencies.
Works interactively, so you can update/uninstall with a keystroke.
Works with both local and global packages.

Example:

npx npm-check

Run that command, and you’ll get a nice interactive list of dependencies with options to update or remove them.

5. `log-symbols`

Make your CLI logs actually readable.

Ever built a CLI tool and thought, this looks so plain?

log-symbols adds intuitive icons (✅ ❌ ⚠️) to your logs, making them clearer at a glance.

Why you should use it:

Gives instant visual feedback in the terminal.
Works across macOS, Linux, and Windows.
Small but powerful.

Example:

import logSymbols from 'log-symbols';

console.log(logSymbols.success, 'Build completed successfully!');
console.log(logSymbols.error, 'Failed to connect to the database.');
console.log(logSymbols.warning, 'Using default configuration.');

Don’t just use what’s popular. Use what makes your life easier.

The next time you find yourself repeating code or struggling with a common problem, take a detour into the lesser-known corners of NPM.

What’s your favorite underrated NPM package?

Modern JavaScript Patterns You’ll Want to Use in 2025.

Balraj Singh — Tue, 25 Feb 2025 09:54:12 +0000

JavaScript is always changing. Some patterns stick around, some fade, and some evolve into something we never saw coming.

Here’s a breakdown of the JavaScript patterns.

1. Pattern Matching (Early Proposal Stage, But Promising)

Think of switch statements—but better. Pattern matching, inspired by languages like Haskell and Scala, makes handling complex branching logic way cleaner.

❗ Where it stands: Still in Stage 1 of the TC39 Pattern Matching Proposal, meaning it’s experimental and far from being implemented in JavaScript yet.

📌 Why it matters:

✔️ Reduces boilerplate

✔️ Makes conditions more readable

✔️ Handles nested destructuring elegantly

Takeaway: If this gets approved in the future, it’ll make switch feel like a relic.

2. Decorators (Closer to Standardization)

Decorators allow you to wrap functions & classes with extra functionality.

📌 Where it stands: Now in Stage 3, meaning it’s closer to being finalized. TC39 Proposal

📌 Why it matters:

✔️ Cleaner than traditional wrappers

✔️ Perfect for logging, permissions, & class enhancements

Takeaway: If you use TypeScript, start experimenting now.

3. Module Federation (Micro-Frontend Hype)

Micro-frontends are here, and Webpack 5’s Module Federation is making it easier than ever.

📌 Why it matters:

✔️ Teams can deploy different parts of an app independently

✔️ Works well for large-scale applications

🔗 How it works: Webpack Docs

Takeaway: If you're working on a multi-team project, this is a must-know.

4. Proxy-Based Observables (Reactivity Without a Framework)

Vue.js made reactive programming cool, but JavaScript itself doesn’t provide built-in observable support yet. Instead, developers are using Proxy-based reactivity for lightweight state tracking.

📌 Why it matters:

✔️ Lets you watch changes dynamically

✔️ Eliminates heavy state management libraries

Example:

const handler = {
  set(obj, prop, value) {
    console.log(`${prop} changed to ${value}`);
    obj[prop] = value;
  }
};

const data = new Proxy({ name: "Alice" }, handler);
data.name = "Bob"; // Logs: "name changed to Bob"

Takeaway: Expect to see lightweight reactivity without frameworks.

5. Immutable Data Patterns (Avoiding Side Effects)

More teams are moving away from mutation and towards immutable state management, but JavaScript does not natively enforce immutability. Instead, libraries like Immutable.js and Immer help achieve this.

📌 Why it matters:

✔️ Helps prevent unpredictable side effects

✔️ Makes debugging easier

🔗 Deep dive: Immutable.js

Takeaway: Functional programming principles are not just hype—they actually help.

Which of these patterns do you already use? Let me know in the comments.

10 Hidden Gems in GitHub Actions for Automating Your Workflow

Balraj Singh — Wed, 19 Feb 2025 10:40:05 +0000

GitHub Actions has changed the game for automation. CI/CD, testing, and deployments? Sure, those are the basics.

But what if I told you there’s a whole world of underrated Actions that can make your workflow smoother, faster, and—dare I say—effortless?

Here are 10 lesser-known but insanely useful GitHub Actions you should be using.

1. YAML Validator

YAML is everywhere in automation, but one indentation mistake and boom—your pipeline is broken. This Action catches errors before you commit them.

Why it’s a game-changer:

Saves you from debugging nightmare-inducing YAML misconfigurations.
Essential for Kubernetes, GitHub workflows, and CI/CD.

- name: Validate YAML
  uses: ibiqlik/action-yaml-lint@v3
  with:
    config_file: '.yamllint'

2. Markdown Link Checker

Ever had a README full of broken links? This Action scans your Markdown files and flags dead links before they embarrass you.

Perfect for:

Keeping documentation flawless.
Avoiding those awkward “this link is broken” messages from users.

- name: Check Markdown Links
  uses: gaurav-nelson/github-action-markdown-link-check@v1

3. Auto Assign PRs

Stop manually assigning PRs. This Action does it for you based on predefined rules.

Why you need it:

Saves time, especially for teams handling multiple PRs daily.
Ensures code reviews don’t get lost in the shuffle.

- name: Auto Assign PR
  uses: kentaro-m/auto-assign-action@v1
  with:
    assignees: 'team-lead'
    reviewers: 'senior-dev'

4. Commitlint

Messy commit messages make tracking changes painful. This Action enforces consistency.

Best for:

Teams following Conventional Commits.
Keeping changelogs neat and versioning structured.

- name: Commitlint
  uses: wagoid/commitlint-github-action@v5

5. Cache Dependencies

Dependency installation slowing down your builds? This Action caches them, making CI runs significantly faster.

Where it shines:

Large Node.js/Python/Ruby projects.
Reducing build times in active development environments.

- name: Cache Node Modules
  uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

6. Notify Slack

Stop refreshing GitHub to check workflow statuses. This Action sends real-time Slack notifications for builds, tests, and deployments.

Great for:

Keeping teams updated instantly.
Catching failed deployments before they cause chaos.

- name: Notify Slack
  uses: rtCamp/action-slack-notify@v2
  with:
    webhook-url: ${{ secrets.SLACK_WEBHOOK }}
    message: "Deployment Status: ${{ job.status }}"

7. License Compliance Checker

If your project depends on external libraries, you need to ensure all licenses are compliant. This Action does the checking for you.

Ideal for:

Open-source projects.
Enterprise teams with strict licensing policies.

- name: License Check
  uses: anchorfree/license-check-action@v2

8. Pull Request Size Labeler

Helps reviewers by labeling PRs based on size—small, medium, large.

Why it’s useful:

Lets teams prioritize quick PRs.
Prevents massive, unmanageable PRs from slipping through.

- name: PR Size Labeler
  uses: kentaro-m/size-label-action@v3

9. Security Scan with Trivy

Security is a non-negotiable. Trivy scans your container images and dependencies for vulnerabilities before they become a problem.

Use it for:

Keeping your Docker images secure.
Identifying vulnerable dependencies before deployment.

- name: Security Scan
  uses: aquasecurity/trivy-action@v0.3.0
  with:
    image-ref: myapp:latest

10. GitHub Actions for JIRA Integration

If your team uses JIRA, this Action automatically updates tickets based on GitHub commits and PRs.

Why it matters:

Keeps your development and project management teams aligned.
Reduces manual updates and keeps issues moving.

- name: Update Jira Issue
  uses: atlassian/gajira-create@v3
  with:
    project: "ENG"
    issuetype: "Task"
    summary: "Automated issue update from GitHub Action"
    description: "Linked PR: ${{ github.event.pull_request.html_url }}"

Which one are you adding to your workflow?

10 Git Commands You’ll Wish You Knew Earlier

Balraj Singh — Mon, 17 Feb 2025 09:20:23 +0000

Git can be intimidating when you’re just starting out. Most developers stick to git add, git commit, and git push, and for the most part, that’s enough—until you run into a problem you don’t know how to fix.

That’s when these 10 Git commands can save you time and frustration.

1. `git reflog` – Recover Lost Commits

Sometimes, you accidentally delete a branch or reset to the wrong commit. git reflog lets you go back in time and recover lost work.

What it does: Tracks every change made in the repository, even those you thought were gone.

When to use:

You accidentally deleted a branch.
You need to recover a commit after a bad reset.

Command:

git reflog

2. `git cherry-pick` – Apply Specific Commits

You need a commit from another branch but don’t want to merge everything. git cherry-pick brings in only the commit you need.

What it does: Lets you apply a specific commit from one branch to another.

When to use:

You need a bug fix from a different branch without merging unnecessary changes.

Command:

git cherry-pick <commit-hash>

3. `git bisect` – Find the Problematic Commit

When a bug appears but you don’t know which commit introduced it, git bisect helps you track it down efficiently.

What it does: Uses binary search to identify the commit that caused an issue.

When to use:

You need to find which commit introduced a bug.

Command:

git bisect start
git bisect bad  # Mark the current commit as bad
git bisect good <commit-hash>  # Mark a known good commit

Git will guide you through commits until the problem is found.

4. `git stash pop` – Switch Tasks Without Losing Work

You’re in the middle of coding, and suddenly, you need to switch branches. git stash pop lets you do that without losing progress.

What it does: Saves your uncommitted changes so you can apply them later.

Why pop instead of stash? It applies the saved changes and removes them from the stash list automatically.

Command:

git stash pop

5. `git reset --soft` – Undo a Commit Without Losing Changes

You committed too early, and now you need to modify the commit. git reset --soft moves the commit back to the staging area.

What it does: Allows you to edit a commit without losing your changes.

When to use:

You need to modify the last commit before pushing.

Command:

git reset --soft HEAD~1

6. `git blame` – Track Changes to a File

If you’re trying to understand why a certain change was made, git blame shows you the last modification for each line in a file.

What it does: Displays commit history for each line of a file.

When to use:

You want to know who changed a specific line of code.

Command:

git blame <file>

7. `git log --oneline --graph` – A Clearer History View

Repositories with multiple branches can get messy. This command gives a simplified visual overview of the commit history.

What it does: Shows commits in a structured, easy-to-read format.

When to use:

You need to understand how branches diverged and merged.

Command:

git log --oneline --graph --all

8. `git clean -f` – Remove Untracked Files

If your working directory is cluttered with untracked files, git clean -f helps clean it up.

What it does: Deletes untracked files from your working directory.

When to use:

You have untracked files interfering with your work.

Command:

git clean -f

9. `git rebase -i` – Edit Your Commit History

When you need to clean up your commits before merging, git rebase -i lets you squash, edit, or delete commits.

What it does: Allows you to modify commit history interactively.

When to use:

Before merging, to make your commit history look structured and clear.

Command:

git rebase -i HEAD~<number-of-commits>

Note: Avoid using this on public branches—it rewrites history and can cause conflicts.

10. `git diff --staged` – Review Staged Changes

Before committing, you may want to double-check what you’re about to push. git diff --staged shows exactly that.

What it does: Displays changes between the staging area and the last commit.

When to use:

You want to verify staged changes before committing.

Command:

git diff --staged

Hope this helps!

Do you have a go-to Git command that isn’t on this list? Let’s discuss in the comments!

How to Write Clean Code: Refactoring and Best Practices

Balraj Singh — Thu, 13 Feb 2025 10:05:18 +0000

Let’s be honest, every developer (yes, even the ones with years of experience) has shipped messy code at some point.

Writing clean code isn’t some elite skill. It’s a habit you can build. And refactoring? That’s just your chance to make your code actually make sense—both to you and whoever gets stuck maintaining it later.

Let’s break it down. No fluff. No abstract theory. Just practical, real-world tips to help you write clean, maintainable code.

1. Name Things Like You Mean It
Your variables and functions need to tell a story.

Not x, not temp, not data. Those are just placeholders for confusion.

✅ Good: getUserProfile()

❌ Bad: getData()

✅ Good: maxLoginAttempts

❌ Bad: m

When you name things well, your code explains itself—no detective work required.

2. Less Is More: The Power of Function Size

If you’re scrolling through a function like it’s an essay, something’s wrong.

Long functions are hard to read, hard to debug, and hard to maintain. Instead, break them down into smaller, single-purpose functions.

Think of it like this: each function should answer one question. If it’s answering five, break it apart.

Example:

// Instead of this
function processUserData(user) {
  validateUser(user);
  saveToDatabase(user);
  sendEmail(user.email);
}

// Do this
function validateAndSaveUser(user) {
  validateUser(user);
  saveToDatabase(user);
}

function notifyUser(email) {
  sendEmail(email);
}

This makes your code easier to read and reuse. Future-you will thank you.

3. Consistency Is Key

Ever worked on a project where userList was called users in one place and activeUsersArray in another? Chaos.

Keep naming conventions, indentation, and formatting consistent. When your code follows a predictable pattern, it’s easier to read—and easier to debug.

✅ Good: userList, orderList, productList
❌ Bad: users, ordersList, listOfProducts

Pick a convention and stick to it. No surprises.

4. Comment With Purpose, Not Out of Habit

Comments should explain why, not what. If your code needs a comment to explain what it does, rewrite the code instead.

Example:

// ❌ Bad Comment
// Increase count by 1
count = count + 1;

// ✅ Good Comment
// Edge case: Prevents counter from going negative
if (count > 0) {
  count--;
}

Write comments that add value, not ones that state the obvious.

5. Magic Numbers and Hardcoded Values – Get Rid of Them

Ever seen a function with random numbers thrown in? Yeah, it’s a maintenance nightmare.

Instead, use constants that make these values meaningful.

Example:

// ❌ Bad
if (user.loginAttempts > 3) {
  lockAccount(user);
}

// ✅ Good
const MAX_LOGIN_ATTEMPTS = 3;
if (user.loginAttempts > MAX_LOGIN_ATTEMPTS) {
  lockAccount(user);
}

Much better.

6. DRY: Don’t Repeat Yourself

Repetitive code is just waiting to break. If you find yourself copy-pasting, stop. Create reusable functions or modules instead.

Example:

// ❌ Bad: Duplicated logic
sendEmail(user.email, "Welcome!");
sendEmail(admin.email, "New user registered!");

// ✅ Good: Reusable function
function sendNotification(email, message) {
  sendEmail(email, message);
}
sendNotification(user.email, "Welcome!");
sendNotification(admin.email, "New user registered!");

This way, when changes are needed, you only have one place to update.

7. Keep Your Code SOLID

If you haven’t heard of SOLID principles, now’s a good time to start. These are five simple rules that make your code cleaner and easier to maintain.

If nothing else, start with this: The Single Responsibility Principle.

➡ Each function/class should do ONE thing and do it well.

If your class is handling both user authentication and database storage, it’s time for a refactor.

8. Refactor Ruthlessly
Writing clean code isn’t a one-and-done thing. It’s a habit.

Every time you review your code, look for ways to make it better:

Can you rename variables for clarity?
Can you break down a huge function?
Can you remove unnecessary comments?

Don’t wait for a major rewrite—refactor as you go.

Example:

// ❌ First draft
function fetchUserData(userId) {
  return fetch(`https://api.example.com/user/${userId}`)
    .then(response => response.json())
    .catch(error => console.error(error));
}

// ✅ Refactored
async function fetchUserData(userId) {
  try {
    const response = await fetch(`https://api.example.com/user/${userId}`);
    return await response.json();
  } catch (error) {
    console.error(error);
  }
}

Refactoring doesn’t mean your first attempt was bad—it means you’re making it better.

If you can:
✅ Name things clearly

✅ Keep functions small

✅ Stay consistent

✅ Avoid hardcoded values

✅ Refactor often

…you’re already way ahead of the game.

10 DeepSeek R1 Prompts for Coding That Actually Save You Time.

Balraj Singh — Mon, 10 Feb 2025 18:25:33 +0000

Most people don’t know how to prompt AI properly.

They type something vague like “Optimize this JavaScript function” and expect groundbreaking results. Then, when they get a slightly cleaner version of what they already wrote, they think, AI isn’t that great.

AI is only as good as your prompts.

DeepSeek R1 is powerful. It understands code well, but if you’re not framing your questions correctly, you’re leaving value on the table.

These 10 prompts will help you get the best possible output—cleaner, faster, and actually useful.

1. “Refactor this function for better performance. Explain each change.”

A vague "optimize this" won’t cut it. You want clear improvements with reasoning so you actually understand what’s being changed.

🟢 Better prompt:

"Refactor this function to improve performance and maintainability. Explain each change in detail, focusing on execution time, readability, and memory efficiency."

This forces DeepSeek R1 to not just rewrite code but also justify every modification.

2. “Identify potential memory leaks in this JavaScript code.”

Memory leaks slow down applications and are hard to spot. Let DeepSeek R1 do the heavy lifting.

🟢 Better prompt:

"Analyze this JavaScript function for potential memory leaks. Point out what’s causing them and suggest fixes."

You’ll get targeted optimizations instead of a generic best-practices list.

3. “Rewrite this SQL query for better performance. Explain the changes.”

Databases get sluggish when queries are inefficient. Asking for a rewrite without explanation means you’ll end up copy-pasting without learning.

🟢 Better prompt:

"Optimize this SQL query for speed. Prioritize reducing execution time and improving index usage. Explain each improvement step by step."

This gets you performance gains you can actually apply elsewhere.

4. “Write unit tests for this function covering all edge cases.”

If you just ask AI to write tests, it’ll generate happy path scenarios and call it a day. You need to force it to dig deeper.

🟢 Better prompt:

"Write comprehensive unit tests for this function in Jest, ensuring all edge cases (invalid inputs, boundary conditions, unexpected data types) are covered."

Your tests will go from basic to robust.

5. “Debug this error and explain what’s causing it.”

Copy-pasting errors into Google works, but DeepSeek R1 can debug faster if you give it the right context.

🟢 Better prompt:

"I’m getting this error in my Next.js app: [Insert error]. Analyze the issue and explain what’s going wrong in simple terms."

Instead of random StackOverflow answers, you’ll get a direct fix with an explanation.

6. “Convert this JavaScript function to TypeScript with proper types.”

Most AI-generated TypeScript code is lazy. It just slaps an any type on everything. That’s not useful.

🟢 Better prompt:

"Convert this JavaScript function into TypeScript, ensuring strict type safety. Avoid using 'any' and infer types where possible."

This forces DeepSeek R1 to do actual type inference instead of taking shortcuts.

7. “Rewrite this function using functional programming principles.”

If you just ask AI to refactor code, it’ll slightly clean it up but won’t shift paradigms. To enforce a different approach, you need to be specific.

🟢 Better prompt:

"Refactor this function to follow functional programming principles. Use pure functions, immutability, and avoid side effects."

This gives you a structural shift, not just minor tweaks.

8. “Optimize this React component to minimize unnecessary re-renders.”

React re-renders kill performance. AI won’t prevent them unless you specifically ask it to.

🟢 Better prompt:

"Identify why this React component is re-rendering unnecessarily and optimize it using memoization, useCallback, or other best practices."

You’ll get targeted solutions instead of basic ‘useMemo’ suggestions.

9. “Explain this complex code to me like I’m a junior developer.”

Ever come across code that looks like an alien language? AI can break it down for you—if you ask the right way.

🟢 Better prompt:

"Here’s a function that does X. Explain its logic in a simple, step-by-step way, as if you’re teaching a beginner."

This makes AI act like a mentor, not just a code generator.

10. “Rewrite this Python script in Node.js while maintaining efficiency.”

AI translates code line by line unless you tell it otherwise. That often leads to inefficient conversions.

🟢 Better prompt:

"Convert this Python script into an optimized Node.js implementation, ensuring equivalent functionality while following best practices for event-driven programming."

Instead of blind translation, you get a version that actually makes sense in Node.js.

If you feed it weak prompts, you’ll get weak results. The way you phrase your request determines whether you get something useful or something generic.

Try these prompts the next time you use DeepSeek R1. You’ll see the difference instantly.

10 Underrated Swift Features You Probably Aren’t Using (But Should)

Balraj Singh — Wed, 05 Feb 2025 10:44:12 +0000

Swift is packed with cool tricks that often go unnoticed. While everyone obsesses over async/await and SwiftUI, there are plenty of low-key features that can make your life easier if only more people knew about them. So, let’s talk about those.

1. some Keyword for Type Opaqueness

You’ve probably used Any to deal with unknown types. But have you used some? It lets you return an opaque type without exposing unnecessary details. Less clutter, more clarity.

Example:

func makeButton() -> some View {
    Button("Tap Me") {
        print("Button tapped!")
    }
}

This matters because without some, generics can turn into a tangled mess really fast.

2. @autoclosure for Cleaner Lazy Evaluations

Instead of wrapping expressions inside {} for no reason, let @autoclosure handle it for you.

Example:

func logIfNeeded(_ message: @autoclosure () -> String) {
    #if DEBUG
    print(message())
    #endif
}

This way, you can just pass "Some log message" without worrying about closures.

3. @discardableResult to Avoid Unused Result Warnings

Sometimes, you call a function for its side effects and don’t care about the return value. But Swift does.

Example:

@discardableResult
func performTask() -> Bool {
    return true
}

Now you won’t see warnings for ignoring the return value. Simple fix.

4. @inline(__always) for Performance Boost

If you care about performance, this forces inlining, even when the compiler doesn’t think it’s necessary.

Example:

@inline(__always)
func fastFunction() {
    print("This will always be inlined!")
}

It’s a small optimization, but for high-performance apps, small tweaks add up.

5. Conditional Conformance for Generics

Swift allows types to conform to protocols only when certain conditions are met.

Example:

extension Array: Equatable where Element: Equatable {}

Now, arrays of Equatable elements can be compared directly. Before this, you had to manually implement Equatable. Not fun.

6. withoutActuallyEscaping(_:) for Non-Escaping Closures

Got a non-escaping closure but need to pass it somewhere that expects an escaping one? Swift has a trick for that.

Example:

func execute<T>(_ closure: (T) -> Void, with value: T) {
    withoutActuallyEscaping(closure) { escapable in
        escapable(value)
    }
}

This keeps things type-safe without the usual @escaping gymnastics.

7. defer for Guaranteed Cleanup

You’ve probably seen finally in other languages. Swift’s defer is even better—it always runs, no matter how the function exits.

Example:

func fetchData() {
    defer { print("Cleanup executed") }
    print("Fetching data...")
}

No matter what happens, cleanup is handled. No surprises.

8. ExpressibleBy*Literal for Custom Types

Ever wanted to assign literals to your custom structs? You can.

Example:

struct Temperature: ExpressibleByFloatLiteral {
    var value: Double
    init(floatLiteral value: Double) {
        self.value = value
    }
}
let temp: Temperature = 36.6  // Works because of ExpressibleByFloatLiteral

Now you don’t have to write Temperature(value: 36.6). Just use 36.6. Neat, right?

9. mutating func in Structs

Structs are immutable by default. But what if you need to modify them? mutating lets you do it safely.

Example:

struct Counter {
    var count = 0
    mutating func increment() {
        count += 1
    }
}

Still keeps your code clean and predictable while allowing changes where necessary.

10. lazy Properties for Efficient Initialization

Why initialize a heavy object if you might not even use it? lazy postpones initialization until it’s actually needed.

Example:

class ExpensiveObject {
    init() { print("Expensive Object Created") }
}
class MyClass {
    lazy var expensiveInstance = ExpensiveObject()
}
let obj = MyClass()  // Nothing happens yet
obj.expensiveInstance  // Now the instance is created

This avoids unnecessary resource allocation. Especially useful in UI-heavy apps.

The best part is that most of them require just one extra keyword to start using.

7 Swift Hacks You Wish You Knew Sooner

Balraj Singh — Mon, 03 Feb 2025 10:02:35 +0000

You know that feeling when you write a code, only to realize later, there was a one-liner that could’ve done the same job? Yeah, me too.

Swift is full of underrated gems.

So here are 7 Swift hacks you’ll wish you knew sooner.

1. Format Numbers Without the Extra Work

Manually formatting numbers? Nope. Swift has a built-in way:

let formatted = NumberFormatter.localizedString(from: 1234567, number: .decimal)
print(formatted) // "1,234,567"

Works for currency, percentages, and scientific notation too.

2. The 'One-Liner' if let Trick

Before:

if let username = username {
    print(username)
}

Now:

username.map { print($0) }

Why? Cleaner, more functional, and no unnecessary nesting.

3. Force a SwiftUI View to Refresh Instantly

SwiftUI sometimes just… doesn’t refresh when you expect it to. Instead of overcomplicating state management, do this:

someStateVariable.toggle() // Forces view to re-render

No extra logic, no unnecessary bindings. Just works.

4. Auto-Resizing Text Fields Without Extra Code

Tired of writing logic for resizing text fields? Here’s the fix:

TextField("Enter text", text: $text)
    .frame(minHeight: 40)
    .padding()
    .background(Color.gray.opacity(0.1))
    .cornerRadius(10)

What happens? The field grows/shrinks dynamically. No extra logic needed.

5. Turn a Dictionary into a URL Query String Instantly

No need to manually construct query strings. This one-liner handles it:

let params = ["search": "Swift Hacks", "limit": "10"]
let query = params.map { "\($0.key)=\($0.value)" }.joined(separator: "&")
print(query) // "search=Swift Hacks&limit=10"

Time saved. Code cleaner.

6. Ditch the Long if Statements with switch

Instead of multiple conditions, simplify it like this:

switch value {
case 1...10: print("Low")
case 11...20: print("Medium")
case 21...: print("High")
default: print("Unknown")
}

Easier to read. Faster to debug.

7. Lazy-Load Expensive Functions

Instead of executing an expensive function right away, delay it:

func fetchData(_ loader: @autoclosure () -> String) {
    print("Fetching Data: \(loader())")
}

fetchData(expensiveFunctionCall()) // Runs only when needed

Performance boost, especially in bigger apps.

That’s it—7 Swift hacks to simplify your code and speed up your workflow.

Hope this helps!

Top 10 Python Libraries That Will Save You Hours of Work.

Balraj Singh — Fri, 31 Jan 2025 10:50:45 +0000

If you write Python code regularly, you know that some tasks can be painfully repetitive.

Python has some incredibly powerful libraries that can save you hours (or even days) of work. The problem? Most people keep using the same mainstream ones—NumPy, Pandas, and Requests—without realizing there are hidden gems that can automate, optimize, and simplify a lot of tasks.

So here’s a list of 10 Python libraries that can help you get things done faster.

1. Rich – Stop Using Boring Print Statements

Rich is a game-changer for beautifully formatted console logs. It lets you print tables, syntax-highlighted code, markdown, and even progress bars. Perfect for debugging or making CLI tools visually appealing.

Time saved: No more ugly print debugging or manually formatting tables.

from rich.console import Console
console = Console()
console.print("Hello, [bold magenta]Rich![/bold magenta]")

2. Typer – Writing CLIs the Easy Way

If you’ve ever struggled with argparse, you’re going to love Typer. It’s based on FastAPI’s structure and makes it ridiculously easy to build command-line interfaces.

Time saved: No more manually parsing command-line arguments. Just type hint your functions and Typer does the rest.

import typer
app = typer.Typer()
@app.command()
def hello(name: str):
    print(f"Hello {name}")
app()

3. Polars – A Faster Alternative to Pandas

If your Pandas operations feel slow, Polars is the upgrade you need. It’s a blazingly fast DataFrame library that can handle large datasets more efficiently.

Time saved: Significantly reduced processing time for big data.

import polars as pl
df = pl.read_csv("data.csv")
df.filter(pl.col("age") > 30)

4. FastAPI – The Modern Way to Build APIs

Django and Flask are great, but FastAPI is a whole different level. It’s fast, has built-in validation, and generates API docs automatically.

Time saved: Less boilerplate, automatic validation, and speedier performance.

from fastapi import FastAPI
app = FastAPI()
@app.get("/")
def read_root():
    return {"message": "Hello, FastAPI!"}

5. Pydantic – Stop Writing Manual Data Validation

If you hate writing manual validation logic, Pydantic is your best friend. It allows you to define data models with automatic validation using Python type hints.

Time saved: No need to write complex validation functions.

from pydantic import BaseModel
class User(BaseModel):
    name: str
    age: int
user = User(name="John", age="25")  # Raises validation error

6. Loguru – Logging Made Ridiculously Simple

Python’s built-in logging module is powerful but overcomplicated. Loguru makes logging as easy as writing a print statement.

Time saved: No need to configure complex logging settings.

from loguru import logger
logger.info("This is an info message")

7. TQDM – Add Progress Bars with Zero Effort

If you work with loops that take time, TQDM is a must-have. It lets you add progress bars to your loops with a single line.

Time saved: Makes long-running loops visually trackable.

from tqdm import tqdm
for i in tqdm(range(100)):  
    pass  # Your logic here

8. Shapely – Work with Geometric Objects Effortlessly

If you deal with geospatial data, Shapely makes working with geometric objects a breeze.

Time saved: No need to manually compute intersections, distances, or shapes.

from shapely.geometry import Point
point = Point(1.0, 2.0)
print(point.x, point.y)

9. Pytest – Write Better Tests, Faster

Forget about Python’s built-in unittest. Pytest makes writing and running tests intuitive and efficient.

Time saved: Cleaner syntax, auto-discovery, and better debugging.

def test_example():
    assert 2 + 2 == 4

Run all tests with a single command:

pytest

10. Playwright – Automate Browser Actions Like a Pro

For web scraping or automated testing, Playwright is a powerful alternative to Selenium.

Time saved: Faster execution, headless browsing, and better handling of modern web apps.

from playwright.sync_api import sync_playwright
with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto("https://example.com")
    print(page.title())
    browser.close()

If you find yourself repeating certain tasks, look for a Python library that can automate or simplify it. Chances are, someone has already built the solution for you.

Which of these libraries have you used? Got any more time-saving Python gems? Drop them in the comments!

Everyone Teaches Coding, But No One Talks About These 5 Skills Developers Actually Need.

Balraj Singh — Tue, 28 Jan 2025 14:41:25 +0000

Coding bootcamps, YouTube tutorials, and online courses have one thing in common: they teach you how to write code. But ask any seasoned developer, and they’ll tell you—writing code is just one thing. The reality of being a developer is far messier, more nuanced, and requires a set of skills that no tutorial will ever truly cover.

Here’s what nobody is talking about: the five skills that separate average developers from exceptional ones. If you’re tired of generic advice like "learn data structures" or "master algorithms," this one’s for you.

1. The Art of Asking the Right Questions

Ever heard of "rubber duck debugging"? Developers joke about explaining their code to a rubber duck to find bugs. But here’s the deeper truth: your ability to ask questions is directly tied to your ability to solve problems.

When you’re stuck on a feature, the solution quickly often comes down to asking the right questions:

What assumptions am I making about this code?
What happens if I handle this edge case differently?
Have I truly understood the user’s needs, or am I guessing?

Stop memorizing syntax—learn how to interrogate your own thought process.

2. The Skill of Reading Between the Lines (a.k.a. Reading Code)

Writing code is glamorized. Reading code? Not so much.

But let me tell you: most of your career will involve someone else’s mess or revisiting your own cryptic comments from six months ago. Reading code isn’t just a technical skill—it’s an exercise in empathy.

To read code effectively, you need:

Pattern recognition: Spot how the codebase organizes logic, handles errors, or repeats patterns.
Context awareness: Understand why something was written that way, not just how.
Curiosity: Ask yourself, “What problem does this code solve? Is it still relevant?”

3. Mastering the Non-Technical: Communication

Hot take: The biggest bugs in software often come from miscommunication, not bad code.

You’re not just building software; you’re translating someone’s abstract idea into functional reality. This means you need to:

Listen actively: Understand what stakeholders really want, not just what they say they want.
Write clearly: Your documentation, comments, and commit messages should make sense to a future you (or anyone else).
Collaborate effectively: Whether it’s pair programming or debating architecture choices in a meeting, your ability to communicate makes or breaks the project.

Pro tip: Practice explaining technical concepts to non-technical people. It’ll sharpen your understanding and make you a better developer.

4. Don't Freak Out

Here’s a reality check: you will never have all the answers upfront.

Specs will be incomplete. The client’s requirements will change mid-sprint. The library you’re using might suddenly become unmaintained. The ability to stay calm, adapt, and navigate uncertainty is what sets the pros apart.

How to build this skill:

Learn to prototype quickly: Build small, disposable versions to clarify vague requirements.
Document assumptions: Write down what you think you know and revisit it as the project evolves.
Be okay with being wrong: Iteration is the name of the game.

5. Thinking Beyond the Code: Systems Thinking

Developers often obsess over their immediate task: Build this feature. Fix that bug. But exceptional developers see the bigger picture. They think in systems.

Systems thinking means:

Understanding how your code impacts the performance, scalability, and maintainability of the entire application.
Considering edge cases, failure points, and how your feature integrates with other parts of the system.
Thinking about the user’s journey beyond just the screen you’re coding.

For example, let’s say you’re optimizing a database query. A systems thinker won’t stop at making the query faster; they’ll ask:

How does this query impact the overall server load?
What happens if traffic spikes tomorrow?
Is this optimization worth the trade-off in readability or maintainability?

So, the next time you’re grinding through another coding tutorial, pause and ask yourself: Am I learning how to code? Or am I learning how to be a developer?

Big difference.

DEV Community: Balraj Singh

Your Context Window Is Not a Knowledge Base

Context is an attention budget

The seven layers of useful context

1. System instructions: stable behaviour

2. Task contract: the current job

3. Examples: the quality bar

4. Retrieval: changing evidence

5. Working memory: state that must survive

6. Tools: possible actions

7. Recent history: local continuity

A simple context compiler

Five common context failures

1. Context omission

2. Context pollution

3. Context conflict

4. Context staleness

5. Context leakage

Long tasks need context management, not just a larger window

Compaction

Structured notes

Context isolation

The four-C filter

Context engineering in one sentence

Further reading

Stop Writing Bigger Prompts. Start Writing Better Task Contracts

A prompt asks. A task contract defines success.

Prompt A

Prompt B

The five parts of a task contract

1. Goal

2. Context

3. Constraints

4. Deliverable

5. Acceptance checks

One good example can beat another paragraph of instructions

Do not solve every AI problem inside the prompt

Treat prompts like code

Keep representative cases

Define what good looks like

Change one thing at a time

A reusable template

What changes

Further reading

5 Underrated NPM Packages You’re Not Using (But Should Be)

1. date-fns-tz

2. clsx

3. ow

4. npm-check

5. log-symbols

Modern JavaScript Patterns You’ll Want to Use in 2025.

1. Pattern Matching (Early Proposal Stage, But Promising)

2. Decorators (Closer to Standardization)

3. Module Federation (Micro-Frontend Hype)

4. Proxy-Based Observables (Reactivity Without a Framework)

5. Immutable Data Patterns (Avoiding Side Effects)

10 Hidden Gems in GitHub Actions for Automating Your Workflow

1. YAML Validator

2. Markdown Link Checker

3. Auto Assign PRs

4. Commitlint

5. Cache Dependencies

6. Notify Slack

7. License Compliance Checker

8. Pull Request Size Labeler

9. Security Scan with Trivy

10. GitHub Actions for JIRA Integration

10 Git Commands You’ll Wish You Knew Earlier

1. git reflog – Recover Lost Commits

2. git cherry-pick – Apply Specific Commits

3. git bisect – Find the Problematic Commit

4. git stash pop – Switch Tasks Without Losing Work

5. git reset --soft – Undo a Commit Without Losing Changes

6. git blame – Track Changes to a File

7. git log --oneline --graph – A Clearer History View

8. git clean -f – Remove Untracked Files

9. git rebase -i – Edit Your Commit History

10. git diff --staged – Review Staged Changes

How to Write Clean Code: Refactoring and Best Practices

Example:

1. `date-fns-tz`

2. `clsx`

3. `ow`

4. `npm-check`

5. `log-symbols`

1. `git reflog` – Recover Lost Commits

2. `git cherry-pick` – Apply Specific Commits

3. `git bisect` – Find the Problematic Commit

4. `git stash pop` – Switch Tasks Without Losing Work

5. `git reset --soft` – Undo a Commit Without Losing Changes

6. `git blame` – Track Changes to a File

7. `git log --oneline --graph` – A Clearer History View

8. `git clean -f` – Remove Untracked Files

9. `git rebase -i` – Edit Your Commit History

10. `git diff --staged` – Review Staged Changes