Forem: Yashodhan Singh

Resilience > Perfection

Yashodhan Singh — Fri, 22 Aug 2025 05:14:07 +0000

Software engineering is mostly about decisions under uncertainty.

Every framework you choose, every abstraction you build, every quick fix you push to production is a decision under uncertainty.

The hard part isn’t writing code. It’s deciding when you don’t have perfect information.

A useful mental model for this comes from Donald Rumsfeld. He split knowledge into four categories:

Known Knowns: things we know
Known Unknowns: things we know we don’t know
Unknown Knowns: things we know but have forgotten or buried
Unknown Unknowns: things we don’t even realize we don’t know

Here’s how those quadrants show up in engineering work.

1. Known Knowns

“Use the linter.”

Examples

Choosing between a for loop and .map
Configuring a database connection string

These are the obvious decisions. You already understand the trade-offs, and the outcome is predictable. The best way to handle known knowns is to automate them. Style guides, linters, and conventions remove the need to think about them at all, freeing engineers to focus on the problems that actually require judgment.

2. Known Unknowns

“Let’s spike it.”

Examples

Which database fits a multi-tenant SaaS?
How to meet GDPR logging requirements?

This is where you’re aware of the gap in your knowledge. You know you don’t know, which means you can plan for it. Known unknowns are best approached with structured exploration: build a proof of concept, run a benchmark, or consult someone with domain expertise. The key is to turn uncertainty into learning, and to capture that knowledge so it doesn’t slip back into ambiguity later.

3. Unknown Knowns

“If it works, don’t touch it.”

Examples

A scaling trick solved by an engineer three years ago
An API that looks weird but has a buried reason

This is where legacy code thrives. The system works, but the original context has been forgotten. Maybe someone added a hack to prevent cascading failures, or maybe the odd-looking API was designed around an old constraint that isn’t obvious today. Unknown knowns create risk because you might break something you didn’t even realize had a purpose.

The best antidote is to preserve knowledge with documentation, ADRs, and mentorship so that wisdom doesn’t quietly disappear over time. This doesn’t mean you should never touch legacy code. It means you approach it with care, seeking to understand before rewriting. Refactoring from knowledge leads to progress; refactoring from ignorance often reopens old wounds.

4. Unknown Unknowns

“We’ll find out in production.”

Examples

A user signs up with 🚀💥🔥 as their username and the system breaks
A sudden traffic spike from going viral melts your caching layer
A timezone edge case shifts reports by a full day

These are the landmines. Unknown unknowns are the problems you don’t even know exist until they explode in your face. You thought you had tested thoroughly, but reality exposes blind spots you never considered. The emoji username bug is a perfect case: Unicode normalization, surrogate pairs, and multi-byte storage were never even on your radar.

Unknown unknowns can’t be eliminated, but you can prepare for them: observability, tests with odd inputs, chaos drills, and a blameless culture make your systems and your team more adaptive when the unexpected happens.

How to Build Resilient Software

Resilience is the art of surviving the unknown. It doesn’t mean overengineering or locking everything down. It means buying yourself flexibility so that when surprises happen, they don’t turn into catastrophes.

Practical patterns

Preserve optionality When you change a database schema, don’t flip everything at once. Support old and new fields side by side, migrate in phases, and only remove the old path when you’re confident nothing depends on it.
Capture history before optimizing If you don’t have a fully fleshed-out auditing system, start by keeping every version of what matters, like storing every CSV upload. It may feel heavy-handed, but it means you won’t lose information. Later, when you understand the use cases better, you can design a slimmer system.
Fail gracefully Don’t assume success. Timeouts, retries, circuit breakers, and clear error handling keep failures local instead of global.
Embrace feedback loops Logging, monitoring, and alerts aren’t just for outages. They help you discover edge cases you didn’t anticipate and feed those back into design and testing.

Resilience rarely looks elegant at first. As engineers, we often aim for the most optimal, minimal, or clean design. But resilience requires flexibility, and flexibility often comes with a few rough edges. Temporary duplication, layered schemas, storing too much data, or supporting multiple code paths might feel like antipatterns. In reality, they are often what keep systems safe until the unknowns are better understood.

Resilience isn’t about perfection. It’s about giving your system the ability to bend without breaking, and your team the confidence to make changes even in the face of uncertainty.

Why This Matters

Most real failures come from the bottom half of the matrix: forgotten wisdom and surprise landmines. By naming these categories, the Rumsfeld Matrix gives us a way to think about uncertainty in engineering.

Great engineers don’t try to erase uncertainty. They accept that surprises will always show up and build systems and teams that can adapt when they do.

👽 Why AI Agents Write Alien Code — And How to Fix It

Yashodhan Singh — Wed, 02 Jul 2025 07:59:44 +0000

AI coding agents are getting absurdly good. Whether it's GPT-4, Claude Sonnet, or something else, having an AI pair-programmer can feel like magic.

But here’s the thing nobody talks about:

The code they write often feels… alien.

Not wrong — just off.

🎯 The Problem

You ask the agent to write a component, a helper function, or even a config file — and what you get is:

Functional, yes.
Accurate, mostly.
But completely misaligned with your style.

Variable names don’t follow your naming conventions. Braces are in weird places. It destructures things you wouldn’t. The imports are ordered strangely. Sometimes it even uses APIs you’d never touch.

At first, I thought the fix was simple:

📝 Write a coding conventions document.

I created a clear markdown file with all my stylistic preferences:

Naming rules
Folder structure
Syntax conventions
Patterns to avoid

Then I pasted it into the chat and told the agent:

“Follow these rules.”

It worked for a few prompts.

Then it forgot.

🤖 Agents Follow Context, Not Suggestions

Here’s the catch:

AI agents don’t remember your suggestions — they react to context.

Unless you keep repeating your style guide every few prompts, it fades. You’re left copy-pasting reminders over and over, and even then, the agent might prioritize code patterns it’s seen more often on GitHub over your personal taste.

✅ The Real Fix: Let ESLint Speak For You

What actually worked was this:

I created a strict, opinionated ESLint config that embodied my coding style.

Not just “use semi-colons” — I went all-in:

Custom rules
Plugin overrides
Import ordering
JSX formatting
Naming conventions

Once this config was active in my codebase, something amazing happened:

The agent started writing code that fit.
When it didn’t, the lint errors showed up — and the agent fixed them instantly.
I stopped explaining. The config did the talking.

Because most AI agents inside editors like VSCode see the same lint errors you do. They adjust their output in real-time based on what they see in your codebase.

🧠 Linting = Real-Time Reinforcement Learning

Every lint error becomes a feedback signal. It’s like reinforcement learning — but inside your editor.

Instead of telling the agent “please don’t use any,” your linter throws a red squiggle. The agent fixes it. Done.

The more you enforce style with tooling, the faster the agent adapts. No more alien code. No more babysitting.

🛠️ Pro Tips

1. Don’t be shy — be strict

Go beyond Prettier defaults. Add ESLint rules that actually reflect how you think.

pnpm i -D eslint eslint-config-98kb

Then build your eslint.config.js:

// eslint.config.js
import {defineConfig} from 'eslint/config';
import {recommended, strict, typescript} from 'eslint-config-98kb';
export default defineConfig(
  recommended,
  strict,
  typescript,
);

2. Enable auto-fix on save

Your agent will see the output clean up as it works — another feedback loop.

3. Use prompts for logic, not style

Don’t waste tokens on stylistic instructions. Let the config guide the tone.

✨ Conclusion

Coding agents don’t care what you say.
They care what your codebase enforces.

So stop asking them nicely to follow your style.
Tell them with tooling.

Linting isn’t just for humans anymore — it’s how you speak to your AI pair.

💬 Your Turn

Have you tried teaching your coding agent to match your style?
Did you go the linter route — or something else?

Would love to hear your take 👇

You A̶l̶m̶o̶s̶t̶ Never Need useReducer

Yashodhan Singh — Wed, 11 Jun 2025 06:57:26 +0000

Let’s stop pretending useReducer is some architectural upgrade over useState.

It’s not.

In the hands of most developers, it’s just overengineering theater. A costume.

An attempt to cosplay as a systems thinker in a CRUD world.

But here’s the truth:

If you’re reaching for useReducer in your React component, you're probably just adding ceremony to avoid writing setState.

Let’s talk about it.

🧠 Why Devs Fall for `useReducer`

It looks structured.
It feels scalable.
It smells testable.

It lets you write fancy things like:

dispatch({ type: 'UPDATE_FIELD', field: 'title', value: e.target.value });

And now you feel like you're writing a framework instead of a component.

But you're not building a state machine.
You're updating a form input.

This isn't clever. It's LARPing.

💬 The Famous Interview Trauma

You've heard it:

“My friend was rejected from a frontend role because they used useState instead of useReducer 😞”

That anecdote makes the rounds every 3 months — usually paired with something like this:

const [title, setTitle] = useState('');
const [description, setDescription] = useState('');
const [startDate, setStartDate] = useState(null);
const [endDate, setEndDate] = useState(null);

Then comes the critique:

Too many states!
No validation!
Inconsistent logic!
Not enterprisey enough!

So they slap on a reducer:

const [event, updateEvent] = useReducer((prev, next) => {
  // This section will be bad for
  // your mental health in the real world
  const newEvent = { ...prev, ...next };

  if (newEvent.startDate > newEvent.endDate) {
    newEvent.endDate = newEvent.startDate;
  }

  if (newEvent.title.length > 100) {
    newEvent.title = newEvent.title.substring(0, 100);
  }

  return newEvent;
}, {
  title: '',
  description: '',
  startDate: null,
  endDate: null,
});

Congratulations.
You’ve replaced readable logic with a pseudo–Redux wormhole to feel more "correct."

💡 Why Coupling Validation with State Stinks

You're baking validation logic into the state update mechanism. That means:

Every state change must trigger validation — even when it shouldn't

You can’t test validation separately

You can’t control when or how validation happens

You’ve locked logic into an opaque reducer blob

Validation is not a reducer's job. A reducer should handle transitions, not rules.

✅ The Clean Way (That Just Works)

Let’s write boring, effective, adult code:


function useForm(initialValues) {
  const [title, setTitle] = useState(initialValues.title);
  const [description, setDescription] = useState(initialValues.description);
  const [startDate, setStartDate] = useState(initialValues.startDate);
  const [endDate, setEndDate] = useState(initialValues.endDate);

  return {
    title,
    setTitle,
    description,
    setDescription,
    startDate,
    setStartDate,
    endDate,
    setEndDate,
  };
}

const {
  setTitle,
  setDescription,
  setStartDate,
  setEndDate,
  ...event,
} = useForm({
  title: '',
  description: '',
  startDate: null,
  endDate: null,
});

const validateEvent = (event) => {
  const errors = {};
  if (event.startDate > event.endDate) {
    errors.date = 'End date must be after start date';
  }
  if (event.title.length > 100) {
    errors.title = 'Title must be under 100 characters';
  }
  return errors;
};

You can now:

Validate on blur
Show errors inline
Test validateEvent independently
Reuse the same validation in the backend
Extend logic without digging through reducer guts

This is code that’s actually maintainable.

🤡 The Real Reason People Push useReducer

You are probably an influencers trying to sell your "How to be a 10x dev? I know, you don't" course when your only real skill is clearing interviews.

You exploit the insecurities of innocent junior devs without providing them any real value in return and by making them feel:

insecure about writing “basic” code.
useState looks amateur
Abstracting everything into a reducer makes it “professional”
More indirection = better architecture

It’s the same mindset that leads to:

Overuse of design patterns
Creating types.ts files for three enums
Wrapping simple logic in ten layers of abstraction

You're not a worse dev for writing useState.
You’re a better one for knowing when not to reach for complexity.

🧠 When useReducer Actually Belongs

Let’s be fair. Here’s when it makes sense:

✅ Finite State Machines (e.g., multi-step wizards)
✅ Undo/Redo logic
✅ Pure state transitions you want to extract + test
✅ Shared reducer logic across multiple components
✅ You're modeling explicit transitions, not just storing values

If that’s not you, and you’re still using useReducer, ask yourself:

Am I solving a real problem?
Or just inventing stuff to feel clever?

✍️ The Rule of Thumb

useState is for values.
Custom hooks are for reuse.
useReducer is for transitions.

Write code that’s easy to read, not code that performs intellectual gymnastics.

Break this rule of thumb if it gets in the way.

🔥 Final Thought

You don’t get a promotion for writing dispatch().

You don’t become a better engineer by mimicking Redux on your delete confirmation modal.

You become a better engineer by writing clear, boring, durable code your teammates can understand without context.

So unless your state has explicit transitions, interdependencies, or reversibility — just use useState.

Don't be a sheep 🐑.
You almost never need useReducer.

How LLMs Are Quietly Democratizing Intellect

Yashodhan Singh — Tue, 10 Jun 2025 22:23:12 +0000

Let’s not pretend everyone starts life with equal cognitive resources.

Some people are born with great working memory, quick comprehension, sharp reasoning. Others aren’t — but that doesn’t mean they don’t have good ideas, drive, or creativity.

Large Language Models (LLMs) are quietly helping bridge that gap.

They offer something rare:
the ability to punch above your intellectual weight.

You don’t need to remember all the edge cases, or how to word a formal request. The model helps scaffold that for you.

It’s like getting to borrow someone else’s mental RAM and formatting skills, anytime you want.

“It’s Making People Think Less” — or Is It?

Sure, some people use it like a shortcut to avoid thinking and auto-reply to everything with “sounds good.”

But the same was true of Wikipedia. Or Stack Overflow. Or calculators.

Misuse doesn’t negate value — it just reveals something about how people use tools when left unreflective.

In practice, the people getting the most out of LLMs aren’t thinking less.

They’re thinking better.

They’re testing assumptions faster. They’re seeing counterarguments they hadn’t considered.
They’re experimenting with styles of thinking that didn’t come naturally before — analytical, concise, lateral.

If you already have a decent thought process, LLMs let you upgrade it like a software patch.

It’s Not About Replacing Thinking — It’s About Scaling It

We’re used to thinking of intellect as a fixed trait.
But LLMs treat it more like compute.

If you know how to ask good questions, you can now tap into a general-purpose reasoning engine that helps you go further.

The internet gave us access to information.
LLMs give us access to synthesis — and to a kind of “on-demand second brain” that lets people without elite credentials or training produce surprisingly high-quality outcomes.

This won’t make everyone brilliant.
But it will shift the baseline.
It’s already doing that.

I Tried Vibe Coding a Semantic Layer From Scratch

Yashodhan Singh — Wed, 04 Jun 2025 10:11:08 +0000

Before this project, we already had reporting—dozens of fixed reports written in raw SQL. But our users kept coming back with one-off requests:

“Can I see this by region instead of by customer?”

“Can we compare Q1 vs Q2 just for this segment?”

“What about filtering this down to fleet customers only?”

Each request meant hand-tweaking SQL, validating the output, and adding yet another fork to our growing report list.

Our team is lean. We don’t have many senior engineers. And honestly, I had never done data engineering before.
I barely knew what “grain” meant, let alone how to design a scalable reporting system.

But I was determined to solve the problem.
And I had a secret weapon: long conversations with AI.

“Isn’t This Already Solved?”

In theory? Yes.
Big BI vendors offer semantic layers. Big tech has internal tools. There are open source solutions like Cube.js and Apache Superset.

But those solutions assume:

A team of experienced data engineers
Complex org-wide needs across many datasets
Dedicated data modeling cycles

We had none of that.

What we had was:

A well-scoped schema
A stream of custom user requests
And the need for a solution with a low learning curve and high adaptability

So I decided to build something tailored—simple, durable, and easy to own by anyone, not just me.

Phase 1: Learning the Terrain with AI

To get started, I did what I always do when entering unfamiliar territory: I asked a lot of questions.

I fed AI:

The full schema
All business-defined metrics and dimensions
Role-based access rules and exceptions
Legacy SQL logic from old reports

I asked about:

How to resolve join paths safely
What makes certain metrics non-additive
What is a non-additive metric
When fan-out happens and how to prevent it
Whether a derived metric should be nested or flattened

And I got answers that made sense. Not code—but conceptual clarity.

That’s how I went from knowing almost nothing about semantic layers…

To understanding the building blocks of semantic architecture.

Phase 2: Vibe Coding My Way into Failure

Armed with that new understanding, I did what most devs would do: I built fast.

Prompt-driven join builders
Schema-agnostic query engines
Filters and dimensions as abstract objects

It felt powerful—until it wasn’t.

Soon, I hit:

Grain mismatches that caused inflated metrics
Derived KPIs breaking due to missing dependencies
Filters applied too early, too late, or not at all

It was clever code. But unstable.

Great for a demo. Bad for production. Worse for handoff.

I'd gladly accept if vibe coding was a skill issue I can improve but I want to be sure if it's a skill issue or I was chasing shadows.

Phase 3: Burning It Down and Rebuilding with Contracts

So I reset. From scratch. Again.

This time:

Measures explicitly declare their grain and aggregation
Dimensions define their valid join paths and fact compatibility
Filters are parsed in context—validated before execution
Derived metrics rely on dependency graphs and outer aggregations
Security rules are baked into the query structure by default

I wrote:

A join resolver for composing minimal, valid paths
A filter parser that understands nesting and table origin
A query compiler that builds safe, predictable, performant SQL

Now, AI was my code companion:

Helping draft utility functions
Validating logic edge cases
Explaining odd query plan behaviors

It wasn’t building the system.

I was.

But it helped me learn faster and write better.

Where Things Stand Now

The system is still in development—but the foundation is strong.

Once done, the layer will:

Accept any compatible dimensions + metrics
Build dynamic, grain-safe SQL with reusable CTEs
Enforce multi-tenant access at the query layer
Return compatibility metadata for frontend UI guards

It’s not fully feature-complete yet—but the hardest parts are solved:

✅ Data correctness
✅ Structural safety
✅ Extensibility
✅ Teachability

The entire thing is built with handoff in mind—so that even a junior developer can understand it, extend it, and trust it.

What’s Next: The AI Chatbot — My Next Challenge

Once this layer is complete, I want to explore building an AI-powered chatbot on top of it.

Something that can take a question like:

“Compare RO sales growth by segment over the last two quarters.”

…and:

Parse the natural language
Map it to known dimensions, filters, and metrics
Validate the request
Run it safely through the semantic engine

But I know this will bring a whole new set of challenges:

Ambiguity in user intent
Fuzzy synonyms vs structured fields
Invalid requests that sound perfectly valid
Performance and security trade-offs in real time

In many ways, it’ll be like starting over—with unknown unknowns waiting at every turn.
And honestly? I’m looking forward to it.

Closing: From Blank Slate to Ownership

I started this project with zero background in data engineering.

What I had was:

Curiosity
A well-scoped schema
Real pain points
And AI as my co-pilot

Along the way, I learned to:

Respect grain
Handle fan-out
Design for clarity
Build with the next developer in mind

It’s still in progress.
But now I see the shape of the system, and I know how to complete it.

From vibes → validation → vision—with a whole lot of learning in between.
That’s what this project gave me.

🧼 Help, I Have Clean Code OCD – A Functional Programming Horror Story

Yashodhan Singh — Fri, 30 May 2025 06:05:45 +0000

"Hi, my name is Yash, and I haven’t mutated a variable in 147 days."

They say the first step is acceptance. But how do you accept that your life has become a series of pure functions and monads? That you've spent more time refactoring than writing actual features? That you once rejected a PR because someone used a let instead of a const?

Welcome to my story — a tale of one dev’s descent into the rabbit hole of functional programming and clean code purity.

📖 The Backstory: I Was Just a Developer Once

I used to write code that worked. It wasn’t elegant, but it was honest. We called APIs. We mutated objects. We had deeply nested conditionals.
It wasn’t beautiful — but it shipped.

My files were big, my variables were vague, and my linter? Mostly decorative.

And then one day... I discovered eslint --fix.

That led me to Clean Code. Then FP. Then a YouTube video where someone used a curried function to build an entire REST API. I was horrified… and inspired. I thought, “If this guy can refactor CRUD into existential math, so can I.”

What started as a pursuit of better code quickly became a full-blown personality trait.

Last night, I spent two hours to refactor something that already works. Why?

🚿 It Started Innocently…

Like all good horror stories, mine began with a desire to do better. One day I saw a talk by Uncle Bob and thought, “Yes, I too want my codebase to be so clean it could do surgery.”

So I started small:

No console.log in production code ✅
One function per concern ✅
No mutation ever ✅

But once I read about functional programming, that's when everything changed. I was already in the cult.

🌀 The Pure Function Spiral

At first, map and filter were fun little tools. Like new LEGO pieces.

Then came:

Composing functions like an orchestral symphony 🎼
Refusing to write a single if 💀
Judging colleagues for using variables with more than one responsibility

Eventually I was:

Turning state management into a philosophical debate about immutability
Writing code that passed all linter rules... and failed all human readability tests
Creating tiny functions with 100% test coverage that did absolutely nothing useful

I even had a function called normalizeData that was composed of 11 smaller functions — none of which were longer than 3 lines. Beautiful. Useless. Like modern art.

🧠 The Symptoms

You may also be infected with Clean Code OCD if:

You have more types than actual data
You use the word “side effect” in casual conversation
You believe null is a personal insult
You’ve said, “I can’t approve this PR; it’s not referentially transparent”
You get physically uncomfortable around uncurried functions

Worst of all, this obsession spreads. One code review at a time. One Slack thread about "function purity" at a time. I've seen strong, pragmatic devs fall under its spell after just a single exposure to fp-ts.

They say perfect is the enemy of done. But in software, perfect is often just a clean code compulsion hiding behind eslint.

So here’s to all of you who’ve spent two hours renaming variables for the sake of clarity — may your purity bring you peace, or at least pass CI.

And if your teammates start repeating your patterns, just remember: Clean Code OCD is contagious.

We Are Not Code Monkeys

Yashodhan Singh — Wed, 21 May 2025 10:45:18 +0000

Let’s be honest.

Some days it feels like all we do is pick up tickets and crank out features.
Another bug, another UI tweak, another "quick fix." Sprint after sprint.
Ship it and move on.

And somewhere in all that motion, it’s easy to forget:

We’re not just here to code.
We’re here to create.

🧠 You're more than a ticket machine

You’ve got ideas. You see the patterns. You know when something feels off in the codebase or the product. That voice in your head saying “There’s a better way to do this”?

That’s not noise. That’s your engineering instinct kicking in.

🏭 Feature factories don’t kill creativity — apathy does

Yeah, maybe you're not in every product meeting. Maybe the roadmap isn’t something you get to shape yet.

But here’s the truth:

Culture doesn’t change from the top. It changes when the people doing the work start doing it differently.

Start small:

Ask why before you start coding.
Suggest a better way.
Clean up something messy.
Pair up. Learn something. Share something.

You don’t need permission to care.

🧑‍💻 Code monkeys follow orders. Engineers ask questions.

Engineers:

Think about users.
Think about systems.
Think ahead.

You don’t need to be a senior dev to think like one.
Ownership doesn’t start with a promotion — it starts with a mindset.

🔥 Be the spark

Every team has someone who raises the bar. Someone who nudges the culture a little closer to better.

Why not you?

Care about quality, not just speed.
Speak up when something doesn’t make sense.
Push for smarter decisions — not just faster ones.

When enough people take that attitude, the team shifts. The work gets better.
Suddenly, you're not in a feature factory anymore.
You're on a team that builds cool stuff and gives a crap.

🙅‍♂️ You are not a code monkey.

You’re a builder.
A thinker.
A problem-solver.
An engineer.

Start acting like it. Others will follow.

🗣️ Let’s hear it — what small things have you done to make your team better? Drop them in the comments. Someone else might need the spark.

Bun 1.0: A No-Nonsense Look at the New Kid on the JavaScript Block?

Yashodhan Singh — Thu, 14 Sep 2023 10:04:06 +0000

Alright, let's hop on the hype train for a moment and talk about Bun 1.0! 🚂 Choo-choo, all aboard!

What's Cooking in the Bun Oven?

So, Bun wants to be your one-stop-shop for all things JavaScript and TypeScript. It's like the Swiss Army knife of coding, but without the awkwardness of actually trying to use a Swiss Army knife for anything serious. 🤣

Too Many Cooks in the Kitchen?

JavaScript has more tools than a hardware store, and let's be honest, it can be a mess. Node.js, npm, webpack, Jest—sounds like the lineup for a nerdy music festival. Bun aims to declutter your life by replacing all these tools without making you learn a new programming language or ditch your favorite libraries. 🎸🔨

Speedy Gonzales

Bun claims to be faster than a caffeinated squirrel, starting up 4x faster than Node.js. It's like the Usain Bolt of JavaScript runtimes. 🏃‍♂️💨

One Ring to Rule Them All

Compatibility is the name of the game here. Bun wants to be your new BFF, fitting into your life like that one friend who's always up for anything. It's a drop-in replacement for Node.js and plays nice with both CommonJS and ES modules. 🤝

Customization Station

You can trick out Bun with plugins, just like you'd add spinning rims to a car (if you're into that sort of thing). Most esbuild plugins will work with Bun, so you can make it as fancy or as simple as you like. 🚗✨

Windows to the Soul

Mac and Linux users, you're already in the club. Windows users, you're getting your VIP pass soon. Bun is working on a native Windows build, so everyone can join the party. 🎉

The Final Bun, I Mean, Run

So, is Bun 1.0 the future of JavaScript development, or is it just the flavor of the month? Only time will tell (I mean react is still the king when it should actually be 6 feet under the ground). But hey, bun's got some pretty cool tricks up its sleeve, and it's worth keeping an eye on. 👀

Avoid the Refactor Tractor 🚜

Yashodhan Singh — Thu, 14 Sep 2023 06:27:00 +0000

What is the Refactor Tractor? 🤔

We've all been there. You're working on a multi-year project, and you start to feel the itch to refactor everything. You look at the codebase and think, "I could make this so much better!" (How cute 🥹) That urge to refactor is what we affectionately call the "Refactor Tractor".

Why Do We Jump On? 🤷‍♂️

The reasons are many: new technologies emerge, coding standards evolve, or maybe (we think) we've just become better developers. The temptation is real, but before you jump on that tractor, let's weigh the pros and cons.

Pros 🌈

Improved Code Quality: Cleaner, more maintainable code.
Better Performance: Optimizations often come with refactoring (in your dreams).
Learning Opportunity: A chance to implement new technologies or patterns (the actual reason for buying a new tractor).

Cons 😬

Time-Consuming: Refactoring can take a lot of time away from new features.
Risk of Bugs: Changing existing code can introduce new issues.
Team Disruption: Everyone has to get on board with the new changes, affecting productivity.

How to Minimize the Urge 🛑

Prioritize 📝

Not all code needs refactoring. Prioritize what really needs it and what can wait.

Small Iterations 🔄

Instead of a complete overhaul, make small, incremental changes over time.

Discuss with the Team 👥

Before making any major changes, discuss them with your team. A collective decision is often better than a unilateral one.

When to Actually Do It 🕒

When It Blocks Progress: If the current architecture is hindering progress, it might be time.
Tech Debt is Piling Up: If you're spending more time fixing bugs than developing, take it as a sign.
Team Consensus: If everyone agrees that it's time, then it's probably time.

Tips 🎩

Automated Testing: Make sure you have a good suite of tests to catch any bugs.
Documentation: Document what you're changing and why, for the sake of your future self and others.
Code Reviews: Get multiple eyes on the changes to catch issues early.
Follow the Churn: Prioritise refactoring components with a high churn and low maintainability.

Conclusion 🎬

Jumping on the Refactor Tractor can be tempting, but it's not always the best course of action in a multi-year project. Weigh the pros and cons, consult with your team, and make disciplined decisions to ensure you're doing it for the right reasons.

Conquering the Learning Curve of Bazel: My Ongoing Struggles and Hopeful Horizon 📈🌅

Yashodhan Singh — Mon, 20 Feb 2023 05:57:58 +0000

Hey everyone! 🤗 Today, I wanted to talk about something that's been on my mind lately: 🤔 Bazel! This amazing build tool has SO much potential, but for me, there's been a bit of a learning curve 😩📈.

One particular challenge I've faced is with rules_nodejs 🚫. As a developer, one of my go-to tools is Storybook JS 📚🤓, but it seems almost IMPOSSIBLE to run it with rules_nodejs 😵. I've spent COUNTLESS hours trying to get it to work, but it's just not happening.

BUT, there's hope on the horizon! 🌅 I've been hearing great things about rules_js, and I'm optimistic that it will fix all the problems I'm facing with rules_nodejs. 🙏🤞 Fingers crossed! I'll be sure to share my experiences with rules_js soon.

Overall, I think it's important to remember that learning a new technology takes time and patience. 🕰️🧘 Even though I'm struggling with Bazel right now, I know that with persistence and a bit of help from the community, I'll get there eventually. 🤝

Functional Reactive Programming: My Love-Hate Relationship 💔

Yashodhan Singh — Thu, 16 Feb 2023 08:28:43 +0000

As a software developer, I've always been on the lookout for new and exciting technologies to dive into. However, my first introduction to functional reactive programming (FRP) wasn't exactly love at first sight 🙈.

You see, my first exposure to FRP was through Angular + RxJS, and let's just say it was a bit of a mess 🤯. The code was bloated, the documentation was scarce, and I just couldn't seem to wrap my head around the concept.

But then, something interesting happened. I stumbled upon a talk about FRP and things started clicking! 💡 The elegant simplicity of FRP was finally revealed to me, and I was hooked! 🎉

Here it is: The Essence and origins of Functional Reactive Programming • Conal Elliot •YOW! 2015

FRP, at its core, is a programming paradigm that allows you to model your application state as a stream of events in continuous time. This means that you can easily track changes in your data and respond to them in real-time. It's like having a superpower 🦸‍♀️ that makes your application more responsive, scalable, and predictable!

And while my love-hate relationship with Angular + RxJS is still ongoing 💔, I've found that FRP has revolutionized the way I approach software development. I've been able to write cleaner, more maintainable code and solve complex problems with ease 💻.

So, if you're feeling frustrated with your current development process, give functional reactive programming a try! 💪 You might just find yourself even more frustration with eventual peace once you catch up with it.

Checkout how FRP changed the way I do authentication

I Used to be a 💩 Coder 💻 Until I Re-discovered SOLID Principles 🌟

Yashodhan Singh — Wed, 15 Feb 2023 00:51:57 +0000

I remember when I first heard about SOLID principles, I thought to myself "what a load of 💩, who needs that many rules to write good code?" 🤔 Little did I know, it was my code that was 💩. Eventually, those principles became the cornerstone of my development practice and elevated my coding skills tenfold 🚀.

It wasn't until my CTO 🧔 started making "amazing" remarks in code review and explained the value of SOLID principles that I really understood their importance. He showed me how they made my code more maintainable, scalable and easier to understand. And trust me, that's when I really started to see the value in SOLID.

Here's how each SOLID principle leveled up my skills:

Single Responsibility Principle (SRP) 💼
This principle taught me to write code that only has one responsibility, making it much easier to maintain and understand. It's like having a neat and organized workspace, everything has its place and it's much easier to find what you need!

Open/Closed Principle (OCP) 🚪
This principle taught me to write code that can be easily extended, but not modified. It's like having a building that can be added on to, but still remains sturdy and secure.

Liskov Substitution Principle (LSP) 🔗
This principle taught me to write code that is easily interchangeable, like building with LEGOs! It's like being able to switch out parts without affecting the overall structure.

Interface Segregation Principle (ISP) 🌐
This principle taught me to write code that is flexible, allowing me to create interfaces that can be used by different parts of my code without affecting the others. It's like having multiple languages that can communicate with each other!

Dependency Inversion Principle (DIP) 💪
And my personal favourite, DIP taught me to write code that is easily adaptable, by depending on abstractions instead of concrete implementations. It's like having a toolbox that can be used for any job, no matter how complex!

In conclusion, SOLID principles may seem overwhelming at first, but they're worth taking the time to understand. Trust me, your code will thank you! 😊

P.S. 📢 Don't stress about memorizing each principle, even I had to Google them to write this article! But in practice, they've already become second nature to me, like muscle memory 💪. Just keep using SOLID principles in your development and you'll see the benefits for yourself! 💻

Forem: Yashodhan Singh

Resilience > Perfection

1. Known Knowns

2. Known Unknowns

3. Unknown Knowns

4. Unknown Unknowns

How to Build Resilient Software

Why This Matters

👽 Why AI Agents Write Alien Code — And How to Fix It

🎯 The Problem

🤖 Agents Follow Context, Not Suggestions

✅ The Real Fix: Let ESLint Speak For You

🧠 Linting = Real-Time Reinforcement Learning

🛠️ Pro Tips

1. Don’t be shy — be strict

2. Enable auto-fix on save

3. Use prompts for logic, not style

You A̶l̶m̶o̶s̶t̶ Never Need useReducer

🧠 Why Devs Fall for useReducer

💬 The Famous Interview Trauma

✅ The Clean Way (That Just Works)

🤡 The Real Reason People Push useReducer

🧠 When useReducer Actually Belongs

✍️ The Rule of Thumb

🔥 Final Thought

How LLMs Are Quietly Democratizing Intellect

“It’s Making People Think Less” — or Is It?

It’s Not About Replacing Thinking — It’s About Scaling It

I Tried Vibe Coding a Semantic Layer From Scratch

“Isn’t This Already Solved?”

Phase 1: Learning the Terrain with AI

Phase 2: Vibe Coding My Way into Failure

Phase 3: Burning It Down and Rebuilding with Contracts

Where Things Stand Now

What’s Next: The AI Chatbot — My Next Challenge

Closing: From Blank Slate to Ownership

🧼 Help, I Have Clean Code OCD – A Functional Programming Horror Story

📖 The Backstory: I Was Just a Developer Once

🚿 It Started Innocently…

🌀 The Pure Function Spiral

🧠 The Symptoms

We Are Not Code Monkeys

🧠 You're more than a ticket machine

🏭 Feature factories don’t kill creativity — apathy does

🧑‍💻 Code monkeys follow orders. Engineers ask questions.

🔥 Be the spark

🙅‍♂️ You are not a code monkey.

Bun 1.0: A No-Nonsense Look at the New Kid on the JavaScript Block?

What's Cooking in the Bun Oven?

Too Many Cooks in the Kitchen?

Speedy Gonzales

One Ring to Rule Them All

Customization Station

Windows to the Soul

The Final Bun, I Mean, Run

Avoid the Refactor Tractor 🚜

What is the Refactor Tractor? 🤔

Why Do We Jump On? 🤷‍♂️

Pros 🌈

Cons 😬

How to Minimize the Urge 🛑

Prioritize 📝

Small Iterations 🔄

Discuss with the Team 👥

When to Actually Do It 🕒

Tips 🎩

Conclusion 🎬

Conquering the Learning Curve of Bazel: My Ongoing Struggles and Hopeful Horizon 📈🌅

Functional Reactive Programming: My Love-Hate Relationship 💔

I Used to be a 💩 Coder 💻 Until I Re-discovered SOLID Principles 🌟

🧠 Why Devs Fall for `useReducer`