Coder Legion - Recent posts tagged developer

💬 Developers: Would you ship AI-generated code without reviewing it first?

Mon, 19 Oct 2026 03:21:00 +0000

Vibe coding can turn an idea into a working prototype in minutes. But a successful demo doesn't guarantee reliable, secure, production-ready software. 🚀

Here's the real challenge: How do you know the code is actually correct?

🧪 Automated tests
🔍 Code review
🔐 Security and dependency checks
⚙️ Real-world validation

💡 The developer takeaway: Don't measure AI coding success by how quickly code is generated. Measure it by how reliably that code works, how safely it runs, and how confidently you can maintain it.

AI can accelerate development. Engineering discipline makes the result dependable.

👇 Let's discuss:

Which AI coding tool has earned your trust?
What's your must-have check before merging AI-generated code?

Share your real-world experience. Let's exchange practical insights—not just tool hype.

📖 SEOSiri's guide to vibe coding tools and code accuracy:
https://www.seosiri.com/2026/10/vibe-coding-tools-accuracy-guide.html

VibeCoding #SoftwareEngineering

Just for now, forget coding

Thu, 08 Oct 2026 17:31:24 +0000

Can we walk together once again
On that secluded forestry path,
Where the world faded away
And left just you and me?

Can we laugh together again,
Just as we laughed back then—
When nature stood completely still,
Listening to our joy?

Travel eSIM for Developers: How MyEsimGlobal Can Keep You Connected Abroad

Thu, 24 Sep 2026 20:57:23 +0000

A practical look at using a travel eSIM for connectivity, communication, and online work while traveling.

Traveling abroad as a developer can make staying connected more important than ever. You may need access to GitHub, cloud dashboards, Slack, email, documentation, or video calls while away from your usual internet connection.

A travel eSIM can make this easier by giving you mobile data without having to buy a physical SIM after arriving.

What Is MyEsimGlobal?

MyEsimGlobal is a travel eSIM provider offering plans for 190+ destinations. You can choose country-specific or regional plans, with both limited-data and unlimited-data options available depending on the destination.

The main advantage is that you can arrange your mobile data before your trip rather than searching for a local SIM after landing.

Why Could a Travel eSIM Be Useful for Developers?

For developers traveling internationally, mobile data can be useful for:

Checking GitHub repositories and issues
Accessing cloud services and dashboards
Using Slack, Teams, or other communication tools
Joining online meetings
Checking documentation and APIs
Using maps and travel applications
Using your phone as a hotspot when supported by the plan

It can also be useful as a backup connection when hotel or public Wi-Fi isn't available.

If you're interested in another travel eSIM option for developers and remote workers, you can also read my eSIM.dog WorldPass review, where I look at multi-country connectivity, hotspot support, and other considerations for working while traveling.

How Does MyEsimGlobal Work?

The process is straightforward:

Choose a destination → Select a plan → Install the eSIM → Connect when you arrive.

After purchasing, you receive the eSIM information and QR code or installation option. MyEsimGlobal recommends installing the eSIM before traveling while connected to reliable Wi-Fi.

When you arrive, select the travel eSIM for mobile data and follow the activation instructions.

Your phone needs to support eSIM and should be carrier-unlocked.

What Should You Check Before Buying?

Don't choose an eSIM based only on price.

Check:

Whether your destination is covered
Data allowance
Plan validity
Supported local networks
Hotspot availability
Your phone's eSIM compatibility
Any high-speed limits on unlimited plans

This is particularly important if you expect to use your connection for work or other data-heavy activities.

Is MyEsimGlobal Worth Considering?

If you regularly travel internationally and want to arrange mobile data before leaving home, MyEsimGlobal provides a convenient option with plans covering 190+ destinations.

For developers, it can be useful as a primary mobile connection during travel or as a backup when Wi-Fi isn't reliable.

The best plan will depend on your destination, trip length, and expected data usage.

Get 10% Off MyEsimGlobal

If you want to try MyEsimGlobal, you can get 10% off using the code:

BEINGOPTIMIST10

Get 10% Off MyEsimGlobal

Disclosure: This article contains an affiliate link. If you purchase through it, I may earn a commission at no additional cost to you.

She had a great business. AI just wasn't telling people about it

Wed, 12 Aug 2026 09:46:11 +0000

I've been working on different AI visibility projects, but this one has been particularly satisfying.

The business was genuinely good. Great service, happy customers, and everything you'd expect from a business that deserved more attention.

But there was one problem.

When people were asking AI who they should choose, her business wasn't getting mentioned.

And the frustrating part?

Businesses offering similar services, some that weren't necessarily better, were being recommended while hers was being overlooked.

So we dug into the problem.

We looked at how her business was being understood across the web, what information AI could actually pick up, and the signals that were making other businesses easier to surface.

Then we started fixing the gaps.

Seeing the difference afterward was honestly satisfying.

Because this wasn't a case of trying to make a bad business look good.

The business was already good. It just wasn't getting the visibility it deserved.

That's exactly why I find AI visibility so interesting.

Sometimes, you're not losing customers because your business isn't good enough.

You're losing the opportunity because people aren't finding you.

Happy Client 😊

Is Your Business Invisible on AI Search?

Mon, 10 Aug 2026 11:26:03 +0000

A business can have a good website, good reviews, and even strong Google rankings and still be almost invisible when someone asks ChatGPT or Gemini:

“What’s the best [service] in [city]?”

I recently looked into this problem and found that some businesses simply weren't being mentioned when AI tools were asked to recommend companies in their area.

The interesting part? Being visible on Google doesn't automatically mean you'll be visible in AI search.

I worked on improving the signals and information that AI search systems use to understand and recommend a business.

After making the changes, the business became much more visible in relevant AI searches.

AI search is changing how people discover businesses. If you're not checking how your company appears on ChatGPT, Gemini, and other AI search tools, you may not even know what you're missing.

Curious about how your business appears? Feel free to reach out.

Anyone Can Build Software Now. We Tried That Already.

Mon, 03 Aug 2026 16:25:11 +0000

Somewhere on your feed right now, someone is bragging about the app they built in a weekend, no engineering background, no team, just a prompt and a Saturday. The post always ends the same way. Look what I built without needing any of you.

Anyone can build software now. That is the whole pitch, repeated in a hundred different captions this month alone.

Here is what that post never shows you. The part where someone checks it.

Not "does it run." Checks it. Someone who did not write it, looking for the version of it that fails, the input nobody thought to try, the assumption that was wrong in a way the builder was structurally the worst person to catch, because they were too close to their own idea to see the hole in it.

That someone is not optional. It is the actual job.

None of this is theoretical. A notification icon that, instead of opening a panel, closes the entire page and drops me back on an empty tab. A video call that disconnects mid sentence for no visible reason. A video that plays with the sound simply gone, until I restart it. I do not have a chart proving reliability across the industry is getting worse. What I have is a pattern I keep running into, on products built by some of the most resourced engineering organizations on earth.

Why software engineering has more than one person in the room

A developer writes the code. A reviewer reads it before it merges. QA tries to break it on purpose. A manager decides if it is actually ready, or just finished. None of these roles exist because engineers do not trust themselves. They exist because a single person, however good, cannot see their own blind spots. That is not a flaw in the person. It is a fact about how blind spots work.

Ten sets of eyes exist so that the eleventh mistake gets caught before a million people hit it.

We have already watched what happens when that layer disappears, and we did not need AI to run the experiment. We ran it with the spreadsheet.

The spreadsheet already showed us the cost of skipping this

In 2012, JPMorgan Chase lost 6.2 billion dollars in the London Whale trade. Investigators traced part of the failure to a risk model where a formula divided by the sum of two numbers instead of their average. Someone had copied and pasted the wrong range. Nobody caught it before the number went into a report that told the bank its risk was lower than it actually was.

Raymond Panko, a University of Hawaii researcher who has spent decades studying exactly this failure, put it in nine words:

Spreadsheet programs are not error-prone. People are error prone.

He is right, and he is making a narrower point than it sounds like. The tool did not cause the loss. The absence of anyone checking the tool did.

In 2010, Carmen Reinhart and Kenneth Rogoff published a paper arguing that growth slows sharply once public debt passes 90 percent of GDP. Governments cited it for years while deciding how hard to cut spending. In 2013, a graduate student trying to replicate the result found a formula that had quietly excluded five countries from the average. Corrected, growth in the high debt group went from negative 0.1 percent to positive 2.2 percent.

That error sat unreviewed for three years, informing real policy, because nobody with the standing to check the underlying spreadsheet did, until a student did it for a class assignment.

Neither of these was a skill problem. Both were a review problem. The tool made something that looked finished. Nobody treated "looks finished" as different from "is correct."

The AI version of this is worse, because it can close the whole loop

A spreadsheet could not review itself. It could not test itself, or decide it was done, or ship itself into production. A human still had to be the one who trusted it too much.

AI coding tools are closing that gap. Not just writing the code, but reviewing it, testing it, and in some workflows, deciding it is ready, with no human required at any step. That is a different category of risk than "the code was written badly." It is the removal of the entire mechanism that would have caught JPMorgan's formula, or Reinhart and Rogoff's missing rows, before it cost anyone anything.

I am not arguing AI should stay out of engineering. I use it every day, and it makes me faster at parts of the job that used to be slow for no good reason. The argument is narrower than that, and I think it is the only argument that actually holds up: AI has not proven it can review its own work the way a second, independent, motivated engineer does. Not yet. It is getting better at an uncomfortable pace, and I would not bet against it eventually closing that gap. It has not closed it now, and treating the current state of the tools as if they already have is the reckless part, not using them.

Why I build what I build

This is the reason I built agentsmyth. Not another assistant that writes code faster. A contract the agent you already use agrees to follow: seven gates, Think, Plan, Build, Review, Test, Ship, Reflect, each one leaving a real artifact behind instead of reasoning that evaporates the moment a chat scrolls off screen. One command, npx agentsmyth init, wires it into a repo. Skipped checks get recorded as risk, not hidden. Nothing ships on the strength of looking finished.

Its own pitch is two words. Forge, don't vibe.

I do not know if that is the full answer to the problem this piece describes. It is the piece of the problem I can actually put my hands on. If AI is going to keep closing more of the gap between an idea and a shipped feature, someone still has to decide where the edges of that gap are, and someone still has to check the work against them. I would rather build the scaffolding that forces that check to happen than write another post about how nobody needs it anymore.

The reliance itself is not the problem

The completeness of it is.

Until an AI system can review its own work the way a second engineer does, at two in the morning, with their own name on the outcome and nothing personal riding on being agreeable about it, the review layer does not get to be optional. That is not an argument for keeping developers employed out of sentiment. It is the argument for making sure the next six billion dollar mistake does not ship quietly, built fast, reviewed by no one, because everyone involved assumed the tool had already checked its own work.

It had not. It still has not. Build with that in mind, and the weekend app stops being something to brag about and starts being something to be honest about.

The Hidden Engineering Behind Git Merge Conflicts

Mon, 13 Jul 2026 12:12:16 +0000

If you've worked with Git for even a few weeks, you've probably seen this message:

CONFLICT (content): Merge conflict
Automatic merge failed.

Your heart sinks.

You stare at the screen and think:

👉 "What did I do wrong?"

The truth is...

Most merge conflicts aren't caused by bad developers.

They're simply a side effect of multiple people working on the same codebase.

Let's see what's actually happening behind the scenes.

💡 Git Doesn't Understand Your Code

Here's something many developers don't realize.

Git doesn't understand:

JavaScript
Java
Python
React
Node.js

Git simply sees...

👉 Text files.

It doesn't know what a function is or what a variable means.

It only knows:

"This line changed."

👨💻 A Simple Example

Imagine your login.js file contains:

function login() {
   return true;
}

Now two developers start working.

Developer A

Changes it to:

return false;

Meanwhile...

Developer B

Changes it to:

return validateUser();

Both changes happen on different branches.

🤔 Now Git Gets Confused

When the branches are merged...

Git asks itself:

"I have two different changes for the same line."

Which one should I keep?

Developer A's?

Or Developer B's?

Git has no idea.

So instead of guessing...

It stops.

And asks you to decide.

That's a merge conflict.

🚀 Why Git Doesn't Auto-Fix Everything

People often ask:

"Why can't Git just combine both changes?"

Because sometimes there isn't a correct answer.

Imagine:

One developer deletes a function.

Another developer adds new logic inside that same function.

Should Git:

Keep the deletion?
Keep the new logic?
Combine both?

Only the developer understands the intent.

Git doesn't.

⚙️ What Those Weird Markers Mean

When a conflict happens, you'll see something like:

<<<<<<< HEAD
Developer A's code
=======
Developer B's code
>>>>>>> feature-branch

Git is simply saying:

"Here are both versions.
You choose the correct one."

After editing the file and removing these markers, the conflict is resolved.

🤝 Why Merge Conflicts Increase in Large Teams

In small projects...

Conflicts are rare.

In large projects:

Multiple developers
Multiple features
Long-lived branches
Frequent releases

The chances of two people modifying the same file become much higher.

That's why enterprise teams often merge changes frequently instead of waiting for weeks.

💡 How Good Teams Reduce Merge Conflicts

Experienced teams don't eliminate conflicts completely.

Instead, they reduce them by:

Creating smaller pull requests
Merging branches frequently
Keeping branches short-lived
Improving communication
Breaking large features into smaller tasks

The goal isn't "no conflicts."

The goal is "easy conflicts."

🎯 The Bigger Lesson

A merge conflict isn't Git being broken.

It's Git protecting your work.

Instead of making the wrong decision...

Git lets the developer make the final call.

That's actually a safety feature.

🚀 Final Thought

The next time Git says:

"Automatic merge failed."

Don't panic.

It's not telling you that your project is broken.

It's simply saying:

👉 "Two smart developers made different changes. I need your help deciding which one is correct."

And that's the hidden engineering behind one of the most common messages every developer eventually learns to respect.

💬 What's the longest merge conflict you've ever had to resolve? 😄

Git #GitHub #SoftwareEngineering #Developers #Programming #VersionControl #Coding #WebDevelopment #DeveloperLife

"I'll document it later" - the biggest lie in tech.

Thu, 18 Jun 2026 09:27:11 +0000

Before writing docs: "I'll remember everything. No need to write this down."

After writing docs: "Why did I name this variable temp? What does this function even do? Who wrote this?! Oh… it was me."

Me: "I'll document as I go."

Also Me, 6 months later: opens empty README — "Well, this is fine." 🔥

Documentation: "Just write clear comments."
My code: // TODO: figure out what this does

We're not developers anymore.
We're archaeologists digging through our own past code. 😭

What's the worst documentation crime you've committed? Drop it below! 👇

Follow for more dev reality checks!

Tell me you're a dev without telling me you're a dev.

Mon, 15 Jun 2026 11:32:38 +0000

I just spent 45 minutes aggressively debugging a piece of code, questioning my career choices, and cursing the universe... only to realize I was editing the wrong file.

The worst part? The AI assistant I was using just watched me do it and said nothing. Absolute betrayal.

Your turn. Drop your most "developer" moment in the comments below! 👇

The Evolution of Software Development: Automation Coding vs. Written Code

Mon, 08 Jun 2026 05:18:30 +0000

The landscape of software engineering is undergoing a profound transformation. For decades, the backbone of technology was "written code"—handcrafted, line-by-line syntax meticulously typed by human software engineers. Today, the rise of artificial intelligence, low-code/no-code platforms, and agentic developer tools (such as Google Antigravity or Jules) has introduced "automation coding."

As software creation shifts from manual execution to high-level orchestration, understanding the strengths, limitations, and synergy between automation coding and traditional written code is essential for the future of technology.

1. What is Written Code?

Written code refers to traditional software development. Programmers use integrated development environments (IDEs) to manually write code in languages like Python, Java, C++, or JavaScript.

The Power of Control: Hand-written code gives developers absolute control over every logic branch, memory allocation, and architectural decision. It is highly customizable and necessary for building foundational systems, custom algorithms, and high-performance applications.

The Human Edge: Creative problem-solving, edge-case management, and understanding nuanced user empathy remain deeply rooted in human-written code.

The Cost: It is slow, prone to human syntax errors, and highly dependent on developer bandwidth.

2. What is Automation Coding?

Automation coding utilizes AI, code generators, and automated workflows to write, debug, and deploy software. Instead of writing code line-by-line, developers guide AI models using natural language prompts or high-level architecture designs.

Unprecedented Speed: Automation tools can instantly generate boilerplate code, write standard APIs, and automate repetitive testing processes, shrinking development cycles from weeks to hours.

Democratization and Scaling: It allows developers to focus on big-picture system design and architecture while AI handles the execution. It also empowers non-technical users to build functional prototypes.

The Risk: Automated code can sometimes lack optimization, introduce hidden security vulnerabilities if unchecked, or struggle with highly complex, novel logic that hasn't appeared in its training data.

The Verdict: Collaboration, Not Competition

The debate is rarely about one entirely replacing the other. Instead, the industry is moving toward a hybrid model.

Automation coding handles the mundane, repeatable, and boilerplate tasks, drastically accelerating productivity. Meanwhile, written code remains the gold standard for innovation, deep technical optimization, and high-security infrastructure. The most successful developers of tomorrow will not just be code writers, but AI orchestrators who know exactly when to let automation build, and when to step in and write the code themselves.

Sumita
Web Developer

The Beautiful, Chaotic Reality of Software Development: Truths from the Trenches

Mon, 01 Jun 2026 16:49:29 +0000

The Beautiful, Chaotic Reality of Software Development: Truths from the Trenches

To the outside world, software engineering looks like a highly sophisticated, ultra-logical discipline. The mainstream media portrays developers as cyber-wizards who furiously type green code across three monitors while instantly hacking into mainframes.

But if you actually pull back the curtain and look at the daily reality of a developer, you won’t find a flawless digital symphony. Instead, you will find a chaotic, hilarious masterclass in coping mechanisms, caffeine consumption, and Google searches for things they should have memorized five years ago.

Here is the unvarnished, funny truth about what it really means to write software.

1. The Emotional Rollercoaster of Debugging

There is no middle ground in programming; you are either a genius or a fraud, and you will alternate between these two states multiple times a day.

The debugging process generally follows three strict phases:

The Ghost in the Machine: "I have no idea why this code isn't working."
The Accidental Miracle: "I have no idea why this code IS working."
The Anti-Climax: "Oh. A single missing semicolon broke the entire multi-million-dollar infrastructure."

When code works on the first try, a developer doesn't celebrate. They become incredibly suspicious. They wonder what hidden, catastrophic error is lurking beneath the surface, waiting to explode the moment they look away.

2. The Art of "Stack Overflow Engineering"

If we are being completely honest, a massive portion of modern software architecture is held together by digital duct tape and prayers. "Writing code" is often just a fancy term for searching Stack Overflow, finding a snippet written by a stranger in 2018, pasting it into your project, and desperately hoping it doesn't cause a chain reaction that crashes a server in Ohio.

This creates a brilliant paradox:

Normal Person: "This feature will take about two days."
Developer: "I can write this in two hours."
Reality: It takes two weeks because the pasted code broke the login system.

3. The Myth vs. The Reality

The gap between expectations and what actually happens on a Tuesday afternoon is massive.

The Myth	The Reality
"Developers love solving complex mathematical algorithms."	We spend 45 minutes trying to vertically center a `<div>` box on a webpage.
"Coding is a highly collaborative, social process."	If a developer has headphones on, they are legally dead to the world. Do not perceive them.
"We know exactly what we are doing."	We have 47 browser tabs open, and half of them are checking basic language syntax.

4. The Evolution of the Git Commit

Version control is meant to keep a clean, professional history of a project’s development. Instead, it serves as a psychological diary of a developer's descent into madness.

Look at any project's history, and you can map the timeline of a Friday afternoon:

3:00 PM: Initial feature setup.
3:45 PM: Fixed the authentication bug.
4:15 PM: Code cleanup.
4:45 PM: Please work.
5:10 PM: I hate my life.
5:30 PM: Final fix final v2 ACTUAL FINAL.

5. The Ultimate Developer Golden Rules

To survive in this industry, you have to adopt a few unspoken rules. First, "It works on my machine" is always a valid defense mechanism—even if your machine is a highly customized powerhouse and the client is trying to run the app on a ten-year-old browser.

Second, if a bug is simply too difficult or time-consuming to fix, it ceases to be a flaw. It is instantly rebranded as an "undocumented feature" that adds unique character and flavor to the application.

Finally, we write comments. Writing a code comment like // TODO: Fix this later is the ultimate developer lie. It is the digital equivalent of shoving a receipt into a junk drawer and promising you’ll organize it next weekend. That code will remain untouched until the sun burns out.

The Verdict

At the end of the day, computer science remains one of the only fields where you can create a problem that didn't exist, spend six hours failing to fix it, accidentally make it worse, delete everything, start over, and call it a highly productive workday.

It’s frustrating, it’s illogical, and it defies common sense—but developers wouldn't trade it for the world.

When AI Agents Acrt, Check the Action - Not Just the Answer

Sun, 24 May 2026 05:15:50 +0000

For a long time, verifying AI meant checking the answer.

If AI wrote an explanation, we could read it.
If it summarized a document, we could compare it with the original.
If it made a factual claim, we could check the source.
If the answer was incomplete, we could ask again or edit it ourselves.

That kind of verification is familiar.

It is close to reviewing text.

But AI is no longer only producing answers.

It is beginning to act.

It can send emails.
It can book meetings.
It can edit files.
It can run commands.
It can open pull requests.
It can trigger workflows.

That changes the problem.

Because answers can be read.

Actions leave traces.

Wrong answers and wrong actions are different

A wrong answer can create confusion.

It may waste time.
It may mislead someone.
It may need correction.

But often, the damage stays inside the text.

A wrong action is different.

An email that has already been sent is now in someone else’s inbox.

A meeting that has already been booked has taken space on someone’s calendar.

A file that has already been changed may affect other work.

Code that has already been deployed is now running somewhere.

A deleted file may not come back.

That is why AI agents need more than fact-checking.

When AI starts acting, we need action-checking.

What does it mean for AI to act?

AI action is usually quieter than people imagine.

It does not always look like a robot making decisions in the world.

It often looks like software crossing a boundary.

An email assistant does not only draft a reply.
It may send it.

A calendar assistant does not only suggest a time.
It may book the meeting.

A coding assistant does not only suggest code.
It may edit files, run tests, open a pull request, or prepare a deployment.

A research assistant does not only return links.
It may search, compare, summarize, rank, and continue to the next step.

This is the practical meaning of AI agents.

They do not only answer.

They move the task forward.

And once they move the task forward, verification has to change.

Fact-checking is not enough

When we verify AI-generated text, we usually ask:

Is this true?
Is this accurate?
Are the sources real?
Is the explanation complete?
Is the information up to date?

These questions still matter.

But they are not enough for AI agents.

An action can be factually correct and still wrong.

An email can contain accurate information and still be inappropriate to send.

A code change can pass tests and still move the system in the wrong direction.

A workflow can complete successfully and still exceed the boundary it was given.

When AI acts, correctness is only one layer.

We also need to verify direction, scope, reversibility, and responsibility.

1. Direction

The first question is:

Is this action moving in the right direction?

An AI-written email can be polished, grammatically correct, and factually accurate.

But it may still be the wrong email to send.

Maybe the timing is wrong.
Maybe the relationship needs a softer response.
Maybe it commits to something too early.
Maybe it moves the conversation in the wrong direction.

The same applies to code.

An AI coding agent may fix a bug by changing more of the system than expected. The patch may pass tests, but still conflict with the intended design.

So the first check is not only:

Is this correct?

It is:

Is this action serving the actual goal?

2. Scope

The second question is:

Did the agent stay inside the boundary?

Agents interpret instructions.

That is useful, but it also creates risk.

“Clean up this folder” might mean organizing files.

It might also mean deleting files.

“Fix this bug” might mean changing one function.

It might also mean refactoring surrounding code.

“Improve this document” might mean clarifying a few paragraphs.

It might also mean rewriting the argument.

The problem is not always that the agent is broken.

Sometimes it is doing what it thinks the instruction implies.

That is why scope matters.

Before letting an agent act, ask:

What is it allowed to touch?
What is it not allowed to touch?
Where should it stop?
When should it ask for approval?

Without scope, helpfulness can become overreach.

3. Reversibility

The third question is:

Can this action be undone if needed?

Not all actions have the same weight.

Saving a draft is not the same as sending an email.

Running code locally is not the same as deploying it.

Changing a private note is not the same as changing a shared document.

Deleting a test file is not the same as deleting production data.

The harder an action is to undo, the more careful the verification should be.

Before approving an AI action, ask:

Is there a preview step?
Is there a backup?
Is this a draft or final action?
Can this be reverted?
What happens if the agent is wrong?

A trustworthy AI workflow should not remove all friction.

It should put friction in the right places.

4. Responsibility

The fourth question is:

Who owns the outcome?

AI does not remove responsibility.

If AI sends an email, someone allowed it to be sent.

If AI deploys code, someone approved that deployment.

If AI books the wrong meeting, changes the wrong setting, or deletes the wrong file, the result still belongs somewhere.

Automation changes how work happens.

It does not make responsibility disappear.

So before giving an agent more autonomy, ask:

Who approves the action?
Who reviews the result?
Who is notified?
Where is the audit trail?
Who is responsible if it goes wrong?

This is uncomfortable, but necessary.

A simple action-verification checklist

Before letting an AI agent take action, check four things:

Direction:
Does this action move in the right direction?

Scope:
Does it do only what it should do?

Reversibility:
Can it be undone if needed?

Responsibility:
Who owns the outcome?

This is not a complicated framework.

But it changes the question.

We stop asking only:

Is the answer correct?

And start asking:

Should this action happen?

Convenience moves judgment upstream

It is tempting to think that as AI tools become more capable, human judgment becomes less important.

I think the opposite happens.

Convenience moves judgment upstream.

When AI handles more steps, humans may not need to make every small decision manually.

But the remaining decisions become more important:

What goal should be given?
How much autonomy is allowed?
Which tools can the agent use?
Where should it stop?
Which actions require approval?
What should never be delegated?

Automation reduces manual effort.

It does not remove judgment.

The more AI can do, the more clearly we need to define what it should not do.

What should developers delegate?

AI agents can be useful when:

the workflow is clear
the task is repetitive
the result is easy to verify
the scope is limited
mistakes are easy to undo
logs or review steps exist

But we should be careful when:

the action affects other people
the result is hard to reverse
the instruction is ambiguous
the agent can touch sensitive data
the task depends on personal or business context
the outcome creates responsibility outside the tool

You can delegate work to AI.

But you cannot fully delegate judgment.

Final thought

The first phase of AI verification was mostly about answers.

Can we trust this explanation?
Is this fact correct?
Are these sources real?
Is this summary faithful?

That still matters.

But AI agents push the question further.

Now we also need to ask:

Is the direction right?
Is the scope appropriate?
Is the action reversible?
Is the responsibility clear?

When AI makes answers, we verify facts.

When AI takes actions, we verify consequences.

Because answers can be read.

Actions leave traces.

Originally published on Dechive — an archive for verifying AI-generated answers before we trust them.

https://dechive.dev/en/archive/when-ai-acts-beyond-answers

The AI Tool Anxiety Developers Don’t Talk About

Sat, 23 May 2026 03:55:26 +0000

Keeping up with AI is not about trying every tool. It is about knowing which tools deserve your attention.

Every developer feed now feels like a race.

Someone built an app with AI over the weekend.
Someone launched a small SaaS.
Someone connected a new model to an agent workflow.
Someone tested the latest AI coding tool and already posted a breakdown.

Then the quiet question appears:

Am I falling behind?

It does not always feel like failure.

Sometimes it feels like absence.

I am not necessarily doing something wrong.
I am just not doing enough.

Not building enough.
Not testing enough.
Not automating enough.
Not using the newest tools quickly enough.

That is the strange pressure of the AI era.

Two kinds of AI anxiety

I think this anxiety usually appears in two forms.

The first is productivity anxiety.

Everyone seems to be producing more with AI.
More apps. More posts. More videos. More workflows. More launches.

The second is tool anxiety.

Every week there is a new model, framework, coding assistant, agent system, workflow builder, or “best setup” to try.

And if we are not trying all of it, it can feel like we are falling behind.

But both anxieties depend on comparison.

And comparison always needs a standard.

The feed is not a good standard

The feed is good at showing motion.

It shows who launched something.
Who tried the newest model.
Who built an agent workflow.
Who automated part of their work.
Who shipped faster.

But it does not always show whether the work mattered.

It does not show whether the tool solved a real problem.
It does not show whether the workflow is maintainable.
It does not show whether the output was useful.
It does not show whether the person building it even needed it.

That is why using the feed as a standard is dangerous.

The feed can always move the finish line.

After you try one tool, another one appears.
After you launch one project, someone launches three.
After you automate one workflow, someone shows a better one.

If the standard stays outside of you, no tool will ever be enough.

Trying a tool is not the same as moving forward

This is the mistake I keep noticing:

We confuse trying tools with making progress.

But those are different things.

Trying a tool quickly is not the same as understanding it.

Understanding a tool is not the same as using it well.

Using a tool well is not the same as building something meaningful with it.

A tool is not a direction.

A model is not a goal.

A workflow is not a standard.

Of course, testing new tools matters.
Curiosity matters.
Experimentation matters.

But trying everything is not the same as keeping up.

Sometimes it is just another way to borrow direction from the feed.

A better checklist

Before trying a new AI tool, I want to ask better questions.

1. Why do I want to use this?

Is it curiosity?
Is it connected to a real problem?
Or am I only reacting because everyone else seems to be using it?

2. What problem does it solve?

If I cannot name the problem, I am probably just collecting tools.

3. What would count as a useful result?

Does it save time?
Improve quality?
Reduce friction?
Help me understand something?
Help me build something I actually care about?

4. What will I stop doing if this works?

A useful tool should replace, improve, or clarify something.

If nothing changes after using it, maybe it was not that useful yet.

5. Am I curious, or am I anxious?

Curiosity and anxiety can look similar from the outside.

Both can make us test tools.
Both can make us write notes.
Both can make us post screenshots.

But internally, they are different.

Curiosity builds judgment.
Anxiety borrows direction.

A small example

Instead of saying:

I need to try this new AI coding tool because everyone is talking about it.

A better standard might be:

I want to test this tool because I spend too much time refactoring repeated UI patterns, and I want to see whether it reduces that friction without lowering code quality.

That second version has a problem.

It has a reason.

It has something to verify.

The goal is not just to use the tool.

The goal is to know whether the tool helps with a real task.

Keeping up with AI

Keeping up with AI does not mean using every new model, agent, framework, or workflow.

It means building the judgment to decide what deserves attention.

It means knowing why we are trying something before we mistake the act of trying for progress.

It means knowing what we are building before we confuse output with direction.

AI can make us faster.

But speed only helps when we know what it is serving.

Without an internal standard, every new tool becomes a demand.
Every launch becomes a comparison.
Every post becomes evidence that we are late.

With a standard, a tool can become just a tool again.

Something to test.
Something to use.
Something to ignore.
Something to return to later.

Maybe the AI tool anxiety developers feel is not always about using too few tools.

Maybe it is about borrowing too many standards from the feed.

Originally published on Dechive — an archive for verifying AI-generated answers before we trust them.

https://dechive.dev/en/archive/am-i-falling-behind-in-ai-era

Stop Rebuilding the Same Infrastructure. Use These Tools Instead.

Thu, 21 May 2026 17:28:04 +0000

Every developer has done it — spent the first sprint of a new project wiring up auth, configuring deployments, scaffolding a project structure, and setting up CI/CD pipelines before writing a single line of actual product logic. It's the tax you pay for starting from scratch.
The ecosystem has matured enough that most of this is a solved problem. Here are six tools worth knowing about, each handling a specific piece of the stack so you don't have to.

Developer Toolkit — AI-Powered Dev Workflows That Actually Hold Up in Production

There's a well-known gap between "using AI to prototype" and "using AI to ship production features reliably." Developer Toolkit is built to close it. It's a structured learning and workflow system for developers using Cursor, Claude Code, and Codex — with 350+ tutorials, reusable prompt patterns, and production-ready templates covering CI/CD, testing, and architecture. The goal is turning specs into working, tested, documented features in hours rather than weeks, without the regressions and messy diffs that tend to come with AI-assisted code. If you're serious about making AI a consistent part of your development workflow rather than an occasional shortcut, this is worth a look.

Clerk — Authentication as a Drop-In Component

Auth is one of those things that's easy to underestimate until you're deep in the weeds of session management, token refresh logic, and OAuth edge cases. Clerk handles all of it. It ships as pre-built components — sign-up, sign-in, user profiles — that are fully customizable and integrate in minutes. It supports MFA, SSO, OTPs, magic links, and passkeys out of the box, with SDKs for Next.js, React, React Native, Remix, and most frameworks you'd reach for in 2025. The free tier covers up to 10,000 MAUs/month, which is more than enough runway to get to paying customers. Pro is $25/month. If the alternative is a week of hand-rolled auth, the math is obvious.

SupaNext — Full-Stack SaaS Starter for Next.js + Supabase

If your stack is Next.js and Supabase — a common and sensible choice — SupaNext gives you a complete starting point rather than an empty repo. Auth, payments, AI integration, landing page, blog, admin panel, and a set of modern UI components come pre-assembled. The architecture decisions are already made sensibly, so you're not inheriting technical debt from the boilerplate itself. The practical effect is skipping a week or more of setup work and jumping straight to building the features that differentiate your product.

Capgo — Live Updates for Capacitor Apps Without App Store Delays

If you're shipping a mobile app on the Capacitor framework, Capgo solves one of the more frustrating parts of the release cycle. It lets you push updates, new features, and critical fixes directly to users' devices — bypassing the App Store and Google Play review process for eligible changes. Update times drop from days to minutes. It includes version management, rollback capabilities, and analytics, with cross-platform support for iOS and Android. For teams that need to respond quickly to production issues or iterate fast on mobile, the alternative — waiting three days to ship a one-line fix — doesn't scale.

2V Modules — AI-Augmented Dev Team for When You Need to Move Fast

Not every project makes sense to build entirely in-house, especially at the early stages. 2V Modules is a development shop that covers the full product lifecycle: Discovery, UI/UX, full-cycle development (React, Next.js, Flutter, Laravel, NestJS), and Webflow marketing websites. Their Flutter specialization is worth noting — cross-platform mobile at roughly half the cost of native development is a meaningful budget advantage for early products. B2B and B2C SaaS, marketplaces, and MVPs are their main focus areas. If you need an end-to-end partner who can take a product from wireframes to deployment without the overhead of coordinating multiple vendors, this is the kind of shop that handles that.

code.store — Custom Software Built Fast with Low-Code and AI

For businesses running on legacy systems, manual operations, or overpriced SaaS licenses, code.store builds custom software using low-code platforms and AI tooling at significantly higher velocity than traditional development — they cite 5x faster delivery compared to classical approaches. Their focus is on media, publishing, and business applications. If your organization is still managing operations through Excel sheets and email threads, running software that's a decade old and increasingly painful to maintain, or paying $50K+ per year for Salesforce or Microsoft Dynamics, there's a reasonable case for a custom build. Clients include BNP Paribas and a number of established media companies.

The pattern across all six is the same: every hour you spend rebuilding solved infrastructure is an hour you're not spending on the code that actually makes your product worth using. Knowing which tools to reach for — and when to reach for them — is part of writing good software.

I used to fail .NET interviews for not giving the “expected answer”, now I understand them better

Wed, 06 May 2026 15:58:47 +0000

I’m a .NET developer. I can build production-ready applications, APIs, and work with databases.

In the past, I kept failing interviews and getting rejected or ignored, mostly because I wasn’t giving the “expected answer”.

I could solve the problems in real code, but I struggled to explain things in the structured way interviewers wanted. I thought performance should matter more than theory, but interviews don’t really work like that. You have to answer first, then prove yourself later.

I even got hired once just because I memorized definitions and answered correctly, even though I wasn’t actually strong in what they asked. I ended up learning everything on the job and eventually resigned after a short time.

Now, after going through many interviews, I understand the process much better. I know what they are looking for, how questions are framed, and what kind of answers they expect.

Still, it’s interesting how different real-world development is from interview performance.

Tooling Tips: Visualizing Your Data in MongoDB and Kafka

Wed, 06 May 2026 00:32:14 +0000

Hey folks!

Quick tooling post today. Before moving forward to the next services, I want to share the tools I use to visualize and inspect data in MongoDB and Kafka during development.

Without these tools, debugging an asynchronous data pipeline would be much harder — you're essentially "blind" to what's happening inside the containers.

MongoDB — MongoDB Compass

MongoDB Compass is MongoDB's official GUI. Free and available for Windows, Mac and Linux.

What you can do:

Browse collections and documents
Run queries with visual filters
See indexes created by Flyway/code
Inspect document schemas
Monitor performance metrics

How to connect to the local container:

URI: mongodb://root:password@localhost:27017/?authSource=admin

After connecting, you'll see the market_data_db database with the price_history collection being populated by broker-market-data-api on each ingestion round.

Download: mongodb.com/products/tools/compass

Kafka — Offset Explorer (formerly Kafka Tool)

Offset Explorer is a GUI for inspecting Kafka clusters. It lets you see topics, partitions, messages and offsets without needing the command line.

What you can do:

List all topics in the cluster
See messages from each partition in real time
Inspect the content (key + value) of each message
Monitor consumer group offsets
Check whether consumers have lag

How to connect to the local container:

Bootstrap Servers: localhost:9092

After connecting, you'll see the trading-assets-market-data-v1 topic with messages published by broker-market-data-api. Each message will have the ticker as key (e.g. PETR4) and the quote JSON as value.

Download: kafkatool.com

RabbitMQ — Management UI (already included)

RabbitMQ comes with a built-in web interface. In our docker-compose.yml, port 15672 is exposed:

URL: http://localhost:15672
User: admin
Pass: admin_pass

What you can do:

View queues, exchanges and bindings
Inspect messages in queues
Manually publish messages to test consumers
Monitor message rates and lag
See the DLQ (Dead Letter Queue) when messages fail

This is the most useful tool for debugging the flow between trading-broker-order and b3-matching-engine.

Workflow Tip

During development, I use all three tools in parallel:

Offset Explorer to confirm broker-market-data-api is publishing messages to Kafka
MongoDB Compass to confirm the history is being persisted
RabbitMQ Management to confirm orders are arriving in the B3 queues

This turns an opaque asynchronous pipeline into something completely observable.

What's Next?

With the tools set up, in the next post we build b3-market-sync — the Java service that consumes quotes from Kafka and synchronizes them to Redis, feeding the Matching Engine with real-time prices.

About the Series

⬅️ Previous Post: Market Data Integrator

➡️ Next Post: Syncing the Real Market: Consuming Brapi and Feeding Redis with Spring Boot

Series Index: Series Roadmap

Links:

How to Win Hackathons: A Deep, Practical, and Honest Roadmap for Student Builders

Sat, 02 May 2026 12:21:48 +0000

Hackathons look chaotic from the outside — buzzing rooms, half-written code, caffeine clouds, loud keyboards, and that strange collective silence at 3AM when everyone is too tired to speak but too determined to stop.
But if you look closely, beneath the noise, hackathons are surprisingly quiet.

Quiet in the sense that what really decides the winners happens in the moments that nobody else sees:
the 20 minutes where your idea suddenly clicks,
the late-night decision to remove a feature you loved,
the discussion that aligns your team,
the pitch where your voice doesn’t shake,
the clarity that arrives when pressure is highest.

My own journey — through CTFs, open-source nights at GirlScript Summer of Code, early internships, coding battles, and national-level hackathons at places like Microsoft Gurugram — taught me this one truth:

Hackathons do not reward the smartest coder in the room. They reward the clearest thinker.

People often ask, “How do you win hackathons?”
And the real, practical, tried-and-tested answer is not a checklist — it’s a mindset and a method. A way of building, deciding, collaborating, communicating, and recovering when things go wrong.

This is the roadmap I’ve slowly pieced together through every build sprint, every debugging meltdown, every mentor interaction, and every quiet moment of self-doubt transformed into confidence.

Let’s go deep.

1. The First Lesson: Hackathons Are Clarity Competitions, Not Coding Competitions

The biggest mistake beginners make is believing hackathons are about complexity. They try to stack AI models on top of blockchain on top of some advanced API just because it “sounds impressive.” I made this mistake too. It took me multiple events to understand that judges aren’t waiting to be dazzled by architecture diagrams or buzzwords — they’re trying to understand your idea in under 60 seconds.

When I walked into the Microsoft Triwizardathon Hackathon, I saw incredibly talented teams. But the ones who advanced weren’t the teams with the most technical depth; they were the ones with the clearest problem statement. They told a simple, human story. Their demos felt like something a real person would use.

Judges remember clarity, not complexity.

They want to know:

Who exactly you’re helping
What pain they feel
Why it matters
How your solution solves it beautifully and simply

Once you internalize this, everything becomes easier. Your decisions become sharper. Your pitch becomes shorter. Your UI becomes cleaner. And your demo becomes smoother. The moment clarity becomes your north star, you quietly move into the top 10% of teams.

2. Your Team Determines Your Ceiling — Not Your Tech Stack

My best hackathon experiences were never about the project alone. They were about the people in the room with me. The teammates who continued debugging when I was mentally done. The ones who kept the energy alive at 4AM. The ones who argued with me for 20 minutes only to find the right answer at minute 21.

A team doesn’t need to be made of prodigies; it needs to be made of complements.

There’s the person who sees the big picture — the one who says, “Let’s not build five features. Let’s build one that works.”
There’s the designer who transforms rough sketches into something elegant enough that judges trust the product before even touching it.
There’s the builder who creates the core functionality — the heartbeat of the project.
And there’s the integrator who holds the universe together, ensuring the frontend, backend, and APIs cooperate long enough to survive the final demo.

When SecureX — our decentralized file storage system — started taking shape at a hackathon, the breakthrough wasn’t in code. It was in trust. Everyone knew their role. Everyone respected the others’ strengths. And somehow, even under pressure, the team moved like a single organism.

A powerful team isn’t built during a hackathon.
It’s revealed during one.

3. Preparation Is the Unfair Advantage No One Talks About

People assume hackathons start when the clock starts.
In reality, hackathons start weeks before you enter the venue.

If there’s one pattern I’ve consistently seen among winning teams — whether it was my own projects like HealthGuard AI or others I admired — it’s that they never start from zero.

They arrive with:

a boilerplate ready for authentication
a UI kit that makes screens look clean instantly
a mental library of APIs they trust
a few problem domains they understand deeply

This preparation creates a quiet but massive advantage.

During my initial hackathons, I wasted hours just setting up project folders or fixing package conflicts. But once I started maintaining my own starter templates — backend routing structure, frontend layout, login page, reusable components — everything became smoother.

Preparation multiplies your focus.
And focus wins hackathons.

4. Choosing the Right Problem: The Idea Must Move You Before It Moves Others

Every great hackathon project I ever built started not from technology, but from emotion — a feeling that something in the world wasn’t right or could be better.

HealthGuard AI wasn’t born out of a desire to train another model.
It came from frustration — how inaccessible reliable health insights feel in urgent situations.
SecureX wasn’t born from blockchain hype.
It came from a quiet anger at how fragile online privacy feels.

That’s the secret:
Hackathon ideas shouldn’t impress you.
They should bother you.

Because when an idea bothers you, you naturally express it with clarity. You naturally build it with care. And you naturally pitch it with conviction.

Judges can sense when a solution comes from curiosity.
But they feel it when a solution comes from emotion.

5. The Build Phase: Winning Requires Ruthless Reduction, Not Endless Expansion

Hackathons constantly tempt you to build more.
One more feature.
One more API.
One more “wow” moment.

But the truth is far more unromantic:

The winning project is not the one with the most features.
It’s the one with the least unnecessary features.

Time is your greatest constraint, not skill.
Great teams understand this intimately. They make hard decisions early.

During the build phase, something always breaks. Something always fails. A library refuses to install. An API key expires. A model doesn’t load. This has happened to me more times than I can count.

Here’s what separates finalists from participants:

Finalists know what to cut.

When a feature endangers the demo, they remove it.
When an idea becomes too heavy, they simplify it.
When time gets tight, they optimize narrative over novelty.

Winning is the art of letting go.

6. The Demo and Pitch: This Is Where Winners Are Made

People assume the pitch is the last step.
But in reality, the pitch is the moment your project receives its meaning.

I’ve seen brilliant teams fall apart because they walked into the pitch room unprepared.
I’ve seen ordinary ideas rise to the top simply because their story was unforgettable.

Your pitch must do three things beautifully:

1. Make the problem feel urgent

Not through jargon, but through emotion.
Bring the judge into the life of your user.
Make them feel the gap in the world that you are trying to fill.

2. Present your solution with simplicity and elegance

Imagine explaining it to your past self.
If your past self can’t understand it, refine.

3. Deliver a demo that feels inevitable

A good demo doesn’t surprise the judge.
It confirms the judge’s expectations.

During one hackathon, an API we relied on went down minutes before our pitch. Luckily, we had recorded a backup demo video. That single decision saved our entire presentation.

A great pitch is not the result of confidence.
It is the result of preparation meeting clarity.

7. What Judges Actually Reward — The Quiet Criteria No One Teaches

After talking to mentors, organizers, and judges, I realized something that fundamentally changed the way I approach hackathons:

Judges aren’t scoring your codebase.
They’re scoring your thinking.

They’re asking:

Does this team understand the user?
Is the problem real and meaningful?
Is the solution simple enough to exist and sharp enough to matter?
Does the demo feel smooth and trustworthy?
Can this project actually grow beyond tonight?
Does the team look capable of delivering?

You win hackathons by proving one idea:

“We didn’t just build something.
We built something that makes sense.”

8. The Real Win: Hackathons Change You Long Before They Reward You

When I look back at September — open-source nights, internships, CTFs, SecureX versions, late-night debugging, the triumphs and the mistakes — I don’t think of prizes.

I think of:

the moment I stopped doubting my ability to solve a new problem
the first time a mentor told me, “You think like a builder”
the realization that pressure doesn’t break you; it clarifies you
the friendships built in rooms where everyone was half-awake but fully alive

Hackathons do something subtle but profound:
they turn you into someone who believes in your ability to create — consistently, courageously, and under pressure.

Winning becomes a natural byproduct of the builder you’ve become.

Final Reflection

If there is one message I want to leave you with, it’s this:

Winning hackathons isn’t about outperforming others.
It’s about outgrowing every previous version of yourself.

You win by thinking clearly, building intentionally, simplifying relentlessly, and pitching with emotion.
You win by preparing before others begin.
You win by understanding your users instead of overwhelming your judges.
You win by choosing meaning over buzzwords.
You win by trusting your team.
You win by telling a story worth remembering.

And if you keep showing up — with clarity, depth, curiosity, and heart — you won’t just win hackathons.

You’ll win the confidence and competence to build whatever future you imagine.

Your Portfolio Is Probably Missing This One Thing (And It Matters More Than You Think)

Tue, 28 Apr 2026 12:05:57 +0000

A lot of developers spend weeks building portfolios.

They add:

Projects ✅
Skills section ✅
GitHub links ✅
Nice UI ✅

And still…

It doesn’t stand out.

Why?

Because many portfolios are missing one thing that matters a lot:

Context.

Or more specifically:

The story behind your projects.

And trust me…

This matters more than you think.

Most Portfolios Look Like This

Project Card 1
Project Card 2
Project Card 3

Tech stack:

React
Node.js
MongoDB

Looks good.

But there’s a problem.

It tells me what you built

Not:

Why you built it
What problem it solves
What challenges you faced

And that’s where strong portfolios become different.

Recruiters Don’t Just Want Projects

They want proof you can think.

A project title alone doesn’t show that.

Example:

❌ “Built Job Portal using MERN”

Okay…

But so what?

Now compare:

✅ Built a job portal solving fragmented job discovery for freshers, with search filters, role-based auth, and scalable backend APIs.

Very different signal.

One shows code.

One shows engineering thinking.

What Your Portfolio Should Include

For every serious project, add:

1. Problem Statement

What problem were you solving?

Not:

“I built a chatbot”

Instead:

“I built a chatbot to simplify candidate support queries.”

Huge difference.

2. Architecture Thinking

Show how you designed it.

Talk about:

Frontend
Backend
Database
APIs
Deployment

Now you sound like a builder.

Not just a coder.

3. Challenges You Faced

This is massively underrated.

Talk about:

Bugs you solved
Scaling issues
Performance fixes
Deployment problems

Because real projects have struggles.

And solving them is experience.

4. Tradeoffs You Made

This is advanced… and powerful.

Example:

Used JWT instead of sessions because…

That shows decision making.

Recruiters love that.

5. Live Demo + Proof

Please…

Don’t just show GitHub.

Show:

Live demo
Screenshots
Demo video
README
Use cases

A project people can try > a repo people may never open.

Projects Don’t Impress.

Project Thinking Impresses.

Read that again.

Anyone can clone a project.

Not everyone can explain:

Why it exists
Why it was designed that way
Why choices were made

That’s what makes portfolios memorable.

Common Portfolio Mistake

Many developers think:

More projects = better portfolio

Not always.

3 strong projects with depth
can beat

10 shallow projects.

Every time.

⚡ Think Product, Not Assignment

Don’t present projects like college submissions.

Present them like products.

Instead of:

“Task App”

Say:

“Task management tool built to solve team workflow tracking.”

Sounds completely different.

Because it is.

A Better Portfolio Formula

Try this:

Project + Problem + Architecture + Challenges + Demo

That combination is gold.

Final Thought

Most portfolios focus on showing code.

Great portfolios show thinking.

And in interviews…

Thinking often matters more.

So if your portfolio feels incomplete…

Maybe you don’t need another project.

You may just need better storytelling around the projects you already have.

And honestly…

That might be the missing piece

What do you think every developer portfolio should include?

Live demos?
Case studies?
Architecture diagrams?

Let’s discuss

Portfolio #Developers #SoftwareEngineering #WebDevelopment #BuildInPublic #CareerAdvice #GitHub

How I Review PRs with AI — Without Losing My Own Judgment

Sun, 26 Apr 2026 14:07:05 +0000

Originally published on Medium:
https://medium.com/@rajkundalia/how-i-review-prs-with-ai-without-losing-my-own-judgment-f930ad30dc60

Over the last few months, my code review queue has changed completely. With agentic coding, PRs are larger, faster, and harder to reason about.

I needed a system that was faster, but I absolutely did not want to just hand things off to an AI and call it a review.

Built-in tools exist. Claude Code has /review or /deep-review, and GitHub Copilot's PR review is decent out of the box. If you just want an AI pass, they work fine. But I am not optimizing for just an AI pass; I am optimizing for understanding and architectural signal.

Here is a repeatable framework I use to let AI handle the heavy scanning, while I keep the heavy thinking and judgment firmly in my own hands.

(Note: All the prompts referenced below are open-source in my GitHub repo: https://github.com/rajkundalia/ai-code-review-prompts. They are tool-agnostic — paste them into Claude, ChatGPT, Cursor, or whatever you prefer.)

The Golden Rule: Context Isolation

Before we get into the phases, there is one non-negotiable rule that makes this entire system work: One AI session per PR.

If you mix your own daily work, multiple PR reviews, and random questions into a single AI session, you lose context. PR reviews are context-heavy. When a colleague replies to your comment four days later, having a dedicated, preserved AI session helps you instantly remember your mental model and why you left that comment in the first place.

Keep the thread alive from the start of the review through the merge.

The 4-Phase PR Review Workflow

When I load my initial prompt, it gives me a starting point: a high-level summary, the files touched, and the core intent of the PR. From there, I move through four distinct phases. Do not skip ahead.

Phase 1: Build Understanding (Human First)

What happens next is entirely mine. I go file by file, line by line, and ask the AI questions until I have built my own understanding of the flow:

What is this doing?
Where is this data model used further downstream?
What breaks if this assumption changes?

This is deliberately manual. Anything I still do not understand after interrogating the AI, I flag for a human comment.

If you skip this phase, you're not reviewing the code — you're reviewing the AI's opinion of the code.

Phase 2: AI First Pass (Filter the Noise)

This is where the AI does its first real pass, flagging standard issues and inconsistencies. This is intentionally a surface pass.

The reason this is a separate phase from the deep review is simple: I want the obvious stuff caught and out of the way early. It gives me a chance to dismiss irrelevant suggestions immediately, ensuring the next phase isn't cluttered with noise.

Think of this as signal extraction, not decision-making.

Phase 3: The Deep Review (Pressure Testing)

This is the heaviest phase, driven by a few specific forcing functions:

The "Chief Programmer" & "Chief Architect" Persona
Giving the AI a specific role produces sharper, more critical output than a generic "review this code." You can adjust the role to fit your domain, e.g., chief AI engineer if you are reviewing prompt code.

Real Coverage vs. Theater
AI agents generate a massive amount of tests. Left unchecked, they will write tests for data models with no logic, or tests that just verify Python works. I explicitly prompt the AI to look for meaningful behavior validation so we catch the noise upfront. It is better than constantly asking the AI to remove redundant tests.

Tests should prove behavior, not existence.

Playing Devil’s Advocate
I force the LLM to question its own assumptions. What could go wrong? Where would this fail in production three months from now?

This surfaces edge cases that standard reviews easily miss.

Phase 4: The Verdict

Finally, I combine my Phase 1 understanding with the AI's deep review insights. The AI helps me classify the findings into:

Must-fix blockers
Good-to-have stylistic suggestions
Noise to be discarded

The Author's Duty: Self-Review

Before your code ever reaches another human, it is your responsibility to review it.

I converted my PR review framework into a self-review prompt. I run through the exact same phases on my own code. The output here is highly surgical: it tells me the file, the line, what is wrong, and what to do instead.

The goal is simple:

The comments you eventually get from your peers should be about high-level design decisions — not trivial things you could have caught yourself.

You get serious brownie points for consistently raising high-quality, pre-vetted PRs.

Scaling the Process

Not every PR needs all four phases.

A 10-line config change → quick pass
A 1,000-line refactor → full deep review

Match the depth of review to the risk and complexity.

Over-reviewing small changes is wasteful.
Under-reviewing large ones is dangerous.

Final Thoughts

I am not offloading my thinking to an AI. I am using it to explore faster, validate assumptions, and stress-test decisions. The thinking is still mine.

The leverage is new.
The responsibility isn’t.

These tools are incredibly powerful — but you still need to hold the leash.

I’ve open-sourced the prompts and guidelines I use:
https://github.com/rajkundalia/ai-code-review-prompts

If you have better ideas, improvements, or ways to reduce noise — I’d genuinely like to see them.

Beyond the Terminal: My Hunt Through the Linux File System

Sat, 25 Apr 2026 05:07:24 +0000

At first, Linux felt like magic. You open the terminal, type a command… and things just work. No questions asked. But after a while, that “magic” started bothering me.

Because I kept thinking:

Where is all of this actually happening?
How does the system know what to do?

Like… when I connect to the internet, where is that configuration stored?
When a user logs in, where is that data coming from?
When something breaks, where does Linux keep track of it?

These weren’t just random questions anymore. They were pulling me deeper.

So instead of just using Linux… I decided to explore it. Not like a normal user.
But like someone trying to understand what’s going on behind the scenes.

Digging into folders.
Opening system files.
Trying to connect the dots.

And what I discovered?

It completely changed how I look at Linux. Because behind every command…
there’s a system quietly doing a lot more than we realize.

`/etc` - The Place Where System Behavior Lives

The first place I explored was /etc, because I kept hearing that it’s important.

So I went inside:

cd /etc
ls

At first, it just looked like a collection of random files. But the more I opened them, the more I realized something important.

/etc is not just a folder.

It is where Linux stores all configuration that controls system behavior.

When I opened files like:

cat /etc/hosts
cat /etc/passwd

I could literally see how my system is configured.

This made me realize why this folder exists. Instead of hardcoding system behavior deep inside programs, Linux stores configurations as editable files. This means the system becomes flexible you can change behavior without touching the core system.

The problem this solves is huge. Imagine if you had to recompile the OS just to change a setting. That would be impossible for daily use.

But with /etc, Linux separates configuration from execution.

And the insight that hit me was this:
My system is not controlled by hidden magic. It’s controlled by plain text files that I can read and understand.

`/etc/resolv.conf` - How My System Finds Websites

One thing I never really questioned was typing something like:

ping google.com

It just works. But then I stopped and thought:

How does my system even understand what “google.com” is?
Because at the end of the day, computers don’t understand names, they understand IP addresses.

So I decided to dig into it.

I ran:

cat /etc/resolv.conf

And I saw this:

nameserver 10.0.2.3

At first, this confused me.

I was expecting something like 8.8.8.8 (Google DNS).
But this… looked different.

So what is this `10.0.2.3`

It turns out, this is not a public DNS server. It’s a local DNS resolver provided by my virtual machine environment

Since I’m running Linux inside a VM, my system is not directly talking to the internet.

Instead, it works like this:

My Linux system → asks 10.0.2.3 → which then forwards the request to actual DNS servers

So basically, 10.0.2.3 is acting like a middleman.

Why does this file exist?

This file tells the system: “If you don’t understand a domain name, ask this nameserver.”

Without this, the system wouldn’t know where to send DNS queries.

What problem does it solve?

Humans use names like:

But systems use IP addresses. So DNS acts as a translator between human-friendly names and machine-friendly IPs.

And /etc/resolv.conf tells Linux where that translator lives.

What I found interesting

The biggest realization for me was this: My system isn’t always directly using public DNS.
In my case, it’s using a local resolver (10.0.2.3), which then handles everything behind the scenes.

That means even something as simple as opening a website involves:

local system configuration
virtual networking layers
DNS forwarding

Small but powerful insight

Just by changing this file, I can control how my system resolves domains.

Which means I can switch to a faster DNS, block certain domains, & control network behavior.

And honestly… Something as simple as opening a website suddenly felt way deeper than I thought.

Routing Table - How Linux Decides Where Data Goes

Next, I wanted to understand how my system sends data.

So I ran:

ip route

What I saw was something like:

This is the routing table.

At a basic level, this tells the system: “If you don’t know where to send data, send it to this gateway.”

In my case, that gateway is 10.0.2.2.

This exists because your system doesn’t just randomly send data. It needs a structured way to decide where packets go.

The problem it solves is routing confusion. Without this, your system wouldn’t know whether to send data locally or over the internet.

The second line (10.0.2.0/24) tells the system that anything in this local network range can be accessed directly, without going through the gateway.

The insight here was surprising: My system is not just sending data it’s making routing decisions like a mini network controller.

And since I’m using a virtual machine, 10.0.2.2 is actually a virtual gateway, not a physical router.

I always thought networking happens “somewhere outside”. But Linux is actively involved in deciding paths. And in this case, it’s even routing traffic through a virtual layer before it reaches the real network.

`/var/log` - The Silent Observer of Everything

Then I explored logs:

cd /var/log
ls

And opened files like:

cat messages
cat secure

This folder is basically the memory of the system.

Everything that happens:

logins
errors
services
system events

…it all gets recorded here. This exists because systems need a way to track what’s happening internally.
The problem it solves is debugging and monitoring. Without logs, if something breaks, you’re blind.

But what really stood out to me was this:

Linux doesn’t interrupt you with errors all the time.
It quietly writes everything down.

It’s like the system is constantly saying:
“I’ll tell you everything… but only if you come and look.”

`/etc/passwd` & `/etc/shadow` - How Linux Handles Users Securely

To understand users, I ran:

cat /etc/passwd
sudo cat /etc/shadow

What I saw was interesting.

/etc/passwd contains user details.

But passwords are not there.

They’re stored in /etc/shadow, which requires special permissions.

This exists for security reasons. If everything was stored in one place, anyone could read sensitive data.

The problem it solves is protecting user credentials.

But the insight here was deeper:

Linux separates identity from authentication.

/etc/passwd → who you are
/etc/shadow → how you prove it

That separation makes the system more secure by design.

Permissions - Built-In Security, Not an Add-On

When I ran:

ls -l

I saw things like:

-rwxr-xr--

At first, it looked confusing. But then i understood: this is how Linux controls access to every file.

Permissions exist because not every user should have full control over everything.

The problem it solves is unauthorized access and system damage.

But what really stood out was:

Security in Linux is not something extra.
It is built directly into the file system itself.

Every file carries its own rules.

`/proc` - Where I Saw the System Live

This was the most surprising part

I explored:

cd /proc
ls

And then:

cat /proc/cpuinfo
cat /proc/meminfo

What I realized is: These are not real files stored on disk. They are generated in real time by the kernel. This exists so users and programs can access live system data.
The problem it solves is system monitoring.

But the insight here blew my mind:

When I read these files, I’m not reading stored data.
I’m interacting with the system live.

It felt like I was directly talking to Linux.

`/dev` - Where Hardware Becomes Files

Then I explored:

ls /dev

I saw entries for disks, terminals, and devices.

This exists because Linux treats hardware as files.

The problem it solves is complexity. Instead of learning different ways to interact with devices, everything becomes file operations.

And the insight here was simple but powerful: In Linux, everything is unified under one idea: files.

That consistency makes the system elegant.

`/boot` - The Starting Point of Everything

Finally, I checked:

ls /boot

This folder contains the kernel and bootloader files.

This exists because the system needs instructions to start itself. The problem it solves is system initialization.
And the insight: Without /boot, Linux cannot even begin to run.

It’s literally where everything starts.

`/var/log/secure` - Who Tried to Enter My System?

While exploring logs, I went deeper:

So I ran:

sudo tail -f /var/log/secure

And what I saw was honestly eye-opening.

This file logs things like:

login attempts
sudo usage
authentication failures

Basically… anything related to who is trying to access the system.

This exists because systems need to keep track of access.

Who logged in
Who tried and failed
Who used admin privileges

Without something like this, there would be no way to monitor system security.

The problem it solves is pretty serious. If something suspicious happens, like:

repeated failed login attempts
unauthorized access
misuse of sudo

you need a way to trace it. And that’s exactly what this file does. The insight here really changed how I see system logs.

Linux doesn’t constantly warn you about everything.
Instead, it quietly records everything in the background.

And this file becomes like a security audit trail. If someone tries to break into your system… the evidence is already there.

`/dev/null` - The Black Hole of Linux

This one was honestly one of the coolest discoveries.

I started with something simple:

ls /dev/null

Then I tried this:

echo "hello" > /dev/null

And… it disappeared.

No output. Nothing showed up anywhere. That’s when I realized what was happening.

/dev/null is a special file that discards anything written to it. This exists because sometimes, you don’t care about output. Maybe a command is producing too much noise, or you just want to run something silently.

The problem it solves is simple but important. Without /dev/null:

your terminal would get cluttered
scripts would print unnecessary output
things would become harder to manage

The insight here was actually pretty cool.

/dev/null is like a black hole. Anything goes in… and nothing comes out. And suddenly, this made sense:

command > /dev/null 2>&1

This basically tells the system:

Run the command, but don’t show me anything.

And now I finally understood why developers use it so often.

`systemd` - The Hidden Manager Running Everything

Then I got curious about what’s running behind the scenes.

So I explored:

cd /etc/systemd/system
ls

At first, it just looked like a bunch of configuration files.

But then it clicked. This is where system services are defined and managed.

systemd is basically the component that handles:

services
startup processes
background tasks

It’s the reason your system feels “alive” even when you’re not doing anything.

This exists because modern systems need automation. You don’t manually start things like:

networking
logging
system monitoring

Every time you boot your system.

The problem it solves is huge. Without something like systemd you would have to manually start every service after boot . Which is clearly not practical. The insight here was interesting. Even when I’m doing nothing…
Linux is still running multiple services silently in the background. Things just work because systemd is managing everything for me.

`/boot/grub2/grub.cfg` - The First Instructions Linux Follows

This one felt powerful.

I ran:

cat /boot/grub2/grub.cfg

And I was looking at the configuration used by GRUB the bootloader.

This file tells the system:

which kernel to load
how to start Linux

This exists because before Linux even starts, something needs to:

initialize the system
load the kernel
hand over control to the OS

And that’s exactly what the bootloader does.

The problem it solves is fundamental. Without this configuration:
the system wouldn’t even know how to boot. No startup. No OS. Nothing.

The insight here made me realize how critical this file is. This is literally where the system’s startup behavior is defined. If this file gets corrupted Linux won’t even start
And that’s when it hit me… This isn’t just another config file. This is the starting point of everything.

After exploring all these parts, one thing became very clear to me:

Linux is not just an operating system
It is a collection of well-structured systems connected through files

From booting → to users → to networking → to logs

Everything is transparent, accessible, & understandable.
And once you start exploring it like this… you stop guessing and start understanding.

Linux is not hiding anything from you.
Everything is there in files, waiting to be explored.

The moment you stop just using Linux… and start reading it… that’s when things finally start clicking.

Understanding Variables and Data Types in JavaScript

Sat, 25 Apr 2026 04:08:11 +0000

I remember when i first started learning JavaScript everything was so confusing, i felt completely overwhelmed.
Variables, Data Types, let, const, Scope, Hoisting, Temporal Dead Zone (TDZ)... ahh so many things.

It felt like everyone else understand it and i was just trying to memorize these things without actually understanding what was going on under the hood.

So in this blog i’m going to cover and explain slowly, clearly & practically everything the way i wish someone had explained it to me when i started learning JavaScript.

By the end of this blog you won’t just know the definitions but you will understand how JavaScript behaves actually.

So let’s start from the very beginning.

What are JavaScript Variables?

Let’s forget the technical definition for now and think of a variable like a box
So start with this Imagine you have a box

You put something inside it
Write a lable on it
Open it later to see what’s inside the box
Later replace what’s inside if needed

That box is exactly what a variable is

In JavaScript a variable is simply a named container that stores data so we can use it later.

for example:

let name = "Nausheen";

How I see it in my head:

name => the label on the box
"Nausheen" => what's inside the box

But the question is: Why do we need variables?
The reason is simple because programs need memory

When you log into a website, it needs to remember:

Your username
Your password
Whether you’re logged in or not
What’s in your cart

Without variables, JavaScript wouldn’t be able to remember anything not even for a second.

Variables are the foundation of everthing

How I Declare Variables (var, let, const)

Here we go In JavaScript, we have three ways to create variables:

var
let
const

But the thing is they are not the same. And this is where beginners usually get confused.
So, let me break it down the way I personally understand it and where to use them.

1. var (old way)

var age = 20;

yup simple, this is how it works.

And yes, you can also change it:

age = 21;

But here’s what I’ve learned over time:
var has some strange behaviors that can create confusion in larger programs.

For example:

var city = "Delhi";
var city = "Mumbai"; // No error

It allows redeclaration in the same scope.

That might not seem dangerous now, but in a big project, this can silently overwrite values & cause bugs that are hard to track.

That’s why in morder JavaScript, we mostly avoid var

Not because it’s bad, but because there are safer alternatives.

2. let (Flexible and Modern)

let score = 50;

I use let when I know that value might change later.

score = 60; // Perfectly fine

But here’s something important:

let score = 70; // Error

You cannot redeclare a let variable in the same scope.

And honestly, I like this.
Because it prevents accidental mistakes.

3. const (Fixed and Safe)

const birthYear = 2004;

Ok so, when I write const I'm basically saying:

I don’t want this value to change

And JavaScript respects that.

birthYear = 2005; // Error

This is why I personally follow this rule:

I use const by default
I switch to let only when I need to change the value

This makes code safer and more predictable.

Difference Between var, let, and const

If you’re just starting out, here’s what I’d suggest you:

Use const most of the time
Use let when necessary
Forget var for now

What Are Data Types?

What’s Inside the Box?

Now let’s talk about what we actually store inside variables.

When I say "data type" I'm simply asking:
What kind of value is inside this variable?

If variables are boxes, data type describes what kind of thing is inside the box.

In JavaScript, there are many types. But as beginners, we focus on primitive data types.

Basically, there are two categories of data types:

Primitive Data Types
Non-Primitive Data Types

But in this blog, we will only focus on primitive data types.

The main primitive types in JavaScript are:

String
Number
Boolean
Null
Undefined

Let’s understand them properly

1. String - Text Data

Whenever I want to store some text data, I use a string.

let name = "Nausheen";
let message = "Hello World";

String are always written inside quotes.
Without quotes, JavaScript thinks it’s a variable name.

Strings are used for:

Name
Emails
Messages
Addresses

Basically, anything that’s text.

2. Number - Numeric Values

let age = 21;
let price = 99.99;

In JavaScript, there is only one number type.

It doesn’t seperate integers and decimals unlike many other programming languages

Whether it’s 21 or 99.99 , both are simply number.

Numbers are used for:

Age
Score
Prices
Calculations

3. Boolean - True or False

Booleans are very simple but very powerful.

They only have two values:

true
false

let isLoggedIn = true;
let hasPermission = false;

Booleans are mainly used in decisions.

For example:

Is the user logged in?
Did the form submit successfully?
Is the password correct?

Most conditions in programming rely on booleans.

4. null - Intentionally Empty

When I use null, I'm basically saying:

I’m intentionally keeping this empty for now.

let selectedUser = null;

This means:
I will assign a real value later.

5. undefined - Not Assigned Yet

If i declare a variable but don’t give it a value:

let score;

JavaScript automatically assigns it undefined.

That means:
The variable exist, but nothing is inside it yet.

The difference between null and undefined is subtle but important:

undefined => JavaScript gives it automatically
null => You assign it intentionally

What is Scope?

When I first heard the word scope, it sounded technical and abstract. But one I simplified it in my mind everything become clearer.

So, Scope simply answers one question:
Where can I access this variable?

That’s it……

Scope determines the visibility & accessibility of variables in different parts of your prograrm.

Let’s take an example of “The Rooms in a House”
Imagine scope as rooms inside a house

Each { } block is like a separate room.

If I place something inside one room, I can only access it inside that room. I cannot randomly walk into another room & expect that thing to be there.

In JavaScript, a block looks like this:

{
    let message = "Hello there";
    console.log(message); // It works
}
console.log(message); // ReferenceError

Here, message was created inside the block (inside the "room").

So when we try to access it outside the block, JavaScript throws a ReferenceError.

Not because the value is undefined
But because it does not exist in that scope.

That’s an important distinction.

Block Scope (let & const)

Variables declared using let and const follow block scope.

A block is anything inside { }:

if statements
for loop
while loop
plain curly braces
function

if (true) {
    let age = 22;
}
console.log(age); // ReferenceError

Here, age only exists inside that if block.

Once execution leaves that block, the variable is gone.

This behavior makes your code safer because:

It prevents accidental overwriting of variables
It avoids naming conflicts
It keeps variables limited to where they are needed

This is one of the main reason why JavaScript prefers let and const.

They give you controlled scope.

Function Scope

Before ES6, Javascript only had function scope.

That means variables declared with var are accessible anywhere inside the function they were declared in regardless of blocks.

function test() {
    if (true) {
        var name = "Nausheen";
    }
    
    console.log(name); // works
}

Even though name was declared inside the if block, it is accessible outside that block but still inside the function.

Why?
Because var doesn't follow block scope.

This difference is the root cause of many bugs in older JavaScript code.

Why `var` Is Problematic?

Let’s look at this code example:

if (true) {
    var count = 10;
}
console.log(count); // Works (unexpected behavior for beginners)

Here, count leaks outside the block.

This can cause:

Variable collisions
Hard to debug errors
Accidental overwrites
Confusing behavior in loops

That’s why modern JavaScript discourages to use var unless absolutely necessary.

Global Scope

If we declare a variable outside of any block or function, it belongs to the global scope.

Let’s see a Example:

let globalMessage = "Hi"; // Global variable
function greet() {
    console.log(globalMessage); // Accessible
}

Global variables can be accessed everywhere in the program.

But here’s the danger:

Too many global variables make your code messy & hard to maintain.
Think of global scope as the entire house, if you throw everything in the living room, it becomes chaos.

Good developers minimize global scope usage.

Function Inside Function

Until now, we talked about scope like rooms in a house.

Let’s now imagine something more interesting
what if a room had another room inside it?

Now let’s see what happens when functions are inside other functions…

Yes this is completely valid look at this code:

function outer() {
    let outerMessage = "Hello from outer";
    function inner() {
        console.log("Hello from inner");
    }
    
    inner();
}
outer();

Here, outer is one room, inner is smaller room inside it.

Now let’s test something important.

function outer() {
    let outerMessage = "Hello from outer";
    function inner() {
        console.log(outerMessage); // works
    }
    
    inner();
}
outer();

The inner function can access the outer function’s variable.

But, can outer access inner’s variable to, let test that also.

function outer() {
     function inner() {
        let secret = "Hidden"
    }
    
    inner();
    console.log(secret); // Error
}
outer();

Oops outer cannot access inner’s variables.

So, remember access only flow upward means:
Child -> Parent
Never Parent -> Child

This idea is the foundation of lexical scope.

But before we go there……
First we need to understand something deeper.

How JavaScript actually runs you code

How JavaScript Actually Runs Your Code (Execution context)

Most beginners think JavaScript reads code line by line.

Reads line 1
Then line 2
Then line 3…

But that’s not exactly true.

JavaScript runs your code in two phases.
And this is where everything changes.

Phase 1: Memory Creation Phase

Before executing anything…

JavaScript first scans you entire code.

It allocates memory for variables
Stores function declarations
Sets up scope

But keep this in mind:

Variables don’t get their real values yet.

var => initialized with undefined
let and const => created but not initialized
Functions => fully stored in memory

console.log(name); // undefined
var name = "Nausheen";

undefined why?

Because during memory phase:

var name = undefined;

Then during execution phase:

name = "Nausheen";

This behavior is called hoisting, but we’ll go deeper into that soon… yes we’re going to cover that too.

Phase 2: Code Execution Phase

Now JavaScript starts running the code line by line.

Values are assigned
Functions get executed
console.log() run

Memory Phase always comes first
Then comes the Execution Phase

Simple as that. Yes nothing scary

Call Stack

Every time a function runs… JavaScript creates a new execution context.

These execution contexts are stacked on top of each other.
Think of the call stack like a stack of plates

When you call a function:

Javascripit puts that function on top of the stack

When the function finishes:

JavaScript removes it from the top

That’s it

It always works Last In, First Out (LIFO).
The last function added is the first one removed

function one() {
    two();
}
function two() {
    console.log("Hello");
}
one();

Let’s see what happens step by step:

Global code starts running
one() is called -> added to stack
Inside one(), two() is called -> added on top
two() finishes -> removed
one() finishes -> removed
Back to global

So, flow looks llike this:

Global
one()
two()

Then it goes backward:

two() removed
one() removed
back to Global

This is how JavaScript manages execution

Hoisting - What It Actually is (And What Most People get Wrong)

Now that you understand execution context… Hoisting will make sense.

When I first learned hoisting, someone told me:

JavaScript moves variables to the top

And honestly?..

That explanation confused me more than it helped.

Because JavaScript doesn’t physically move your code
Nothing jumps to the top
Your code stays exactly where you wrote it.

So the question is what’s really happening?

To understand hoisting properly, we have to go back to something we already learned:

Execution context

Memory Phase

Execution Phase

Hoisting is simply a result of how JavaScript prepares memory before running code.

How `var` Hoisting Actually Works

Let’s see:

console.log(name); // undefined
var name = "Nausheen";

Output is undefined why not error?

Because during memory phase
JavaScript does this internally:

var name = undefined;

Then during execution phase:

name = "Nausheen";

So when console.log runs,
name exists but its value is undefined

So, remember this is important:

var is declared during compilation
It is also initialized to undefined during compilation

That’s why it’s accessible early.

Why `var` Can Be Dangerous

Now look at this:

function example() {
  console.log(x); // undefined
if (false) {
    var x = 10;
  }
  console.log(x); // undefined
}
example();

undefined
undefined

Even though the if block never ran.

Why?
Because var x was hoisted to the function scope.

This is the dangerous part.
var ignores block scope.

It can silently create undefined variables in unexpected places.

This is one of the biggest reasons modern JavaScript prefers let and const.

Function Hoisting

Function declarations behave differently it’s even more powerful.

They are not just declared
They are fully initialized during compilation

greet();
function greet() {
  console.log("Hello!");
}

This works perfectly.

Because during compilation:

greet: [complete function stored in memory]

The entire function body is available before execution begins.

That’s why function declarations are called:
Fully hoisted

Function Expression vs Function Declaration

Now this is important.

sayHi();
var sayHi = function () {
  console.log("Hi");
};

Now this throws:
TypeError: sayHi is not a function

Why?
Because only variable is hoisted

var sayHi = undefined;

Which causes the error.

The difference is

Function Declaration => Fully hoisted
Function Expression => Only variable hoisted

Now Let’s Talk About `let` and `const`

Here’s where things get misunderstood

Many people say:

let and const are not hoisted

That is wrong…

They are hoisted

But they behave differently

During compilation:

let and const are registered in memory
But they are NOT initialized

This creates something called… TDZ

Temporal Dead Zone (TDZ)

Another scary term TDZ. Ahh, now what’s that?
Don’t worry. I’ll keep it simple

This is one of the most misunderstood concepts.

The Temporal Dead Zone is:

The time between when a variable is hoisted

*And when it is initialized

Let’s see it:

console.log(age);
let age = 25;

This throws:
ReferenceError: Cannot access 'age' before initialization

Why?
Beause:

age exists in memory
But it is uninitialized
It is in the Temporal Dead Zone

The TDZ starts:
At the beginning of the block

And ends:
At the line where the variable is declard

TDZ Is About Time, Not Position

Very important, TDZ is not about where the variable is written.
It’s about time.

function test() {
  console.log(score);
  let score = 100;
}
test();

From the moment the function starts running,
score exists.

But until let score = 100 executes,
it is in the TDZ.

That’s why accessing it throws an error.

Proof That let Is Actually Hoisted

Look at this:

let x = "outer";
function demo() {
  console.log(x);
  let x = "inner";
}
demo();

This throws ReferenceError.

If let x inside demo was NOT hoisted,
JavaScript would use the outer x and print "outer".

But it doesn’t.

Why?
Because the inner x is hoisted to the function scope.
It creates a TDZ.

That proves:

let is hoisted
It is not initialized

That difference change everything.

How const Behaves

const works exactly like let regarding hoisting and TDZ.

But with one extra rule:
You must initialize it immediately.

const name; // SyntaxError

Correct:

const name = "Nausheen";

It is hoisted.
It has TDZ.
But it must be initialized.

Common misconceptions you should always remember

“Hoisting moves code to the top”
No.

Code stays exactly where you wrote it
Memory is prepared before execution

“Only var is hoisted”
Wrong.

All declarations are hoisted:

var
let
const
function
class

The difference is initialization timing.

“TDZ means variable doesn’t exist”
Wrong.

The variable exists.
It just cannot be accessed yet.

Why TDZ Is Actually a Good Thing

With var, this is allowed:

var total = total + 5;

This creates weird undefined behavior.

With let or const, you immediately get an error.

TDZ protects you from accidental bugs.
It forces cleaner code.
It makes JavaScript safer.

Beyond Code: Lessons from My Website Experience

Wed, 22 Apr 2026 03:33:00 +0000

A website hiccup made me rethink how I approach projects, habits, and priorities. It's a reminder that growth isn’t just technical, it's personal too.
Read the full reflection: Beyond Code: Lessons from My Website Experience

The Story of Python Togo Building a Strong Python Community in Togo

Mon, 20 Apr 2026 12:24:12 +0000

Our Story – How Python Togo Began

At the heart of Lomé, Togo, a spark was lit not with fire, but with code.
This is the story of Python Togo, a community born from passion, fueled by resilience, and driven by the belief that Python can change lives and transform an entire tech ecosystem.

Humble Beginnings

It all started back in 2022 when @Wasiu Ibrahim (Wachiou BOURAIMA) and @Geoffrey Logovi joined the Microsoft Ambassadors program. Through this experience, they discovered the power of learning in community, mentorship, networking, and the transformative impact of volunteering.

Attending both local and international events online and in-person opened eyes to what a strong developer community could achieve. While some may say volunteering doesn’t pay, we believe it builds something far more valuable: growth, knowledge, and connection.

By 2023, Togo’s tech scene was growing rapidly. Developer communities were emerging across campuses, sparking friendships and collaborations that would lay the groundwork for what was to come. Events like DevFest Lomé, TDevFest, Tech Communities Day, MLSA Togo Meetups became meeting points for leaders who shared a common dream: building something bigger together.

Then came 2024 the year everything changed.

The Turning Point: PyCon Africa 2024

When financial aid applications for PyCon Africa 2024 opened, we saw an opportunity. We shared it widely, and many from Togo applied. Only five received support but we refused to let that limit us.

So we did what any strong community would do: we stepped up together. Some members contributed financially, others reached out through networks. Thanks to Julius Boakey from PyClubs UG / Python Ghana, several of our members received vouchers. For transport and accommodation, we pooled resources so more people could attend.

The result? A life-changing experience in Accra. We met PSF Directors Deb Nicholson, Ex Director David Mertz, Python community founders Many and Michael Young Python Ghana, Kafui Alordo Python Ho, Steve Yonkeu and organizers from around the world Samson Gody, Ditiro Rampate. And amid the conversations, workshops, and late-night chats, one idea took root:

Why not bring this energy back home?

And just like that, Python Togo was born.

PyDay Togo 2024 – Our First Big Step

Inspired by PyCon Africa, we organized PyDay Togo 2024, also known as PyCon Africa Extended Togo 2024. We expected about 50 attendees.

We got over 200 registration, and 150 attendees.

PyCon Togo 2025 – Building Something Greater

Now, we’re preparing for PyCon Togo 2025 our most ambitious project yet. This time, we want to do things right: better equipment, stronger organization, and inclusive access for participants from all corners of Togo and beyond.

This isn’t just another tech event. It’s the beginning of a movement one that empowers developers, educates students, and creates opportunities where they matter most.

Our Vision & Mission

Who We Are

Python Togo is a vibrant, grassroots community dedicated to growing the Python ecosystem in Togo. Founded by passionate developers and educators, we are united by a shared love for Python and a deep commitment to lifting up our local tech community.

We believe that open source, collaboration, and education are the keys to unlocking potential especially in places where opportunity has been scarce.

Our Vision

To create a thriving, innovative Python ecosystem in Togo that is recognized regionally and globally. We envision a future where Togo becomes a hub of Python excellence in West Africa, where developers use Python to solve real-world problems and build scalable solutions.

Our Mission

We are committed to:

Promoting Python as a tool for innovation and education
Training the next generation of developers
Fostering collaboration and knowledge-sharing
Creating pathways to professional growth
Launching impactful open-source projects
Building partnerships that strengthen the tech landscape

Our Values

Collaboration: We grow together.
Innovation: We challenge the status quo.
Excellence: We strive for quality in everything we do.
Inclusivity: Everyone belongs here.

Our Strategic Goals

Skills Development: Regular training sessions, workshops, and hackathons
Community Growth: Build a community of over 1,000 active members by 2027
Strategic Partnerships: Collaborate with schools, companies, and global communities
Open Source Projects: Solve challenges with Python-driven tools
International Visibility: Represent Togo at major Python events worldwide
Diversity & Inclusion: Promote equal participation, especially among women

Join the Movement

Whether you're a developer, student, educator, company, or supporter of open source, you have a place in our story.

You can help us:

✅ Attend and support our events
✅ Mentor and teach others
✅ Sponsor our initiatives
✅ Partner with us for long-term growth
✅ Contribute to open-source projects
✅ Share our mission with your network

Get Involved Today

Join our Discord community
View our sponsorship opportunities
Email us at sponsorship@pytogo.org

Let’s build the future of Python in Togo together.

Thank You

If you’ve made it this far, thank you. Whether you’re reading this as a curious learner, a potential sponsor, or someone looking to give back, you’re part of what makes this possible.

Python isn’t just a language.
It’s a community.
It’s a movement.
And today, it’s alive and growing in Togo.

Welcome to Python Togo.
Let’s code the future together.

Connect & Follow Us

Kindly like and share your thoughts in the comments below. See you in a future article!

Why Every Backend Developer Should Know Bash

Tue, 17 Feb 2026 08:10:34 +0000

Modern backend development is filled with powerful frameworks, cloud dashboards, container orchestration tools, and CI/CD pipelines. It’s easy to spend most of your day inside an IDE or browser based admin panel and forget that, underneath it all, your application is running on an operating system.

And more often than not, that operating system speaks Bash.

If you’re a backend developer working with Linux servers, Docker containers, CI pipelines, or cloud infrastructure, learning Bash scripting and shell fundamentals is not optional it’s leverage.

Let’s explore why every backend developer should know Bash, and how this underrated skill quietly multiplies your effectiveness.

Bash Is the Native Language of Servers

Most production servers run Linux. Whether you’re deploying to a VPS, managing containers, or debugging in production, you’ll inevitably drop into a terminal.

Understanding Bash allows you to:

Navigate file systems confidently
Manage processes
Inspect logs
Automate repetitive tasks
Control services

Without Bash knowledge, you’re operating at the surface. With it, you control the environment your code depends on.

SEO keywords included naturally: Bash for backend developers, Linux shell scripting, backend automation

Debugging Becomes Faster and Smarter

When something breaks in production, dashboards don’t always tell the full story.

Bash helps you:

Tail and filter logs in real time
Search large log files with grep
Inspect running processes with ps
Monitor resource usage
Check open ports and network connections

Instead of guessing or waiting for alerts, you can investigate directly and make informed decisions.

The difference between a backend developer who “knows the framework” and one who “knows the system” often shows up during incidents.

Automation Saves Hours Every Week

Backend development involves repetitive tasks:

Running migrations
Clearing caches
Deploying builds
Rotating logs
Backing up databases

Bash scripting turns these into one command operations.

Even simple scripts like:

#!/bin/bash
php artisan migrate
php artisan config:cache
php artisan queue:restart

can reduce human error and save time during deployments.

Automation compounds. Small scripts today become powerful workflows tomorrow.

CI/CD and DevOps Make More Sense

Modern CI/CD pipelines whether GitHub Actions, GitLab CI, or Jenkins often rely heavily on shell commands.

If you understand Bash, you can:

Write cleaner pipeline scripts
Debug failing builds
Customize deployment workflows
Optimize container entrypoints

Instead of copy pasting commands from documentation, you’ll know what they actually do.

This level of understanding makes you more independent and more valuable to your team.

Containers and Docker Are Built on Shell Foundations

Dockerfiles and container environments rely heavily on shell commands.

If you don’t understand:

How environment variables work
How file permissions behave
How entrypoint scripts execute

you’ll struggle with container based deployments.

Bash bridges the gap between application logic and infrastructure behavior.

Bash Improves Your Mental Model of Systems

Learning Bash forces you to understand:

Standard input and output
Pipes and redirection
Process control
File permissions
Environment variables

These are foundational operating system concepts.

Once you grasp them, everything from web servers to container orchestration starts making more sense.

You Become More Self Sufficient

Backend developers who know Bash don’t wait for DevOps to solve every issue.

They can:

Investigate server errors
Patch quick fixes
Write temporary scripts
Analyze production behavior

This doesn’t mean replacing infrastructure teams. It means collaborating more effectively because you understand the language of the system.

You Don’t Need to Be a Bash Expert

The goal isn’t to master every obscure shell feature.

Start with:

Navigation and file operations
Process inspection
Basic scripting
Pipes and redirection
Cron jobs

Over time, your confidence grows naturally through real world usage.

Final Thoughts: Bash Is Quiet Power

Bash won’t trend on social media. It won’t replace your favorite framework. And it won’t magically make your code better overnight.

But it will make you more capable.

Backend development doesn’t stop at writing controllers, services, or APIs. It extends into the environment your code runs in. Bash gives you control over that environment.

In a world increasingly focused on abstraction, understanding the shell is grounding. It’s practical. It’s empowering. And it’s one of the highest return skills a backend developer can learn.

If this article reminded you to strengthen your shell skills, share it with a teammate who lives in the IDE but avoids the terminal. And if you enjoy practical backend insights that go beyond the surface, there’s more ahead.

10 Real-World Side Projects That Actually Impress Recruiters

Mon, 26 Jan 2026 22:52:41 +0000

10 Real-World Side Projects That Actually Impress Recruiters (With Examples)

Many developers believe that building *any* side project is enough to stand out. In reality, recruiters see hundreds of portfolios filled with to-do apps, weather dashboards, and tutorial clones. What truly makes a difference is not the number of projects — but how real, practical, and problem-driven they are.

In this article, we’ll explore 10 real-world side projects that recruiters consistently find impressive — because they demonstrate problem-solving, system thinking, and real-world engineering skills.

Why Recruiters Care About Side Projects

Side projects act as proof of work. They show how you think, how you structure code, how you handle trade-offs, and whether you can ship something usable. A strong project answers questions like:

Can this developer solve real problems?
Do they understand users, not just code?
Can they take a product from idea to deployment?

Let’s dive into the projects that consistently catch recruiters’ attention.

1. Job Application Tracker for Developers

What it solves:
Managing job applications across emails, spreadsheets, and portals is painful.

Why recruiters like it:
Shows CRUD skills, authentication, dashboards, filters, and real user value.

Example features:

Track application status (Applied, Interview, Offer)
Attach resumes, notes, and follow-up reminders
Analytics on response rates

2. SaaS Billing & Subscription Simulator

What it solves:
Understanding real-world SaaS billing logic.

Why recruiters like it:
Demonstrates backend complexity, payment flows, edge cases, and scalability thinking.

Subscription plans & upgrades
Invoices, retries, cancellations
Role-based access control

3. Community Platform for a Niche Audience

What it solves:
People want focused communities, not noisy platforms.

Why recruiters like it:
Shows full-stack thinking, moderation logic, engagement design.

Posts, comments, likes
User profiles and roles
Reporting and moderation tools

4. Open-Source Contribution Dashboard

What it solves:
Tracking open-source activity across repositories.

Why recruiters like it:
Shows API integration, data visualization, and OSS mindset.

5. Internal Tool for Small Businesses

What it solves:
Manual workflows inside small teams.

Why recruiters like it:
Internal tools mirror real engineering work more than consumer apps.

6. Real-Time Collaboration App

What it solves:
Live collaboration needs (docs, boards, code notes).

Why recruiters like it:
Demonstrates WebSockets, concurrency, and performance concerns.

7. DevOps Monitoring & Alert Tool

What it solves:
Visibility into system health.

Why recruiters like it:
Shows infra knowledge beyond frontend/backend silos.

8. AI-Powered Resume or Code Reviewer

What it solves:
Actionable feedback for developers.

Why recruiters like it:
Shows modern tooling, prompt design, and evaluation logic.

9. Learning Progress Tracker

What it solves:
Tracking skill growth over time.

Why recruiters like it:
Shows long-term thinking and user retention concepts.

10. Technical Writing Platform

What it solves:
Helping developers share knowledge clearly.

Why recruiters like it:
Strong signal of communication + engineering maturity.

How to Make Your Project Stand Out

Solve a real problem (even your own)
Write about your decisions and trade-offs
Show iterations, not just final polish
Document learnings and failures

Final Thought

Side projects don’t need to be massive — they need to be real, intentional, and visible. If you’re building something meaningful, don’t keep it hidden. Write about it, share it, and invite feedback.

Publishing your journey turns projects into opportunities. That’s how developers stand out.

The AI Mirror: How Generative Tools Are Changing Our Minds

Sun, 25 Jan 2026 11:20:21 +0000

As the Founder of ReThynk AI, I’ve started to notice something subtle, but powerful:

Generative AI doesn’t just produce output.
It reflects how we think.

AI is becoming a mirror. And many people are uncomfortable with what they see.

The AI Mirror: How Generative Tools Are Changing Our Minds

When people say, “AI output feels generic,” I often ask a harder question:

Was the thinking behind it generic too?

Generative AI doesn’t create ideas in isolation.
It responds to:

how clearly we think
how deeply we question
how specific our intent is
how honest our standards are

That’s why AI feels like a mirror.

What the mirror is showing us

1) Our thinking habits

If I rush, AI rushes.
If I’m vague, AI becomes vague.
If I’m thoughtful, AI becomes structured.

AI doesn’t just amplify intelligence.
It amplifies habits.

That’s uncomfortable because it removes excuses.

2) Our tolerance for “good enough”

AI can generate “fine” answers endlessly.

And that exposes something human:

how often we settle for surface-level thinking.

When people blame AI for blandness, they’re often reacting to the mirror, not the model.

3) Our relationship with effort

Before AI, effort was unavoidable.

Now, effort is optional.

And that changes how minds work.

Some people use AI to avoid thinking. Others use AI to think better, faster iterations, deeper exploration, and sharper framing.

Same tool. Different mindset.

The cognitive shift we’re living through

Generative AI is quietly changing how we:

start ideas (from blank page to first draft instantly)
evaluate quality (from intuition to comparison)
explore options (from linear to expansive)
learn (from memorisation to dialogue)

The danger is not AI replacing thinking.

The danger is thinking becoming passive.

The opportunity most people miss

The AI mirror can be used deliberately.

I use it to:

challenge my assumptions
surface weak logic
compare multiple perspectives
stress-test ideas before action

In this mode, AI doesn’t dull the mind.

It sharpens it.

The democratisation insight

Generative AI gives everyone access to a thinking partner.

But what they get out of it depends on what they bring in:

curiosity
clarity
responsibility
judgment

Democratisation of AI is not about equal tools.

It’s about equal opportunity to think better.

One-line takeaway

AI doesn’t lower the bar for thinking.

It reveals where our bar already was.

The mirror is here.

The question is: what will we choose to see, and improve?

Monoliths, NEPA, and Real Users: A Pragmatic Guide to Choosing Your Stack in Lagos

Tue, 20 Jan 2026 21:01:47 +0000

Why “boring” stacks quietly win

Let’s be honest.
The internet will make you feel as if you’re not on microservices, Kubernetes, and ten different managed services, you’re already behind.
But when you’re deploying from a place where power can disappear mid-deploy and users are on cheap Android phones, “boring” suddenly looks brilliant.
A monolith with a simple deployment pipeline is easier to revive after NEPA hits than a fragile mesh of services that all need to be healthy at once.
Your users don’t care how modern your stack looks on a conference slide.
They care that your app opens on 3G… and doesn’t crash when their battery is at 9%.

Monoliths: your friend in chaotic environments

Many of us start with monoliths because we don’t know any better.
Years later, we realize they were the sanest choice all along.

A monolith means:
One codebase to reason about when something breaks at 11:47 p.m.
One deploy step, not five services while the generator is groaning.
Simpler logging and debugging — SSH in, check logs, fix, redeploy.
In places where power is unreliable, every extra moving part is just another thing waiting to die at the worst time.
For early-stage products, monoliths give you:
Faster iteration — change a feature, test, ship.
Less infrastructure brain-load — no part-time SRE role just to release a signup flow.
If you’re still chasing product–market fit, the last thing you need is debugging cross-service timeouts while users are begging for a working password reset.

NEPA realities: designing for failure

Power cuts don’t care about your sprint plan.
They introduce invisible requirements most architecture diagrams never mention:
Your dev environment must survive sudden shutdowns without corrupting everything.
Your deployment process must be resumable — you should know how to roll forward or roll back when the lights come back.
Your app must tolerate flaky networks on both server and client.
That shapes your stack:

Databases
Pick something mature and boring, with solid backups and tooling you understand.

Frameworks
Use ones with great docs and big communities. You don’t want to be begging for help on Discord while your inverter is beeping.

Background jobs & queues

Start simple. A single worker or cron-style system beats a complex distributed queue that needs babysitting.
Design as if NEPA will interrupt you at the worst possible moment. You’ll naturally choose stacks that recover cleanly.

Real users don’t live in data centers

It’s easy to design for the laptop in front of you instead of the humans using your product.
In Lagos, you’re often building for:
Low-end Android phones with limited RAM
People buying small data bundles
Users in buses, markets, offices, and homes where the network jumps from “okay” to “are we online?” in seconds

Your stack decisions reach all the way to them:
Heavy SPAs with massive bundles can feel broken on cheap phones. Sometimes server-rendered pages with light JavaScript are kinder.
Over-architected backends add latency users can feel on shaky networks.
Some cloud services are hard to pay for from Nigeria — and rewrites later are painful.

So don’t ask, “What’s the coolest stack?”

Ask:
What keeps response times low on bad networks?
What’s affordable and predictable to host here?
What can my future teammates understand and maintain?

A pragmatic playbook for choosing your stack
If you’re staring at VS Code wondering what to use, try this:

Start with constraints, not hype
List your limits: power, budget, team skill, hosting, payments, user devices.
Ignore them and you’re planning a future rewrite.
Default to a monolith
One repo. One deploy. One database.
Design clean layers so you can split later if needed.
Pick tools you can debug half-asleep
If you can’t explain how to fix it on a midnight call, it’s too complex right now.
Optimize for the worst connection
Test on bad mobile networks.
Avoid huge bundles, chatty services, and unnecessary round trips.
Think about future you (and future devs)
In two years, will you still understand this setup?
Can you ship a fix in one evening after a break?
Add complexity only when pain forces you to
Introduce queues, caches, services, and CDNs when metrics demand it — not because a blog said so.

When to move beyond the monolith

Sometimes the monolith really does start to groan:

Teams grow and deploys collide
One part of the system scales very differently
Releases become risky and slow
When that happens, treat microservices like surgery, not fashion:
Split one well-defined part first
Keep logs, metrics, and alerts simple
Make sure the team understands the cost and responsibility
Every extra service makes your system more brittle — especially in environments where power cuts and network hiccups already exist to humble you.

If you’re building from Lagos, Abuja, Nairobi, Accra — or anywhere that doesn’t look like a glossy Silicon Valley data center — your reality is different.

And your stack should reflect that.

Your superpower isn’t chasing trends.
It’s choosing tech that keeps serving real users when the power blinks, the network stutters, and life gets messy.
Monoliths, NEPA, and real humans aren’t enemies.
They’re the constraints that push you toward a stack that actually works.

AI Didn’t Replace Developers: It Exposed Weak Systems

Fri, 26 Dec 2025 09:15:20 +0000

As the Founder of ReThynk AI, I want to say something that cuts through the noise:

AI didn’t replace developers.
It exposed weak systems.

And that’s why so many teams feel “pressure” right now.

Not because AI is too powerful.
Because their workflows were fragile even before AI arrived.

The Wrong Fear: “AI will take my job”

The real risk isn’t AI.

The real risk is working inside a system where:

requirements are unclear
priorities change daily
documentation is missing
code standards are inconsistent
reviews are weak
ownership is blurry

In that environment, AI becomes a mirror.

It doesn’t just speed up work.
It makes dysfunction visible.

Why AI Exposes Weak Systems So Fast

AI amplifies whatever already exists.

If the system is strong:

AI accelerates clarity
AI helps teams ship faster
AI improves decision-making
AI reduces rework

If the system is weak:

AI accelerates confusion
AI multiplies inconsistent outputs
AI creates more “almost right” work
AI increases rework and frustration

So the question is not:
“Are we using AI?”

The real question is:
“Is our system strong enough to handle acceleration?”

The Most Common Failure I See

A team adopts AI and starts moving faster.

Then suddenly:

bad specs become shipped bugs
unclear decisions become wasted sprints
weak review becomes production incidents
poor naming and structure become unmaintainable code
everyone fights over “best prompts” instead of fixing the process

AI didn’t create these problems.
AI just removed the excuses.

The 4 Weak Systems AI Exposes Instantly
1) Weak problem framing

If the goal is unclear, AI will generate “something” anyway.
That “something” becomes real work, then real waste.

2) Weak standards

If “good code” isn’t defined, AI output becomes a style lottery.

3) Weak validation

If tests and checks are missing, AI output looks correct and fails later.

4) Weak ownership

If nobody owns the outcome, AI output becomes a blame game.

My Fix: Upgrade the System, Not the Prompt

When I see AI causing chaos, I don’t ask for better prompts first.

I strengthen four things:

1) Clarity before code

I force a short written spec:

goal
constraints
success criteria
edge cases

2) Standards that are explicit

I define:

coding conventions
architecture patterns
review expectations
“what we reject” rules

3) Validation that is automatic

AI output must come with:

tests
failure scenarios
rollback plan (when relevant)
basic observability notes

4) Ownership that is human

AI can assist.
But a named person owns the decision.

The Truth That Builders Need to Hear

AI doesn’t replace disciplined developers.

AI replaces:

unclear thinking
messy process
undocumented decisions
“ship now, fix later” culture

So if I want to stay ahead, I don’t compete with AI at typing.

I compete with AI at:

systems thinking
architecture judgment
verification discipline
clarity and ownership

That’s the real professional edge.

The Real Reason Most Developers Are Misusing Generative AI

Mon, 22 Dec 2025 01:59:58 +0000

There’s a quiet frustration I hear repeatedly from developers.

They use generative AI every day.
They save time.
They ship faster.

Yet something still feels off.

The issue isn’t that developers don’t know how to use AI.
It’s that most are using it at the wrong level of abstraction.

That’s the real problem, and it explains almost every misuse we’re seeing today.

The Surface-Level Use Case Trap

Most developers use generative AI as a faster Google.

They ask it to:

write snippets
debug errors
refactor code
explain unfamiliar libraries
generate boilerplate

None of this is wrong.

But it’s shallow.

When AI is treated purely as a helper for isolated tasks, its impact stays limited. Productivity improves, but leverage doesn’t.

That’s not misuse by ignorance. It’s a misuse by framing.

Developers Are Applying AI Where They’re Comfortable, Not Where It’s Powerful

Developers are trained to think in:

functions
files
components
tickets
commits

So naturally, they apply AI at that same granularity.

But generative AI doesn’t shine at the function level. It shines at the system level.

The mismatch looks like this:

AI is capable of reasoning across architecture
Developers restrict it to line-by-line assistance

That gap is where most value is lost.

The Deeper Pattern: AI Is Being Treated as a Tool, Not a System

Here’s the core issue:

Most developers treat generative AI like a smarter editor.

But AI is not just a tool that executes instructions.

It’s a system that can:

reason across context
recognize patterns
evaluate trade-offs
simulate outcomes
maintain long-term intent

When you only ask it to “write code,” you’re underutilising what it’s actually good at.

It’s like hiring a senior architect and asking them to format variables.

Why Prompt Tweaking Isn’t the Solution

When outputs aren’t great, the usual response is:

better prompts
more instructions
stricter formatting
longer context

That helps, but only marginally.

The problem isn’t how the question is asked. The problem is what responsibility the system has been given.

AI works best when it owns:

design decisions
architectural exploration
trade-off analysis
refactoring strategy
system-level reasoning

Prompt tweaks can’t fix a poorly defined role.

Where Generative AI Actually Creates Leverage

In high-performing teams, I see AI used very differently.

Not as:

“write this function”

But as:

“evaluate this architecture”
“identify failure points before we build”
“compare three design approaches under real constraints”
“stress-test this system mentally”
“maintain consistency across a large codebase”

The AI isn’t coding faster. It’s thinking earlier and broader.

That’s where misuse turns into advantage.

The Hidden Cost of Shallow AI Usage

When AI is only used tactically:

technical debt increases
architectural decisions remain unexamined
inconsistency creeps in
teams move faster in the wrong direction

Speed improves. Clarity doesn’t.

And in complex systems, lack of clarity is far more expensive than slow execution.

This Isn’t a Skill Gap. It’s a Mental Model Gap.

Most developers don’t misuse AI because they lack knowledge.

They misuse it because they haven’t updated their mental model.

They still think:

AI as autocomplete
AI as assistant
AI as shortcut

The better mental model is:

AI as a reasoning layer in your system design process.

Once that clicks, usage changes naturally.

What This Means Going Forward

As AI becomes embedded deeper into development workflows, the gap will widen.

Some developers will:

write code faster
ship more
stay busy

Others will:

design better systems
reduce rework
make fewer irreversible mistakes
scale decision quality

The difference won’t be talent. It will be how AI is positioned in the development process.

The Real Takeaway

Most developers aren’t misusing generative AI because they’re careless.

They’re misusing it because they’re aiming too low.

AI’s biggest value isn’t in helping you write code faster.

It’s in helping you decide what code should exist in the first place.

Once you move AI upstream, from execution to reasoning, everything changes.

And that’s when generative AI stops being a productivity boost and starts becoming a real engineering advantage.

Next Article:

“From Assistants to Operators: The AI Role No One’s Preparing For.”

Format JSON Online

Mon, 14 Jul 2025 11:59:43 +0000

Format JSON Online is a fast, free, and privacy-focused tool to format, validate, minify, and beautify JSON data directly in your browser. Built for developers and API testers, it offers support for large JSON files without requiring login or sending data to a server. Additional features like JSON-to-CSV, JSON-to-XML, and cURL conversion make it a versatile tool for debugging, transforming, and visualizing JSON. Light ads may be introduced in the future to support development, but user privacy and experience will always be top priorities.

Beyond Code: The Real Life of a Software Engineer

Mon, 07 Jul 2025 17:32:53 +0000

When people hear "software engineer," the first image that pops into their mind is someone furiously typing code, probably in a dark room with six monitors and a cup of cold coffee.

But is that all there is to it?

Not even close.

In this post, let’s explore what it really means to be a software engineer — beyond the code.

⚙️ 1. Communication is Your Superpower
Being a great software engineer isn’t just about knowing 12 different JavaScript frameworks. It's about understanding problems and communicating solutions.

Can you explain a complex bug to your product manager in simple terms?
Can you write clear, helpful documentation?
Can you give constructive feedback in code reviews?
If you're not improving your communication skills, you're limiting your growth.

️ 2. Debugging Life, Not Just Code
You’ll often face challenges that have nothing to do with code:

Ambiguous requirements
Legacy systems with no documentation
Interpersonal team conflicts
Sometimes, you spend more time on Slack than in VS Code. And that’s okay. That’s part of the job.

Learning Never Stops
You don't just learn programming languages — you learn people, processes, and priorities.

The most successful engineers I've met are not the ones who knew everything — but the ones who kept learning every day.

Self-Care Is a Career Skill
Burnout is real. Sleep deprivation doesn’t make you a hero.

Take breaks.
Set boundaries.
Eat lunch away from your screen.
Because your brain is your best asset — and it needs rest to work its magic.

️ Here's a Little SVG to Sum It All Up

(If dev.to doesn't render SVG directly, you can host it as an image or link it from a GitHub gist.)

Final Thoughts
Software engineering is a journey — and the code is just one part of it.

The next time someone asks you what you do, don’t just say "I write code."
Say:
"I solve problems."
"I collaborate with teams."
"I build the future."

Because that’s what you really do.

Why C++ Compilers Prefer Performance Over Safety Checks?

Fri, 20 Jun 2025 09:24:12 +0000

C++ is a language synonymous with performance, control, and portability. For decades, it has powered the world's most demanding software systems, from operating systems to game engines and real-time trading platforms. At the heart of its power lies a controversial feature: undefined behavior (UB). This feature, or rather lack of behavior definition, has led to immense performance gains but also to programming pitfalls. When modern C++ compilers like GCC and Clang prioritize performance, they do so by aggressively assuming that undefined behavior never occurs. In this article, we will explore why these compilers make such design choices, the benefits and trade-offs involved, and how developers can harness these tools responsibly.

1. The C++ Design Philosophy: Trust the Programmer

One of the key tenets of C++ is that it "trusts the programmer." This trust is not blind; it is intentional and foundational. Unlike languages like Java or Python that emphasize safety and abstraction, C++ offers low-level memory and hardware access. It does so while striving for zero-overhead abstractions. The premise is that a knowledgeable programmer can write highly efficient code if the compiler doesn't impose runtime safety checks that might slow execution.

Control and Efficiency

C++ gives developers precise control over resource management. You decide how memory is allocated, how objects are constructed, and when resources are released. This fine-grained control enables performance tuning at a level unmatched by most high-level languages.

No Built-in Safety Net

By default, C++ does not include bounds checking, null pointer validation, or automatic garbage collection. This lack of safety net is a double-edged sword. On one side lies blazing speed and fine control. On the other, the danger of undefined behavior.

2. What is Undefined Behavior?

In the context of C++, undefined behavior refers to code that does not have a well-defined effect according to the C++ standard. When such code is executed, anything can happen. It may crash the program, produce unexpected results, or appear to work fine (only to break later).

Common Sources of UB

Dereferencing null or dangling pointers
Accessing array elements out of bounds
Using uninitialized variables
Violating strict aliasing rules
Shifting integers by more than their width
Modifying a variable more than once between sequence points
Invoking functions through function pointers with the wrong signature

These are not bugs that merely produce wrong results; they allow the compiler to assume they never happen.

3. Why Compilers Exploit Undefined Behavior

Both GCC and Clang are highly optimizing compilers. They use undefined behavior as a license to transform code under the assumption that such errors never occur. This leads to several advantages:

a. Dead Code Elimination

Consider the following:

if (ptr != nullptr) {
   *ptr = 10;
}

If the compiler determines that ptr is never null (or that dereferencing null is UB), it might remove the check entirely, resulting in more streamlined code.

b. Loop Optimizations

UB assumptions allow the compiler to:

Unroll loops
Perform strength reduction
Vectorize operations for SIMD instructions
Parallelize independent iterations

c. Constant Folding and Propagation

If a branch or operation leads to UB under certain conditions, compilers may discard it entirely or simplify control flow under the assumption that such branches are never taken.

d. Register Allocation Improvements

Assuming UB allows for more flexible reuse of registers, reducing memory access and increasing pipeline throughput.

4. Benefits of This Approach

4.1 Performance

By ignoring checks and relying on the programmer's correctness, the compiler produces leaner, faster machine code. In performance-critical domains (e.g., embedded systems, high-frequency trading), even a 1-2% gain can be significant.

4.2 Simpler Compiler Internals

When the compiler is allowed to assume certain operations never happen (like null pointer access), it simplifies the internal logic for code generation and optimization passes.

4.3 Portability

This model ensures the same code can run efficiently across different platforms without runtime dependencies like garbage collectors or VM-based safety checks.

4.4 Greater Flexibility for Developers

Developers who understand their system well can fine-tune performance and optimize memory usage, trading safety for precision when necessary.

5. The Cost: Dangerous Flexibility

5.1 Debugging Nightmares

Because UB can manifest unpredictably, bugs are often hard to detect. Code that works on one compiler version may break on another. Debuggers might show misleading or inconsistent information when UB is triggered.

5.2 Security Vulnerabilities

Many buffer overflows and privilege escalation exploits originate from UB that goes unchecked during development. Attackers exploit these flaws to insert malicious code, steal data, or crash systems.

5.3 Non-deterministic Behavior

A program might behave differently on each run or platform due to optimizations exploiting UB. This leads to issues in testing, especially in distributed or multithreaded applications.

5.4 Loss of Portability

Code relying unknowingly on UB may work on one architecture but fail on another. For example, pointer alignment or endianness assumptions may cause subtle and hard-to-detect issues.

6. Mitigation Strategies for Developers

6.1 Use Static Analysis Tools

Tools like Clang-Tidy, Cppcheck, and Coverity help detect UB patterns in source code before runtime. They analyze control flow, memory access patterns, and data usage.

6.2 Enable Compiler Sanitizers

Compiler sanitizers are invaluable for catching UB during testing:

-fsanitize=undefined: Catches most UB issues like invalid casts or pointer arithmetic
-fsanitize=address: Detects heap buffer overflows, use-after-free
-fsanitize=thread: Catches race conditions in multithreaded programs
-fsanitize=leak: Helps track memory leaks

6.3 Adopt Safe Subsets

Frameworks like MISRA-C++ or AUTOSAR C++ define subsets of the language that eliminate or constrain UB-prone features. These are essential in safety-critical industries like automotive and aerospace.

6.4 Use Modern C++ Features

Prefer smart pointers (std::unique_ptr, std::shared_ptr), std::optional, std::variant, std::array over raw pointers and C-style arrays. These features enforce safer access and clearer intent.

6.5 Enforce Code Reviews and Testing

Robust peer reviews and extensive unit/integration testing help catch unintended UB before code reaches production.

6.6 Leverage Formal Verification (Advanced)

For critical systems, formal methods can be used to prove the absence of UB under all conditions using mathematical techniques.

7. Why Not Just Eliminate UB?

Eliminating undefined behavior would fundamentally change what C++ is:

More runtime checks would degrade performance.
It would become more like Java or Rust.
Backward compatibility with decades of C/C++ code would break.

UB is a deliberate, though controversial, part of the design. It is the price for raw power and flexibility.

Languages like Rust take a different path: they eliminate most classes of UB at compile time through strict ownership and borrowing rules. But this comes at the cost of a steeper learning curve and more restrictive coding patterns.

C++ allows expert programmers to write fast code with minimal abstraction costs, but the responsibility lies with the programmer to avoid UB through discipline and tooling.

8. Real-World Use Cases Embracing UB for Speed

8.1 Operating Systems

Linux kernel code is filled with performance-critical sections that rely on UB being carefully avoided but never checked. Kernel developers rely on strict coding guidelines and peer review to manage UB risk.

8.2 Game Engines

Engines like Unreal Engine are written in C++ with heavy use of UB-ignoring constructs for maximum speed. Real-time rendering and physics engines must meet frame deadlines every few milliseconds.

8.3 Trading Systems

Low-latency trading platforms depend on compiler-optimized binaries where every nanosecond counts. Programmers in this domain carefully avoid UB through disciplined coding and extensive testing.

8.4 Embedded Systems

In microcontrollers and IoT firmware, memory and processing power are limited. Developers must write tight, efficient code and often disable runtime checks, accepting the trade-offs of UB.

8.5 Scientific Simulations

High-performance computing (HPC) relies on C++ to run simulations on massive datasets. UB assumptions allow compilers to fully exploit hardware capabilities.

9. Compiler Flags That Matter

GCC and Clang both offer many flags to control optimization and UB behavior:

-O2, -O3: Enable aggressive optimizations
-fstrict-aliasing: Assumes pointers don’t alias unless explicitly cast
-fno-strict-overflow: Prevents assuming signed integer overflow is UB
-fsanitize=: Enables various runtime checks
-Wall -Wextra: Turns on helpful warnings
-pedantic: Enforces strict standard compliance

Recommended Combinations

For development:

g++ -O0 -g -fsanitize=undefined,address -Wall -Wextra

For production:

g++ -O3 -fstrict-aliasing -fomit-frame-pointer

10. Conclusion: Master the Power, Respect the Danger

C++ gives you a powerful toolset, but with it comes responsibility. GCC and Clang prioritize performance because that’s what the language promises: speed without overhead. Undefined behavior is not a mistake in the spec; it's a contract with the programmer. The compiler trusts you not to invoke UB, and in return, it gives you unmatched performance.

To use C++ effectively:

Understand the risks of undefined behavior
Use the right tools to catch it early
Write clean, testable, standards-compliant code

In the world of systems programming, performance often trumps safety—but with the right knowledge and practices, you don’t have to choose between them.

Final Thoughts

While undefined behavior may seem like a flaw, it is in fact a feature that empowers developers to write some of the fastest code in the world. If used with care, and backed by tooling and discipline, it allows C++ to remain at the forefront of high-performance software engineering.

AquaScript | Free JSON APIs

Fri, 23 May 2025 19:06:05 +0000

Introducing AquaScript: Your Ultimate Free JSON API Hub for Developers(AquaScript)

Why AquaScript?

At AquaScript, we understand the challenges developers face when sourcing reliable mock data for testing, prototyping, or educational purposes. That's why we've created a platform that offers

Completely Free Access: No sign-ups, no API keys, just instant access.
⚡ Blazing Fast Responses: Optimized for speed to keep your development process smooth.
Diverse Data Categories: From books and movies to jokes and recipes, we've got a wide range of data sets.
Regular Updates: Our APIs are constantly updated to ensure data relevance and accuracy.

Explore Our API Categories

We offer a variety of APIs to cater to your development needs:

Books & Books+: Access detailed information on book titles, authors, genres, and more.
Movies & Movies+: Retrieve comprehensive movie data, including ratings, cast, and streaming availability.
Quotes & Quotes+: Fetch a vast collection of inspirational, funny, and motivational quotes.
Jokes & Programming Jokes: Get clean jokes suitable for all audiences, including tech-specific humor.
Users: Generate mock user data for testing and development.
️ Recipes: Discover a variety of recipes with ingredients, instructions, and nutritional information.
Songs: Access song metadata, lyrics, and artist information.

Each API is designed with a consistent JSON structure, making integration into your projects seamless.

Meet the Team Behind AquaScript

AquaScript is a collaborative effort by passionate developers:

Hanzla Baig (he/him): Lead Developer, bringing innovative solutions to life.
Precious Kelvin (he/him): Backend Specialist, ensuring robust and scalable APIs.
Madhurima Rawat (she/her): Frontend Expert, crafting intuitive user experiences.

Together, we strive to empower the developer community with tools that simplify and accelerate the development process.

Join Our Growing Developer Community

Thousands of developers worldwide are already leveraging AquaScript for their projects. Whether you're building a new app, testing features, or teaching coding, our APIs are here to support you.

Spread the Word

Help us reach more developers by sharing AquaScript with your network. Together, we can build a more efficient and collaborative development ecosystem.

Experience the simplicity and power of AquaScript today. Visit AquaScript.xyz and elevate your development workflow!

Top Coding Languages to Learn in 2025: Stay Ahead in Tech

Thu, 15 May 2025 07:33:35 +0000

Top Coding Languages to Master in 2025

With countless programming languages available, choosing the right one to focus on can set the foundation for success in the tech-driven landscape of 2025. Here’s why JavaScript continues to top the list and deserves your attention:

JavaScript

Global Popularity: According to the Stack Overflow Developer Survey 2023, JavaScript remains the most widely used programming language, with 67.7% of developers utilizing it.
Versatility: JavaScript powers both front-end and back-end development, making it an essential tool for creating web and mobile applications, handling server tasks, and enabling dynamic, highly responsive user interfaces.
Frameworks and Libraries: Master frameworks like React.js for building interactive UIs and Node.js for scalable backend solutions. These tools form the backbone of platforms like Facebook and LinkedIn.
Cross-Platform Capability: JavaScript’s adaptability allows developers to operate seamlessly on both the client and server sides, enhancing productivity and flexibility.

No matter your focus area — web development, mobile apps, or full-stack projects — JavaScript is an invaluable skill to master as it continues to dominate the tech landscape in 2025.

Python

Python is highly popular for both web development and data analysis. For instance, frameworks like Django and Flask are commonly used for building robust web applications. Additionally, libraries such as Pandas and NumPy facilitate efficient data manipulation and analysis, while Matplotlib and Seaborn are essential for data visualization. Python is extensively used by companies like Google and Netflix for backend development and machine learning applications. In addition, Python is:

Beginner-friendly, thanks to its easy design and use of English in the features, making it easy for tech newbies to follow and grasp.
Versatile, helping you use it for a wide range of projects, regardless of its size, scope, or industry.
Helpful, with an incredibly large online support community that can help you if you run into any challenges while you’re learning or developing.

Java

Not to be confused with JavaScript, Java is found on basically every single operating system and app and used by big name companies like Amazon and Google. A frequent requirement of job postings, adding Java to your repertoire is good for your professional growth:

Java can be used across different systems and isn’t linked to just one, meaning it’s a useful programming language that will serve you throughout your career, no matter where you are.
It’s open source, meaning the source code is free and widely available, helping developers skip the basics and move on to the more interesting parts of programming.
Java is used in practically every development application, is compatible with every operating system, and is great for app building.

This high-level language is especially useful for beginners, as it takes care of the basic code that you’d be responsible for writing in other languages. In addition, C#:

Is quite popular among companies and even in projects where it’s not used, it’s still popular for web service creation.
Is both open source and available on Microsoft, OSX, and Linux, meaning it’s quite universal.
It’s easy to learn because it automates some of the toughest elements of programming, letting you focus on the coding itself.

Ruby
If you’re looking to start out at a small company or are just beginning your journey into web development, Ruby is a fantastic option. It’s a popular choice for new techies because:

Ruby uses a familiar syntax that’s similar to English, ensuring that even those without extensive programming backgrounds are able to learn it.
Ruby boasts an incredible online community, is free, and is open-source, allowing users to consult with others for assistance and find solutions.
Ruby is general purpose, meaning it’s versatile and good to have under your toolbelt for future opportunities.

How to Learn a New Programming Language

The idea of learning an entirely new programming language, especially if you’re comfortable with the ones you currently know, can be quite daunting. We get it — it’s never easy to jump feet first into something entirely unknown. That’s why we’ve put together this list to help you on your programming language journey:

Carefully choose your next language to learn: there are a lot of languages out there and knowing the best fit for you can be quite the challenge. Before you randomly choose one and get started, ask yourself these questions:

What language are job postings you’re interested in requesting?
Is the language you’re interested in compatible with the operating systems you know how to use?
Are you truly interested in the coding language?
What’s the learning curve of the programming language?

Set up a learning plan: you might want to dive right in, but it’s crucial to set up a learning plan so that you’re fully prepared. If you’re planning to learn on your own, make sure you find resources to help you in case you get stuck or choose a programming language that’s open source or has widespread usage so you can solicit help online.
Start practicing: practice makes perfect and that’s especially true in the world of coding. Take the time to learn the theoretical foundations of the programming language, but start practicing as soon as possible so that you become familiar with how the language works and any differences from your other ones.

There are lots of websites with coding challenges for beginners that can guide you through the beginning as you gain confidence.

JSON vs BSON: Why MongoDB Uses a Binary Format for Better Performance

Mon, 05 May 2025 18:39:02 +0000

Let’s talk about JSON. A lot of you are probably familiar with it — whether you’ve dealt with API responses, configuration files, or log messages, JSON has likely come up more than once.

JSON, or JavaScript Object Notation, is a human-readable format that stores data in the form of key-value pairs. You might think it’s the same as a JavaScript object — and it’s very similar — but not quite. In JSON, the data must be wrapped in curly braces, the keys must always be strings (in double quotes), and each key maps to a value. That value can be a string, number, array, boolean, null, or even another JSON object. However, JSON supports only a limited set of data types compared to what you might be used to in JavaScript

    {
  "name": "Alice",
  "age": 25,
  "email": "*Emails are not allowed*",
  "isStudent": false,
  "skills": ["JavaScript", "React", "Node.js"],
  "address": {
    "street": "123 Main St",
    "city": "Delhi",
    "zip": "110001"
  }
}

By virtue of being both human- and machine-readable, and relatively easy to implement in most programming languages, JSON has become a widely adopted standard for data exchange. But since we're talking in the context of MongoDB, let’s see how MongoDB actually works with JSON.

One of the key goals was to let developers work with data in a way that feels natural and flexible. Since JSON is a widely used format and easy to read, MongoDB decided to use a JSON-like structure for storing and working with data.

To address these limitations, MongoDB introduced BSON

What is BSON?

BSON (Binary JSON) stands for Binary JavaScript Object Notation. It’s a binary-encoded format that is inspired by JSON, but specially designed for storing and retrieving data in MongoDB.

While JSON is great for exchanging data between systems (like sending API responses), BSON is optimized for efficient storage and fast access, especially when working with large or complex datasets.

Why Use BSON Over JSON?

While JSON is the preferred choice for data interchange due to its simplicity and readability, BSON offers several advantages when it comes to data storage and retrieval.

BSON can store additional data types that are not supported by JSON, such as:

JSON doesn’t have a real "date" type.It only stores dates as text (strings).Example: "2025-05-05T10:00:00Z"→ You have to manually convert this into a date when using it in your code.
BSON (used in MongoDB) does support real dates.It stores dates as numbers → This makes it faster and easier for the computer to understand and work with dates.
JSON can't store binary data (like images or files) directly. You have to convert it to a long text format like Base64, which takes more space and is slower to process.
BSON has a special BinData type just for binary data. It can store things like images, files, or other raw data more efficiently and quickly.
It uses a special type called ObjectId to uniquely identify each document (like an ID).
This ObjectId is only available in BSON, not in plain JSON.

Faster Data Retrieval

BSON helps in faster data retrieval because it is stored in a binary format, which is easier for computers to read and process compared to plain text like JSON. When a database like MongoDB needs to search through data or return results, it can do it more quickly using BSON.This is especially helpful when the data is large or contains complex structures like nested objects. Since BSON is structured in a way that makes it easy to find and access specific pieces of data, it also improves indexing

Space Efficiency for Large Datasets

BSON is more space-efficient than JSON, especially when dealing with large or complex datasets. This is because BSON stores data in a compact binary format, which takes up less space compared to JSON's plain text format. For example, numbers, dates, and other data types are stored in a smaller, more optimized way in BSON. This helps save storage and reduces the amount of data that needs to be transferred between the database and the application.

Does MongoDB Use BSON or JSON?

MongoDB uses BSON, not JSON, to store data internally and when sending it over the network.

However, as a developer, you usually work with JSON-like structures — because it’s easy to read, write, and understand. MongoDB takes care of converting that JSON into BSON behind the scenes.

Here's how the process works:

Your code creates data using native types (like objects or dictionaries).
That data gets converted into JSON (a common format) by your programming language or framework.
The MongoDB driver (a tool that connects your code to MongoDB) automatically converts the JSON into BSON — a special binary format used by MongoDB.
MongoDB stores and processes the data in BSON because it’s faster and more efficient.
When you request (query) the data, MongoDB sends it back as BSON.
The driver converts it back to JSON, and your app receives it in a format it can easily work with.

Differences Between JSON and BSON

Here’s a detailed comparison to help us understand the critical differences between JSON and BSON:

In conclusion, both JSON and BSON serve important roles in data handling but are designed for different purposes. JSON is ideal for lightweight data exchange due to its simplicity and human-readability, making it the standard choice for APIs, web services, and client-server communication. On the other hand, BSON is optimized for efficient data storage and retrieval, particularly in MongoDB, as it supports additional data types like Date, Binary, and ObjectId, and offers faster parsing and better space efficiency.

The Proxy Pattern: A Software Developer’s Essential Tool

Fri, 25 Apr 2025 15:31:01 +0000

The Proxy Pattern is a structural design pattern that provides a surrogate or placeholder for another object to control access to it. It's like having a representative that acts on behalf of another object.

The Proxy Pattern allows you to:

• Provide a substitute or placeholder for another object

• Control access to the original object

• Perform operations before or after requests reach the original object

When to Use the Proxy Pattern

Lazy initialization is needed: When creating objects is expensive and you want to delay creation until absolutely necessary
Access control is required: When you need to restrict access to certain operations or resources based on permissions
Resource management is important: When working with limited resources that need controlled allocation
Added functionality is needed before/after access: When you want to perform operations before or after accessing the real object (like logging or caching)

The key indicator is when you need to control access to an object without changing its interface.

Structure of the Proxy Pattern
The pattern consists of these key components:
• Subject: An interface that defines the common operations for both the RealSubject and Proxy

• RealSubject: The actual object that the proxy represents

• Proxy: Maintains a reference to the RealSubject and controls access to it

• Client: Interacts with the Subject interface

Types of Proxies

1. Virtual Proxy
• Creates expensive objects on demand (lazy initialization)
• Example: Loading large images in a document only when they need to be displayed

2. Protection Proxy
• Controls access permissions to objects
• Example: Access control systems that verify user permissions before allowing resource access

3. Remote Proxy
• Represents objects in different address spaces
• Example: A local object representing a remote service

4. Smart Reference
• Performs additional actions when objects are accessed
• Example: Reference counting, locking mechanisms

Example: Virtual Proxy for Image Loading in C#

Problem: Loading high-resolution images is expensive and may not be immediately necessary.

Solution: Use a Virtual Proxy to load the actual image only when it needs to be displayed.

// Subject Interface
public interface IImage
{
    void Display();
}

// RealSubject
public class HighResolutionImage : IImage
{
    private string _filename;
    
    public HighResolutionImage(string filename)
    {
        _filename = filename;
        LoadImageFromDisk();
    }
    
    private void LoadImageFromDisk()
    {
        Console.WriteLine($"Loading high-resolution image: {_filename}");
        // Expensive operation: loading image data
        // In a real implementation, this might use System.Drawing or ImageSharp
        // to load and process the actual image file
    }
    
    public void Display()
    {
        Console.WriteLine($"Displaying high-resolution image: {_filename}");
    }
}

// Proxy
public class ImageProxy : IImage
{
    private string _filename;
    private HighResolutionImage _realImage;
    
    public ImageProxy(string filename)
    {
        _filename = filename;
    }
    
    public void Display()
    {
        // Create the real image only when Display is called
        if (_realImage == null)
        {
            _realImage = new HighResolutionImage(_filename);
        }
        _realImage.Display();
    }
}

// Client
public class Program
{
    public static void Main(string[] args)
    {
        // Using proxies for multiple images
        IImage image1 = new ImageProxy("photo1.jpg");
        IImage image2 = new ImageProxy("photo2.jpg");
        
        // The high-resolution image is loaded only when displayed
        Console.WriteLine("Application started...");
        Console.WriteLine("Displaying first image:");
        image1.Display();  // Only now is the first image loaded
        
        Console.WriteLine("Second image is not displayed, so it's never loaded");
        
        Console.ReadKey(); // Wait for user input before closing
    }
}

Benefits of the Proxy Pattern

Improved performance: Defers costly object creation until necessary
Enhanced security: Controls access to sensitive objects
Reduced complexity: Hides implementation details from clients
Increased flexibility: Enables features like caching, logging, and access control without changing the original object
Location transparency: Provides unified access to distributed objects

Limitations of the Proxy Pattern

Increased response time: Adds a level of indirection
Implementation complexity: Some proxy types can be complex to implement
Potential for overuse: Not every object needs a proxy

Real-World Applications

Web browsers: Caching proxy for web pages
ORM frameworks: Proxies for lazy loading of database entities
Credit cards: Act as proxies for bank accounts

Summary
The Proxy Pattern provides a surrogate for another object to control access to it. It's particularly useful for lazy loading, access control, and adding behavior when accessing objects. The pattern maintains the same interface as the original object while providing additional functionality.

Reference : Book : ”Design Patterns: Elements of Reusable Object-Oriented Software” by Gamma, Helm, Johnson, and Vlissides. also call Gun of Fure

Reality of the tech market as a software developer at any level of seniority

Wed, 09 Apr 2025 22:34:03 +0000

The Harsh Reality of the Tech Job Market: Why Is It So Hard to Get a Job in Tech Today?

In recent years, the technology sector has shifted from being a booming industry with high demand and abundant opportunities to a highly competitive field where each job posting receives hundreds, if not thousands, of applications. What was once a "candidate-driven market," where companies competed to attract talent, has now become a fierce battleground where programmers must work hard to stand out.

Factors Increasing Competition in the Tech Industry

1. The Rapid Growth of Developers

Platforms like Platzi, Udemy, and Codecademy have made it easier for people to learn programming. Additionally, government and private initiatives promoting tech education have led to an exponential increase in junior developers entering the job market.

2. Massive Layoffs in the Industry

Major tech companies like Google, Meta, and Amazon have significantly reduced their workforce over the past two years. These layoffs have not only affected experienced developers seeking new positions but have also intensified competition for junior roles.

3. Automation and Emerging Technologies

Tools like GitHub Copilot and ChatGPT have streamlined coding processes, reducing the need for manual work and, in some cases, decreasing the demand for developers handling repetitive tasks.

4. Globalization and Remote Work

The rise of remote work has expanded the talent pool, allowing companies to hire professionals from lower-cost regions. As a result, developers in higher-cost areas now face even greater competition.

How to Stand Out in a Competitive Job Market

Although the current landscape is challenging, there are strategies that can improve your chances of landing a tech job:

1. Specialization

General programming skills are no longer enough. Focusing on specific areas like cybersecurity, cloud computing, artificial intelligence, or microservices architecture can give you a competitive edge.

2. Gaining Practical Experience

Contributing to open-source projects, developing personal projects, and engaging with tech communities can significantly enhance your resume.

3. Developing Soft Skills and Networking

Technical skills alone won’t secure a job. Communication, problem-solving, and teamwork are increasingly valued. Building a strong professional network on platforms like LinkedIn can also open doors.

4. Preparing for Technical Interviews

Practicing algorithms and data structures on platforms like LeetCode or HackerRank is still essential for passing rigorous hiring processes.

Conclusion

The tech industry continues to evolve, and while competition is fierce, opportunities still exist for those who differentiate themselves. Adapting, continuous learning, and building a personal brand are key strategies to succeed in today’s job market.

Have you experienced the impact of increased competition in the tech sector? Share your thoughts in the comments!

LinkedIn vs. dev.to: What's better for Developers ?

Tue, 07 Jan 2025 07:10:10 +0000

When developers talk about networking, LinkedIn is often the first platform that comes to mind. It's like a professional hub where people showcase their resumes, accomplishments, and job opportunities. While LinkedIn is great for finding jobs, it might not be the best place for developers looking to make meaningful connections and collaborate.

A Race for Attention: LinkedIn's Competitive Culture

LinkedIn often feels like a constant competition. While it's a useful platform for professionals to display their achievements, it doesn't necessarily create the right environment for developers who want to collaborate, share knowledge, and find mentorship. The platform's focus on resumes, career milestones, and job titles leads to shallow interactions—likes, comments, and congratulatory messages—that don't foster deeper, technical discussions or problem-solving.

One of LinkedIn's shortcomings is its lack of developer-specific tools or features that encourage collaboration on projects. Most interactions are limited to sharing articles or posting about career updates. For developers, this isn’t conducive to learning or working together on code. The overwhelming presence of recruiters also dominates the platform, turning it into more of a job marketplace rather than a community for developers to grow and collaborate.

LinkedIn: Great for Job Searching, Poor for Building Relationships

While LinkedIn shines as a job-seeking tool, especially for connecting with recruiters or showcasing professional achievements, it doesn't cater well to the needs of developers looking to collaborate. The platform is heavily career-oriented, meaning that even technical posts are often framed to appeal to recruiters rather than foster genuine conversations or peer-to-peer knowledge sharing. This makes it hard for developers to form lasting connections with others based on shared technical interests.

For example, a developer might post about a personal project or new technology they’re learning, but the engagement often doesn't go beyond surface-level comments like "Congrats!" or "Well done!" There’s little room for deeper discussions where others pitch in with technical feedback, share insights, or collaborate to solve a problem together.

Dev.to: A Community-First Platform for Developers

If LinkedIn is where developers go to compete, dev.to is where developers go to collaborate. As a community created specifically for developers, dev.to focuses on sharing knowledge, encouraging technical discussions, and fostering real connections. Whether you’re a seasoned developer or just starting, the platform offers a space to ask questions, share insights, and contribute to open-source projects.

How dev.to facilitate collaboration:

Open-source Contributions: Dev.to encourages developers to contribute to open-source projects. Many users share their work, invite others to contribute, and offer support for ongoing projects. This culture of collaboration allows developers to grow and learn together by actively participating in building real-world applications.

In-depth Articles and Tutorials: One of the platform’s strongest features is its collection of technical articles and tutorials written by developers for developers. These posts go beyond superficial updates—they dive deep into coding challenges, best practices, and new technologies. Developers can engage with these posts by asking questions, offering solutions, or discussing alternative approaches. For example, a developer might write an article on solving specific coding problems in JavaScript, and others can comment with their experiences or alternative solutions, leading to meaningful discussions.

Genuine Conversations: On dev.to, the conversations are more substantial. Rather than simply liking a post about landing a new job, you’ll find discussions about code, tools, and technologies developers are using. This creates a more engaging and collaborative environment where developers are encouraged to help each other out and share their experiences in a meaningful way.

Code-sharing and Collaboration: Dev.to provide space for developers to share code snippets, GitHub repositories, and projects they’re working on. Whether it's debugging an issue, optimizing a solution, or reviewing code, dev.to offers a collaborative atmosphere that goes beyond the “likes” and congratulatory comments seen on LinkedIn.

No Recruiter Spam: Unlike LinkedIn, dev.to is a space free from recruiter-driven interactions. The focus remains entirely on coding, learning, and contributing to the community, which is refreshing for developers who want to meet others based on shared technical interests rather than career milestones.

Conclusion

LinkedIn might be useful for developers when it comes to job hunting and expanding their professional network. But if your goal is to connect, learn, and collaborate with a community of like-minded developers, platforms like dev.to are far better suited for that purpose. Ultimately, coding is more about teamwork and learning together than competing for the spotlight.

All about system design

Tue, 07 Jan 2025 06:35:08 +0000

System Design: The Quest to Architect the Universe (Or Just Your App)

Once upon a time in the magical land of Software Engineering, a brave developer stood on the precipice of greatness (or utter confusion). Armed with a keyboard and a half-empty cup of coffee, they were about to embark on the most daunting journey of all: System Design.

Ah yes, system design—the thing interviewers ask about with a gleam in their eye, knowing full well that you’re about to talk in circles for 45 minutes while drawing boxes and arrows on a whiteboard like a mad scientist sketching a blueprint for world domination.

Let’s dive into this adventure, and who knows, by the end of it, you might even survive.

The Client-Server Drama

First off, let’s introduce you to our two main characters: Client and Server. Think of them like a pair of socially awkward friends at a party. The Client is that one person who never stops asking questions, like “Hey, can you get me that photo?” or “What’s the status of my food delivery?” Meanwhile, the Server is the poor soul who’s constantly trying to answer while juggling a hundred requests from other Clients at the same time.

And just like in real life, sometimes the Server will ghost the Client. It’s not personal—it just ran out of memory or crashed trying to fulfill the thousandth request for cat memes.

Load Balancers: The Bouncers of Your App

Enter the Load Balancer. This guy is the bouncer at the club who decides who gets in and who’s going to be left outside refreshing the page for eternity. Without load balancers, your system would be like a house party with 500 guests and one pizza—it’d go downhill fast.

The Load Balancer makes sure that no single server has a nervous breakdown by sending requests to different servers. It’s like your app’s way of saying, “I don’t know what server can handle you, but I hope one of them can.”

Microservices: "It’s Not You, It’s Me"

Monolithic apps? Oh, please. That’s so 2005. These days, we break things down into Microservices, the tech equivalent of breaking up with someone but staying friends. Instead of having one gigantic app doing everything (and eventually failing spectacularly), you have tiny apps that each handle specific tasks.

It’s like having a team of specialists instead of one person who’s trying to do everything—because we all know how that ends (hint: burnout, tears, and unhandled exceptions).

Databases: The Memory Bank

Now, let’s talk about the Database, your system’s treasure trove. It’s the place where you stash all the important stuff—like user data, app configurations, and your deepest secrets. There are two main kinds of databases: SQL (Structured Query Language) and NoSQL (Not Only SQL).

SQL databases are like librarians—organized, strict, and always wanting things in a specific order. NoSQL databases, on the other hand, are more like those cool, laid-back teachers who don’t mind if you turn in assignments whenever. You’ll need to decide which type fits your app’s personality. Are you a rule-following librarian or a chill teacher who’s okay with chaos?

Caching: The Cheat Sheet

If your Database is the library, then Caching is your cheat sheet. Why spend time flipping through pages when you can keep the answers right under your desk? When users keep asking for the same thing (like the score of last night’s game), caching stores that information close at hand, so you don’t have to dig it out of the database every time.

Just be careful—if your cheat sheet is wrong (i.e., stale cache), it’s like showing up to an exam with the wrong answers. Oops.

Scalability: Because More People Are Coming to the Party

Ah, Scalability—the thing everyone loves to brag about. It’s like when your friend says, “Yeah, we had to rent out a bigger venue for the party because so many people RSVP’d.” Scaling your system means handling more users, more requests, and more data without collapsing like a house of cards.

Vertical scaling is like giving your servers an upgrade—a new wardrobe and a gym membership so they can handle the load. Horizontal scaling? That’s when you just hire more servers. Instead of making one server bulk up, you bring in a whole team of new ones.

High Availability: No Downtime Allowed

What’s worse than a system failure? Nothing, according to your users. That’s why we aim for High Availability—because users expect your app to be there for them 24/7, like a loyal pet.

Of course, achieving high availability is no small feat. It’s like trying to stay awake during a 24-hour movie marathon. Servers need naps too, which is why you bring in backups and redundancy. That way, when one server crashes, another swoops in like a superhero, and no one ever notices.

Conclusion: You Survived (Maybe)

Congratulations! You’ve survived the wild world of system design, though it may have left you a little dazed and confused. Just remember, it’s all about drawing boxes, naming things in fancy ways (hello, “load balancer”), and praying that your app doesn’t implode under pressure.

Now go forth, brave developer, and architect systems with the grace of a cat landing on its feet—or at least with enough boxes and arrows to confuse anyone looking at your diagram.

I have a full design course here: system design course
please check it out and gain in-depth knowledge of it.

Happy designing!