DEV Community: Sumeet Dugg

Fake Developer Dashboard That Roasts You While You Work 💀

Sumeet Dugg — Sun, 12 Apr 2026 14:43:11 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I built FakeDevDashboard — a satirical, real-time developer dashboard that looks completely serious but shows 100% fake (and painfully relatable) metrics written in Csharp programming.

It includes:

Fake system metrics (CPU always dying 🔥)
Developer “mental state” tracking (highly questionable accuracy)
AI-generated chaos predictions using Google Gemini
Fake commit history (aka Wall of Shame)

The goal was simple:

👉 Make something that looks enterprise-level… but do silly things to developers.

Project

sumeetpypi / dev-Challenges-projects

⚡ FakeDevDashboard

A completely fake, hilariously over-engineered developer monitoring dashboard that looks very serious and roasts you while you work.

⚡ FAKEDEV DASHBOARD ONLINE
All metrics are completely fake. Your prediction is 100% real

📸 What It Looks Like

A dark terminal-aesthetic dashboard with four main panels:

System Metrics — CPU always screaming, RAM holding on for dear life
Mental State Monitor — Imposter syndrome at 94%, sanity at 12%
AI Chaos Engine — Gemini AI predicting your production outages
Wall of Shame — Your fake (but accurate) commit history

✨ Features

Feature	Description
🖥️ Fake System Metrics	CPU/RAM/Disk/Network bars that auto-refresh every 8 seconds
🧠 Mental State Monitor	Tracks sanity, confidence, imposter syndrome & reddit time
🤖 AI Chaos Engine	Google Gemini generates prophecies, horoscopes & chaos warnings
💬 Live AI Chat	Full conversation with the Chaos Engine in the dashboard
🚨 Random Alerts	Rotating panel of darkly humorous

…

View on GitHub

How I Built It

🏗️ Tech Stack

ASP.NET Core MVC (.NET 8)
C#
Google Gemini 2.0 Flash API
HTML + CSS Grid + JavaScript (fetch + setInterval)

⚙️ Architecture

The project follows clean MVC architecture:

🔌 Key Features

Live updates using polling (no SignalR)
Dependency Injection with Singleton services
AI integration with fallback handling
Graceful degradation (works even without API key)

🤖 AI Chaos Engine

Uses Google Gemini API to generate:

Developer horoscope
Daily prophecy
Deployment risk
Chaos probability

Fallback system ensures:

App never crashes
Always returns something funny

🧩 Features

🖥️ System Metrics

CPU always above 90%
Chrome using entire RAM
Node modules consuming reality

🧠 Developer Metrics

Confidence: low
Bugs: increasing
Google searches: questionable

🤖 AI Chat

Ask AI if you should deploy
Get roasted professionally

📝 Wall of Shame

Example commits:

⚡ Fun Elements

Random chaos alerts every ~25 seconds
“Trigger Chaos” button
Konami Code Easter Egg 🎮
DevTools console surprise
Fake but realistic alerts

💡 What I Learned

Clean dependency injection in ASP.NET Core
Using IHttpClientFactory properly
Async/await patterns in real APIs
Strongly typed ViewModels
Designing resilient systems with fallbacks

🚀 Try It Yourself

Clone the repo
Open in Visual Studio 2022
Add Gemini API key in appsettings.json (optional)
Run the app

No API key?

👉 No problem — it still works with built-in chaos 😄

Prize Category

Best Google AI Usage

Because:

Integrated Gemini API into a real app
Built fallback-safe AI system
Used AI creatively (not just “generate text”)
Turned AI into a chaos engine 😈

Final Thought

We spend so much time building serious software.

Sometimes…

you need a dashboard that tells you:

“Deployment successful. Consequences unknown.”

ASP.NET Core MVC Explained — Step-by-Step with Real Code & Best Practices

Sumeet Dugg — Tue, 07 Apr 2026 10:45:25 +0000

Understand models, views, controllers and why you should use MVC for scalable, testable applications.

Introduction

Model-View-Controller (MVC) is the standard architectural pattern for building modern web applications in ASP.NET Core. It is a design pattern that separates an application into three main logical components: the Model, the View, and the Controller.

This separation helps manage complexity when building applications, allowing you to focus on one aspect of the implementation at a time.

During my college days, I built a Banking System project as part of my academic curriculum. You can check it out here: bankingProject-c-.net
Challenges & Limitations I Faced Without MVC

Building the project without MVC introduced several problems:

No Separation of Concerns — All HTML, business logic, and data handling lived together. How MVC Solves These Problems In contrast, MVC provides:

Models for data and business logic

Views for UI

Controllers to handle user interaction and route requests

This separation makes the code easier to maintain, easier to test, and cleaner and scalable.

1. The Core Components

Each component has a distinct responsibility. Understanding the boundaries between them is key to writing clean code.

M — The Model

The Model represents the shape of your data and the business logic. It is the "truth" of your application.

Responsibilities: Manages the state of the application and handles data logic (e.g., interacting with the database, validating data rules).
In ASP.NET Core: These are typically plain C# classes (POCOs).
Domain Models: Represent database tables (e.g. Product, User)
View Models: Data specifically shaped for display on a screen (e.g. ProductSummaryViewModel that combines data from multiple tables).

V — The View

The View is the User Interface (UI). Its only job is to display information to the user.

Responsibilities: Renders the user interface elements (HTML, CSS) using data provided by the Controller. Ideally, a View should not contain complex logic — only presentation logic (e.g., loops to display a list, if-statements to show/hide buttons).
In ASP.NET Core: These are .cshtml files using the Razor view engine. Razor allows you to embed C# code directly into HTML to generate dynamic content.

C — The Controller

The Controller is the coordinator. It handles user input and interaction.

Responsibilities: Receives the user's request, figures out what to do with it (usually by calling services or the Model), and then selects which View to return to the user.
In ASP.NET Core: Controllers are C# classes that inherit from Controller. They contain public methods called Actions (e.g., Index(), Details(id)).

2. The Request Lifecycle

To understand MVC, you must follow the path of a web request (e.g., a user clicking a link).

Routing: A user navigates to a URL like Books/Details/2. The ASP.NET Core Routing engine determines it needs the BooksController and the Details action method.
Controller Action: The Details method in the Controller executes.
Model Retrieval: The Model retrieves the data (perhaps from a SQL database).
View Selection: The Controller receives the data, decides which View to use (usually Details.cshtml), and passes the data (the Model) to it.
Rendering: The Razor View Engine takes the HTML template and merges it with the Model data to produce a standard HTML page.
Response: The final HTML is sent back to the user's browser.

3. Key Advantages of MVC Architecture

Separation of Concerns (SoC): By decoupling the UI (View), Data (Model), and Application Logic (Controller), the application becomes easier to manage. Front-end developers can modify HTML/CSS without breaking backend logic, and vice versa.
Enhanced Testability: Since Controllers and Models are standard C# classes independent of the UI, you can easily write unit tests for them without simulating a browser.
Full Control Over HTML: Unlike ASP.NET Web Forms which auto-generated complex HTML, MVC gives you absolute control over rendered markup — critical for modern CSS frameworks like Bootstrap or Tailwind.
Asynchronous Support: ASP.NET Core MVC is built to handle async/await efficiently, allowing applications to handle more concurrent requests without blocking the server.

4. MVC Project Structure in ASP.NET Core

When you create a new MVC project via Visual Studio or CLI (dotnet new mvc), you get this standard folder structure:

Note: If you want to learn how to download and install Visual Studio, check out this guide: Getting Started with C# Programming

Create Your First ASP.NET Core MVC Project

Step 1 — Open Visual Studio and Create a New Project

Open Visual Studio
Click Create a new project

Step 2 — Select Project Template

Choose ASP.NET Core Web App (Model-View-Controller)
Language: C#
Platform: Windows / .NET
Click Next

Step 3 — Configure the Project

Fill in the following details:

Project name: BooksLibrary
Location: Default (or your preferred path)
Solution name: BooksLibrary

Click Next.

Note: You can choose your desired location to store project files. I recommend keep default location as it is now.

Step 4 — Choose .NET Version

Select the latest available version: .NET 9 / .NET 10 (LTS)
Set Authentication type to None
Click Create

Visual Studio will scaffold the project and open the default MVC structure.

Understanding MVC Through Code Examples

M — The Model

In MVC architecture, the Model carries the heaviest responsibility. It represents real-world entities, business logic, and domain rules that form the foundation of your application.

For the BooksLibrary project, we need one class — Book.cs — to hold core information about each library book.

Right-click the Models folder in Solution Explorer → Add → Class → name it Book.cs → click Add.

namespace BooksLibrary.Models
{
    public class Book
    {
        public int Id { get; set; }
        public string? Title { get; set; }
        public string? Author { get; set; }
        public string? Genre { get; set; }
        public decimal Price { get; set; }
    }
}

Note: A namespace is a container that groups related classes in C#. It prevents naming conflicts and keeps your code maintainable.

V — The View

Views are the visual layer of your MVC application. They receive data from Controllers and render it as HTML. Views should not contain business logic — only presentation logic.

Views use Razor syntax (.cshtml files) that blends HTML with C# code.

Folder Structure for Views

Views/
  ├── Books/
  │   ├── Index.cshtml
  │   └── Details.cshtml
  ├── Shared/
  │   └── _Layout.cshtml
  └── _ViewStart.cshtml

Index.cshtml — Book List View

Right-click Views/Books → Add View → name it Index.cshtml.

@model IEnumerable<BooksLibrary.Models.Book>
@{
    ViewData["Title"] = "Books Library";
}

<div class="container mt-4">
    <h2>Our Book Collections</h2>
    <table class="table table-striped table-hover">
        <thead>
            <tr>
                <th>Title</th>
                <th>Author</th>
                <th>Genre</th>
                <th>Price</th>
                <th>Actions</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var book in Model)
            {
                <tr>
                    <td>@book.Title</td>
                    <td>@book.Author</td>
                    <td>@book.Genre</td>
                    <td>$@book.Price.ToString("F2")</td>
                    <td>
                        <a asp-action="Details" asp-route-id="@book.Id"
                           class="btn btn-sm btn-info">Details</a>
                    </td>
                </tr>
            }
        </tbody>
    </table>
</div>

Breaking Down the Razor Syntax

The @model Directive — tells the view what type of data to expect. Must be the first line.

@model IEnumerable<BooksLibrary.Models.Book>

Setting View Metadata — @{ } blocks let you write C# code. ViewData passes info like the page title to the layout.

@{
    ViewData["Title"] = "Books Library";
}

Outputting Variables — the @ symbol switches from HTML to C#.

@book.Title

C# Control Structures — use foreach, if, while inside Razor views.

@foreach (var book in Model)
{
    <tr>
        <td>@book.Title</td>
    </tr>
}

Tag Helpers — asp-action generates the correct route URL; asp-route-id passes the book ID as a parameter.

<a asp-action="Details" asp-route-id="@book.Id" class="btn btn-sm btn-info">Details</a>

Details.cshtml — Single Book View

Create Details.cshtml in the Views/Books folder:

@model BooksLibrary.Models.Book
@{
    ViewData["Title"] = "Book Details";
}

<div class="container mt-4">
    <h2>Book Details</h2>
    <div class="card">
        <div class="card-body">
            <h4 class="card-title">@Model.Title</h4>
            <dl class="row">
                <dt class="col-sm-3">Author</dt>
                <dd class="col-sm-9">@Model.Author</dd>
                <dt class="col-sm-3">Genre</dt>
                <dd class="col-sm-9">@Model.Genre</dd>
                <dt class="col-sm-3">Price</dt>
                <dd class="col-sm-9">$@Model.Price.ToString("F2")</dd>
            </dl>
            <div class="mt-3">
                <a asp-action="Index" class="btn btn-secondary">Back to List</a>
            </div>
        </div>
    </div>
</div>

This view expects a single Book object rather than a collection — note the @model directive reflects that.

C — The Controller

Controllers are the traffic cops of your MVC application. They handle incoming requests, coordinate between Models and Views, and decide what response to send back.

When a user clicks a link or submits a form, the Controller:

Processes the incoming request
Interacts with the Model (retrieves or updates data)
Selects the appropriate View
Passes data to that View
Returns the rendered result to the user

Creating the Books Controller

Right-click Controllers → Add Controller → choose MVC Controller - Empty → name it BooksController.cs.

using System.Diagnostics;
using BooksLibrary.Models;
using Microsoft.AspNetCore.Mvc;

namespace BooksLibrary.Controllers
{
    public class BooksController : Controller
    {
        private static List<Book> _books = new List<Book>
        {
            new Book
            {
                Id = 1,
                Title = "The Alchemist",
                Author = "Paulo Coelho",
                Genre = "Fantasy/Adventure",
                Price = 12.99m
            },
            new Book
            {
                Id = 2,
                Title = "Harry Potter and the Philosopher's Stone",
                Author = "J.K. Rowling",
                Genre = "Fantasy",
                Price = 14.99m
            },
            new Book
            {
                Id = 3,
                Title = "1984",
                Author = "George Orwell",
                Genre = "Dystopian",
                Price = 13.99m
            }
        };

        public IActionResult Index()
        {
            return View(_books);
        }

        public IActionResult Details(int id)
        {
            var book = _books.FirstOrDefault(b => b.Id == id);

            if (book == null)
            {
                return NotFound();
            }

            return View(book);
        }

        [ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
        public IActionResult Error()
        {
            return View(new ErrorViewModel
            {
                RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier
            });
        }
    }
}

Breaking Down the Controller

Controller Inheritance

public class BooksController : Controller

Every controller inherits from the Controller base class, which provides View(), RedirectToAction(), and NotFound().

Action Methods

public IActionResult Index()
{
    return View(_books);
}

Action methods return IActionResult — typically a view, redirect, or HTTP status code. View(_books) passes the book collection to the Index view.

Route Parameters

public IActionResult Details(int id)

Parameters are automatically populated from the URL. For /Books/Details/3, the id parameter receives the value 3.

Running the Application

In Visual Studio, find the green ▶ Play button in the top toolbar (labelled "IIS Express" or your project name)
Click it or press F5

The browser will open showing your books list. Click the Details button on any book to see its individual details page.

What We Accomplished

We built a complete MVC application from the ground up, covering all three core components:

The Model — The Book class defines the data structure with properties like Title, Author, Genre, and Price. It is the foundation everything else is built on.
The Views — Two Razor views handle the presentation layer: Index.cshtml lists all books in a table, and Details.cshtml displays information for a single book.
The Controller — BooksController orchestrates everything. It handles incoming requests, manages the book collection, and coordinates between the Model and Views to deliver the right content.

This is the essence of MVC — clean separation of concerns that makes your application easier to maintain, test, and scale.

Found This Helpful?

Leave a comment below sharing what you learned, what challenges you faced, or what you're planning to build next!

Related links:

I moved our Python interpreter into Docker. Full story + setup guide: 👇 https://dev.to/practical_tech_notes/my-local-python-setup-was-quietly-destroying-our-teams-productivity-docker-fixed-it-1647 #Python #Docker #VSCode

Sumeet Dugg — Fri, 03 Apr 2026 15:59:13 +0000

Sumeet Dugg

Apr 3

My Local Python Setup Was Quietly Destroying Our Team's Productivity. Docker Fixed It.

#docker #cicd #python #kubernetes

Comments 2

6 min read

My Local Python Setup Was Quietly Destroying Our Team's Productivity. Docker Fixed It.

Sumeet Dugg — Fri, 03 Apr 2026 15:50:29 +0000

How I moved our Python interpreter into a Docker container, wired it into VS Code, and never looked back.

Let me be upfront with you, I didn't want to write this article.

Not because the topic isn't worth it — it absolutely is — but because writing it means admitting that I let a fixable problem drag on for almost five months before I actually fixed it. Five months of "works on my machine." Five months of onboarding friction. Five months of my team losing hours to an issue that, once solved, took an afternoon.

So consider this both a technical walkthrough and a cautionary tale from someone who waited too long.

The Environment That Slowly Ate Our Standup

Picture this: three developers, one Python codebase, and a Monday morning that starts with a Slack message at 9:04 AM.

"Hey, the pipeline script is throwing a ModuleNotFoundError. Did something change?"

Nothing changed. Nothing ever changed. That was the whole problem.

We had a requirements.txt. We had virtual environments. We had a well-intentioned README with setup instructions that were already six weeks out of date. What we did not have was any guarantee whatsoever that the Python interpreter running on my Windows machine was looking at the same world as the one running on my colleague's MacBook or our third teammate's Ubuntu workstation.

Every developer's local machine is an ecosystem — years of installs, PATH entries, conflicting system packages, half-removed tools that left ghosts behind. You don't notice the weight of it until it starts affecting other people.

The final straw came on a Wednesday afternoon. We were two days from a demo. I'd spent the morning writing a data transformation function that worked perfectly. I pushed it. Twenty minutes later I got a message: "This is crashing for me immediately."

Same code. Different machine. Different Python minor version — 3.10.4 vs 3.10.11 — and a single library that handled a deprecation differently between them.

I spent three hours on that. Three hours, two days before a demo, on an environment problem.

That evening I opened a new branch and set up Docker.

Why Docker and Why VS Code Dev Containers Specifically

The idea is not complicated once you accept it: stop treating your interpreter as something that lives on your machine, and start treating it as something that lives in your project.

Docker lets you write a Dockerfile — essentially a recipe — that describes an environment precisely. Operating system, Python version, every dependency, every configuration detail. Docker builds that recipe into a container: an isolated, reproducible box. Your code runs inside that box. It runs the same way on every machine. It runs the same way in six months when someone dusts off the repo.

VS Code's Dev Containers extension is what makes this actually pleasant to work in. Instead of running Docker separately and juggling a local editor alongside it, VS Code connects directly into the container. Your terminal, your debugger, your IntelliSense, your interpreter — everything operates from inside the container. From the outside it feels exactly like working locally. From the inside, every single person on the team is running identical environments.

That's the shift that mattered to us: the environment stops being invisible infrastructure that lives on individual laptops and becomes an explicit, version-controlled part of the project. When the environment breaks, you fix the Dockerfile and you commit the fix. Everyone gets it.

The Setup, Done Properly

Let me walk through exactly what I built. I'll explain the reasoning behind each piece rather than just dropping files at you.

Project structure when we were done:

my-project/
├── .devcontainer/
│   └── devcontainer.json
├── Dockerfile
├── requirements.txt
└── main.py

The Dockerfile

#Use an official Python runtime as a base image

FROM python:3.14.3-slim

#Optional: tools you may want during development

RUN apt-get update 
&& apt-get install -y --no-install-recommends git curl 
&& rm -rf /var/lib/apt/lists/*

#Set the working directory in the container

WORKDIR /app

#Copy the requirements file into the container (if you have one)

COPY requirements.txt ./

#Install any needed Python packages specified in requirements.txt

RUN pip install --no-cache-dir -r requirements.txt

#Copy code last (better layer caching)

COPY . .

A few deliberate choices here worth explaining.

I used python:3.14.3-slim rather than python:3.14.3. The slim variant strips out things like documentation files and build tools that we don't need at runtime. It keeps the image smaller and faster to pull, which matters when someone is spinning this up for the first time on a slow connection.

The WORKDIR /app appline sets the working directory inside the container to a clean, predictable path. When VS Code mounts your project into the container, it maps to this location. No path confusion, no surprises.

Copying requirements.txt before anything else is intentional. Docker builds in layers, and it caches each layer. If your requirements haven't changed but your code has, Docker doesn't re-run pip install on every rebuild — it uses the cached layer. This makes iteration fast.

Requirements File

I added list of libraries, i was willing to use

fastapi
uvicorn
pydantic
numpy
pandas
scikit-learn
langchain
openai
requests
python-dotenv

Building docker image

Open cmd or visual code terminal .
1. Go to project files where it have Dockerfile from cmd for example cd .
Write command as shown below:

docker build -t my-python-interpreter:3.14.3 .

What above Command Does ??

It builds a Docker image from your project files and gives name to it.

Step-by-Step Explaination

docker build - Create an image using the Dockerfile in this directory.
-t - It lets you name your image .

In our case my-python-interpreter is the name of image and 3.14.3 is the version(tag)

Running Docker python interpreter image from VScode

Let start adding docker image interpreter to VScode

Open VS Code and open the project folder containing your Dockerfile.
Hit Ctrl + Shift + P and type Dev Containers: Add Dev Container into the text box.
Click on Dev Containers: Add Dev Container Configuration Files...
Click on Add configuration to workspace and press Enter.
It will create the configuration files in your project.

Next Step run container

Running container in VScode terminal code

open terminal in VScode from Menu → Terminal → New Terminal
Write command as shown below:

docker run -it my-python-interpreter:3.14.3

docker run - Create + start a new container from an image
-i - Interactive , keeps STDIN open and allow to type commands inside container
-t - Create + start a new container from an image
my-python-interpreter - Image name
3.14.3 - Version name (Tag)

3. Press Ctrl + Shift + P

4 . Write Dev Containers: Attach to Running Container...

5. Press Enter .

6. New window will open , now you can check you added interpreter from ternimal and check python interpreter

7. Write command- which python and which pip, you should see something like below:

Congratulation! Interpreter added successfully

If you want to understand about docker images and containers you can follow article: Understand docker images and containers

What Changed for the Team

I rolled this out on a Thursday. By Friday morning, every developer had pulled the branch, reopened in the Dev Container, and was running code.

Here's the before and after that actually mattered:

Onboarding a new developer, before: roughly four hours. Install Python, set up a virtual environment, install dependencies, hit a conflict, debug the conflict, realise a system package was interfering, fix that, update the README with the step we'd missed.

Onboarding a new developer, after: clone the repo, open in VS Code, click "Reopen in Container," wait three minutes for the image to build, done. The fourth developer we brought on set herself up entirely independently without asking anyone a single question.

Debugging environment issues, before: a ritual of sharing Python versions, pip list outputs, PATH variables, and educated guesses.

Debugging environment issues, after: there are no environment issues. If the code runs in the container on my machine, it runs in the container on yours. When we do find a configuration problem, we fix the Dockerfile, push it, and everyone rebuilds. One fix, universally applied.

The most underrated change was what disappeared from our standups. We used to start every session with at least one throwaway exchange about someone's environment. That's gone. We talk about actual work now.

The Honest Takeaway

The environment is now a first-class part of the project. It lives in the repository. It's reviewed in pull requests. When someone joins the project in eight months, they don't inherit our laptop histories — they get a clean, defined, reproducible box. That's what professional software development should look like.

If you're still fighting your local Python setup — if your standup has a regular guest appearance from "it works on my machine" — this is the fix. It costs an afternoon. It pays back immediately.

If this article saved you debugging time or helped your team, — Questions about the setup? Leave a comment and I'll answer every one.

Echoes of Experience: From Writing Code to Writing Myself

Sumeet Dugg — Mon, 23 Mar 2026 16:00:35 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

This is a submission for the 2026 WeCoded Challenge:

Echoes of Experience

There is a strange kind of silence that comes with staring at a blank screen.

Not the peaceful silence you enjoy after solving a bug.
Not the satisfying quiet after a long day of coding.

This one feels different.It feels like doubt.

That was me a few months ago — not as a developer, but as a writer.

The Developer Who Couldn’t Write

I’ve been a Python developer for over four years now. I’ve built APIs, handled backend logic, worked with databases, and debugged problems that once felt impossible. In code, I was confident.

But writing?

That was a completely different story.

I remember opening my first article draft. The cursor blinked at me like it was asking a question I couldn’t answer:

“What do you even have to say?”

I closed the tab.
That became a habit.

My Journey Didn’t Start With Confidence

Like many developers, my journey wasn’t a straight line.

I didn’t wake up one day knowing Python. I didn’t walk into my first job feeling like an expert. I struggled. A lot.

I come from a background where opportunities weren’t always obvious. I had to figure things out step by step. Learning programming wasn’t glamorous—it was confusing, frustrating, and sometimes lonely.

I still remember spending hours trying to understand why a simple loop wasn’t working. Or why an API call failed without any clear error.

There were no mentors guiding me daily. No perfect roadmap. Just curiosity… and persistence.

And somehow, that was enough._

The Silent Growth No One Sees

In tech, growth is rarely loud.

No one applauds when you finally understand asynchronous programming.
No one celebrates when you debug something after three hours.

But those moments change you.

They build something deeper than skills — they build resilience.

Over the years, I became someone who could break down problems, think logically, and keep going even when nothing made sense.

But here’s what I didn’t realize:

Those struggles were stories.

And I wasn’t telling them.

Why I Started Writing (Even When I Wasn’t Ready)

The idea of writing didn’t come from confidence. It came from frustration.

I wanted to earn something extra. I wanted to share knowledge. I wanted to grow beyond just coding.

But more than that… I wanted to be seen.

Not in a loud, attention-seeking way. But in a real way.

I realized something important:

There are thousands of developers like me — learning quietly, struggling silently, improving slowly.

And most of them never share their journey.

So I decided to try.

Even if I wasn’t perfect.

Even if my writing wasn’t “professional.”

Even if no one read it.

The First Attempt (And the Fear That Came With It)

My first article wasn’t great.

I overthought every sentence. I kept editing. Deleting. Rewriting.

It didn’t sound like me.

It sounded like someone trying to sound smart.

And that’s when I understood something important:

Writing is not about sounding intelligent. It’s about sounding honest.

So I started again.

This time, I wrote like I speak.

Simple. Direct. Real.

And suddenly, it felt easier.

The Reality No One Talks About

Let me be honest.

Writing articles is hard.

Not technically hard — emotionally hard.

You start questioning everything:

“Is this useful?”
“Will anyone read this?”
“Am I wasting my time?”

And when results don’t come quickly — no views, no earnings, no recognition — it hits even harder.

I applied to programs. I waited for responses. Days turned into weeks.

Nothing.

And that silence felt heavier than any rejection.

Because at least rejection gives you closure.

Waiting doesn’t.

But Something Changed

Even though I wasn’t earning yet… something else was happening.

I was thinking differently.

When I solved a problem, I didn’t just move on. I asked:

“How would I explain this to someone else?”

When I learned something new, I thought:

“Is this worth sharing?”

And slowly, I started noticing something:

I wasn’t just consuming knowledge anymore.

I was shaping it.

Writing Made Me a Better Developer

This was unexpected.

Writing didn’t just improve my communication — it improved my thinking.

Because when you write:

You simplify complex ideas
You organize your thoughts
You identify gaps in your understanding

There were times I thought I understood something… until I tried explaining it.

That’s when the real learning began.

The Invisible Struggle of Many Developers

There’s a truth we don’t talk about enough:

Many developers feel invisible.

They work hard. They learn. They grow.

But they don’t share.

Not because they don’t have value — but because they think they don’t.

They think:

“I’m not experienced enough”
“Others know more than me”
“My story isn’t special”

I used to think the same.

But here’s what I’ve learned:

Your story doesn’t need to be extraordinary to be meaningful.

It just needs to be real.

My Experience Is Not Unique — And That’s the Point

I’m not someone who built a startup.
I’m not someone who went viral overnight.
I’m just a developer who kept going.

And that’s exactly why my story matters.

Because it’s relatable.

There are people right now:

Learning their first programming language
Struggling with self-doubt
Trying to find their place in tech

And they don’t need perfect success stories.

They need real ones.

The Turning Point: Accepting Imperfection

At some point, I stopped trying to be perfect.

I stopped chasing the idea of writing “the best article.”

Instead, I focused on writing an honest one.

And that changed everything.

Because perfection delays action.

But honesty creates connection.

What I’ve Learned So Far

If I had to summarize my journey into a few lessons, it would be this:

You Don’t Need Permission to Start

No one will tell you, “Now you’re ready to write.”

You just begin.

Your Early Work Won’t Be Great — And That’s Okay

Growth comes from doing, not waiting.

Consistency Matters More Than Motivation

You won’t feel inspired every day. Show up anyway.

Sharing Is a Skill

Just like coding, writing improves with practice.

Value Comes Before Results

Focus on helping, not earning. Results follow.

Where I Am Today

I’m still learning.

Still writing.

Still figuring things out.

I haven’t “made it” yet. I’m not where I want to be.

But I’m not where I used to be either.

And that matters.

Because progress isn’t always visible.

But it’s always happening.

Why I’m Still Writing

I’m not writing because I’ve achieved everything.

I’m writing because I’m still on the journey.

And maybe that’s the most honest place to write from.

If even one person reads my story and thinks:

“I’m not alone in this.”

Then it’s worth it.

To Anyone Reading This

If you’re a developer who’s thinking about writing… start.

Not when you feel ready.

Not when you feel confident.

Start now.

Write about:

What you learned today
What confused you
What you struggled with
What you finally understood

Because someone out there is exactly where you were yesterday.

And your words might help them move forward.

The Echo That Stays

We often think impact comes from big achievements.

But sometimes, it comes from small, honest stories.

Stories that echo.

Stories that stay.

Stories that remind someone that progress is possible — even when it’s slow, even when it’s messy.

This is mine.

And I’m just getting started.

How I Solved a Deployment Nightmare Using Docker and FastAPI

Sumeet Dugg — Mon, 23 Mar 2026 05:37:52 +0000

The Problem I Faced
I was working at a Python development company where we had to deploy applications on every client machine. Each time a new feature was added or a bug was fixed, we had to manually install or update the application on multiple systems.

This process was:

Time-consuming
Error-prone
Difficult to maintain

Every deployment felt like repeating the same exhausting cycle.

The Idea That Changed Everything
One day, I suggested a simple but powerful idea to my team:

“What if we install Docker on a central server and allow all clients to access the application from there?”

Instead of installing applications on every machine, we could:

Run the application once on a server
Allow clients to access it via a browser using an IP address

Example:

http://<server-ip>:8000

The Result
This approach completely transformed our workflow:

No need to install software on every client machine
Centralized updates (update once, reflect everywhere)
Easy access through browsers
Clean and scalable architecture

Now, every client had separate access to the application just by visiting the server address.

Why Docker Made This Possible
Before Docker:

Applications were installed individually
Dependencies conflicted
Environment issues were common

After Docker:

Everything runs inside containers
Applications become portable
Same setup works anywhere in the world

What is FastAPI (Quick Overview)
FastAPI is a Python-based framework built on top of Starlette. It leverages the Asynchronous Server Gateway Interface (ASGI) technology to perform asynchronous tasks efficiently. FastAPI also validates data using Pydantic, ensuring that incoming requests meet the required schema, as illustrated in the diagram below.

FastAPI runs on the Uvicorn server, which is an asynchronous web server that uses the ASGI standard to run Starlette applications. Uvicorn acts as a handler — it receives HTTP requests and forwards them to Starlette for processing. FastAPI further enhances Starlette’s routing system by adding built-in data validation and automatic API documentation features.

“When I first started learning FastAPI, it was a bit challenging for me to understand its functionalities, especially since I came from a Java programming background. However, as I spent more time working with it, writing code in FastAPI gradually became easier and more intuitive.
What I found most impressive was its asynchronous nature, which allows it to handle multiple HTTP requests at the same time efficiently. It also performs automatic data validation — if the incoming data is invalid, it immediately raises clear exceptions, which makes debugging much simpler.
Another feature that stood out to me was how easy FastAPI makes it to explore and test application endpoints. It comes with a built-in Swagger UI, where you can view and interact with all your APIs. For example, by visiting http: localhost:8000/docs, you can see a complete list of endpoints available in your application and test them directly from the browser.”

Building a Simple FastAPI Application
Let’s create a basic CRUD API.

Create main.py

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import List

app = FastAPI()

# -----------------------------
# Data Model
# -----------------------------
class Task(BaseModel):
    id: int
    title: str
    completed: bool = False

# Fake in-memory database
tasks: List[Task] = []

# -----------------------------
# CREATE (POST)
# -----------------------------
@app.post("/tasks", response_model=Task)
def create_task(task: Task):
    for t in tasks:
        if t.id == task.id:
            raise HTTPException(status_code=400, detail="Task already exists")
    tasks.append(task)
    return task

# -----------------------------
# READ (GET ALL)
# -----------------------------
@app.get("/tasks", response_model=List[Task])
def get_tasks():
    return tasks

# -----------------------------
# READ (GET ONE)
# -----------------------------
@app.get("/tasks/{task_id}", response_model=Task)
def get_task(task_id: int):
    for task in tasks:
        if task.id == task_id:
            return task
    raise HTTPException(status_code=404, detail="Task not found")

# -----------------------------
# UPDATE (PUT)
# -----------------------------
@app.put("/tasks/{task_id}", response_model=Task)
def update_task(task_id: int, updated_task: Task):
    for index, task in enumerate(tasks):
        if task.id == task_id:
            tasks[index] = updated_task
            return updated_task
    raise HTTPException(status_code=404, detail="Task not found")

# -----------------------------
# DELETE
# -----------------------------
@app.delete("/tasks/{task_id}")
def delete_task(task_id: int):
    for index, task in enumerate(tasks):
        if task.id == task_id:
            tasks.pop(index)
            return {"message": "Task deleted"}
    raise HTTPException(status_code=404, detail="Task not found")

Understanding Docker
Consider Docker as a warehouse robot. Before Docker, workers (like traditional “dockers”) had to carry and manage each package separately, which was time-consuming and inefficient. After the introduction of Docker, every package is packed into standardized containers, making transportation and management much easier and reducing manual effort.

Docker is based on two key concepts: images and containers. To understand this, think of an image as a blueprint of a house, and a container as the actual house built from that blueprint. You can create as many containers (houses) as you want from a single image (blueprint), ensuring consistency across all environments.

Now, let’s create the project file structure.

Note: The .gitignore and README.md files are not essential for this setup, so you can skip creating them.
_

How I Added a FastAPI Application to Docker
If your system does not have Docker pre-installed, you can install it from the official documentation here:
https://docs.docker.com/desktop/setup/install/windows-install/

For now, I am installing Docker on my local system. However, you can follow the same procedure to install it on a central server as well.

Creating a Dockerfile

Create a file named Dockerfile or dockerFile(no extension):

# 1. Base image (Python)
FROM python:3.10-slim

# 2. Set working directory
WORKDIR /app

# 3. Copy requirements file
COPY requirements.txt .

# 4. Install dependencies
RUN pip install --no-cache-dir -r requirements.txt

# 5. Copy project files
COPY . .

# 6. Expose port
EXPOSE 8000

# 7. Run FastAPI app
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Requirements File Create requirements.txt:

fastapi
uvicorn

Build and Run the Docker Container
Step 1: Build Image

docker build -t fastapi-app .

Now, open the Docker Desktop UI. You will see the image you created listed in the “Images” section, as shown below.

Step 2: Run Container

docker run -d -p 8000:8000 fastapi-app

Open your browser and go to http://localhost:8000/docs/ . You will see the output as shown below:

Final Thoughts
What started as a small idea turned into a major improvement for our team.

Key Takeaways:

Docker eliminates repetitive installations
FastAPI makes backend development fast and efficient
Centralized deployment saves time and effort
Clients can access applications easily via browser

Closing Note
Sometimes, the best solutions are not complex — they just require a shift in thinking.

Instead of asking:

“How do we install this everywhere?”

Ask:

“How can we run this once and access it everywhere?”

That question changed everything for me — and it might do the same for you.