DEV Community: Bimochan Shrestha

Why DX is becoming a business priority

Bimochan Shrestha — Sun, 24 May 2026 07:30:00 +0000

Imagine you own a restaurant.

Your chefs are world-class, but the knives are dull, the kitchen layout is chaotic, and every ingredient is stored in a different room. They’ll still make great food… for a while. Then they’ll burn out, or worse, leave for another restaurant where the knives are sharp.

That’s what bad Developer Experience (DX) feels like. The food (product) might still come out, but the kitchen (engineering org) slowly loses its soul.

So, what actually is DX?

According to getdx.com, Developer Experience isn’t just about fancy IDEs or swag. It’s about the conditions under which developers build, every touchpoint between “I have an idea” and “it’s live.”

They define three pillars:

Feedback loops: Organizations should identify where feedback loops can be accelerated, whether that’s build and test processes, code review workflows, or deployment pipelines.
Cognitive load: Software development is inherently complex, but unnecessary complexity kills productivity and satisfaction. Cognitive load is the mental effort required for a developer to complete their work.
Flow state: Flow state is where developers do their best work. Those rare hours of deep focus when tough problems finally click. But modern work culture kills it with meetings, pings, and shifting priorities.

Teams that protect flow produce better code, faster and feel far more fulfilled doing it.

When any of these break, velocity drops and frustration spikes, quietly but inevitably.

Why businesses finally care about DX

Wealthsimple treated their internal developer platform as a product. They held weekly feedback sessions with engineers and built tools to reduce repetitive setup pain. The results were dramatic: they moved model deployment from months to days, freeing engineers to focus on building rather than battling pipelines.

That improvement wasn’t just a metric. Studies show that even a 1‑point improvement in DX score can save about 13 minutes per developer per week. Multiply that across 100 engineers and 52 weeks, and you’re looking at over 1,100 hours a year. Nearly half an engineer‑year reclaimed— just by removing friction.

The little things that change everything
Improving DX isn’t always a grand, top-down project. Sometimes, it’s the smallest changes that add up to real impact.

In one of my previous projects, local development was a nightmare. Everyone had their own scripts to spin up services or seed test data. It worked, but each dev was reinventing the wheel quietly, in their corner.

One day, we decided to surface all those private hacks in a meeting. Turns out, between eight of us, we’d already built 80% of what could’ve been a unified internal dev CLI. A week later, we packaged it and suddenly, new developers could get a full environment running with a single command.

The result?

Local setup dropped from hours to minutes.
Onboarding felt less like a rite of passage.
People started sharing their improvements instead of hoarding them.

That’s DX in action— nothing “fancy,” just frictionless.

DX is culture, not a tool

The biggest mistake leaders make is thinking DX is something you can buy— it’s not. It’s built day by day, through how teams document, share, and automate their pain away.

Every commit, every script, every small fix that makes life easier for others.

That’s Developer Experience. It’s what turns engineers from problem solvers into system thinkers.

Final reflection

If User Experience (UX) wins customers, then Developer Experience (DX) keeps the people who build for them. Developer Experience isn’t an expense; it’s how you keep great engineers from walking out the door. Start small, one shared tool, one thoughtful improvement at a time.

So, in the next sprint, ask your team:

“What slows us down that we don't need to?”

You might find that your sharpest knife is already in someone’s drawer.

Reflection for readers

What’s one small thing in your team’s developer workflow that everyone complains about but no one’s fixed yet?

That’s where your next DX win is hiding.

Original Article at LinkedIn

Configuration as Code: The Missing GitOps Layer in Multi-Tenant SaaS

Bimochan Shrestha — Fri, 22 May 2026 15:12:33 +0000

In multi-tenant SaaS systems, configuration eventually becomes part of the product itself. Tenant rules, workflow mappings, pricing behavior, routing logic, UI controls, over time these “configs” quietly become production-critical code. Yet many teams still store them in databases and allow direct edits in production on releases or on informal requests.

From my experience, that model creates anxiety.

Someone changes a value directly in a table. Nobody knows who changed it, why it changed, or what exactly the previous state was. Audits exist, but database audits rarely feel natural to engineers. They’re fragmented, harder to review, and disconnected from normal development workflows.

That’s why I started preferring a CaC mindset: Configuration as Code.

Not secrets. Secrets belong in proper secret managers. But operational and business configuration should live in versioned files, committed to Git, reviewed through pull requests, and deployed through pipelines just like application code.

This is also distinct from feature flags. Feature flags are intentionally dynamic, frequently toggled, and often owned by product teams. Configuration is different. It defines long-term system behavior.

The advantages are surprisingly practical:

Every config change is reviewable
Environments stay reproducible and most importantly predictable
Engineers stop “hot-fixing” production tables
Rollbacks become trivial
History is permanent and searchable
Tenant-specific behavior becomes explicit instead of tribal knowledge

Most importantly, it creates calmness within engineering teams. Nobody silently edits production state anymore. The system becomes predictable.

While GitOps is standard for infrastructure, we need to apply that exact same philosophy to business and tenant configuration: a paradigm we can call Configuration as Code (CaC).

Use YAML, JSON, or any structured format that fits your system. Design folder structures around domains, tenants, environments, or ownership boundaries.

For large-scale systems, keeping configuration in a separate repository can work even better. Pull requests remain isolated, review ownership becomes clearer, and configuration evolves independently from application deployments.

Even legacy systems that rely heavily on database-driven configuration still have a practical migration path. The database can remain, but only as a deployment target and not the source of truth.

Store configuration in files, then use CI/CD pipelines to reconcile and overwrite database values automatically. At that point, direct human write access to configuration tables should ideally disappear entirely.
Git repo → PR → CI/CD → Config Sync → Database/Application

Configs deserves the same engineering discipline as code. Versioning, reviews, approvals, traceability, and reproducibility should not stop at the application layer.

DynamoDB GUI in local

Bimochan Shrestha — Mon, 06 Jan 2025 09:04:00 +0000

I came across this amazing tool a couple of years ago, and I just had to share it here. It’s a game-changer for working with AWS DynamoDB locally!

Here’s why I love it:

No AWS costs – You can experiment freely without worrying about your budget.
Super low latency – It’s incredibly fast, making development seamless.
Regular updates – The tool stays up-to-date with new features and fixes.
Exceptional support – Have a question or a feature request? The maintainers are quick to respond and deliver.

Take a look at the README file for all the details on how to get started. It’s well worth checking out!

Github-Repo

Jira Link Auto Commenter

Bimochan Shrestha — Sat, 25 Dec 2021 03:42:28 +0000

Migrating from bitbucket to Github made me lack only one feature. The link that navigates to its related Jira ticket from pull request.

This is why I created this tool for my project.
This Github action auto comments in pull request with Jira link to it. This tool is helpful for devs who use consistent PR summary like Ticket-1234: This is PR summary.
It grabs the ticket number using regex and comments on the PR by making a JIRA link. If it can't find the ticket number, it will fail silently and won't fail the whole workflow.

How to use:

Create a workflow file in root of your project.
.github/workflows/main.yml

Input:

custom-comment(optional): If you want to add your own comments before Jira link. Default is Thank you for your contributions. Jira link:
jira-project-url: you can figure our this URL by going to any of your JIRA ticket in new tab and checking the URI box.
GITHUB_TOKEN: is auto generated

on: pull_request

jobs:
  example_comment_pr:
    runs-on: ubuntu-latest
    name: Auto jira link commenter
    steps:
      - name: Checkout
        uses: actions/checkout@v1

      - name: Comment PR
        uses: sbimochan/jira-link-commenter@v2.4

        with:
          jira-project-url: https://jira.atlassian.net/browse
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          custom-comment: 'Thank you for your contribution!!! :confetti_ball:'

Hope you will find it useful for your project.

Links:

Marketplace
Github Repo

HacktOverFest

Bimochan Shrestha — Mon, 30 Dec 2019 14:13:03 +0000

Wanna check status of your services in one click? Let's build it together

Bimochan Shrestha — Thu, 14 Nov 2019 15:52:01 +0000

Porter is a tiny tool that searches for our specified ports from netstat and displays message in red or green color.

Link to github

Contributors wanted for synth music creation project

Bimochan Shrestha — Wed, 02 Oct 2019 04:35:17 +0000

This is a project I built during my internship. I want to add new better sounds by using Web audio API's filters. You also can do a QA and post on its issues page. Any contributions are heavily welcome.

Github repo link

Contributors wanted for synth music creation project

Bimochan Shrestha — Wed, 02 Oct 2019 04:22:36 +0000

Github repo link

Happy Hacktoberfest!

Smart Commit

Bimochan Shrestha — Tue, 22 Jan 2019 08:33:25 +0000

To those who works with Jira, we have a convention to prefix commit name with ticket number. This repo solves that tedious task.

Story: I searched for command that could print the current branch(our branch name = Jira ticket number) and decided to concat it with hyphens, colons and user’s input message.

Have a look.

Smart commit github link