About

I'm Subham Bhattacharya, a backend engineer working mainly in Python and a Computer Science student at BITS Pilani. The parts of a system I care about are the ones that have to stay correct under pressure — APIs, data models, authentication, and the service logic that decides what a system is permitted to do.
Most of what I write is service and pipeline code: Protocols at the interfaces, generics for what moves through them, strict mypy across all of it, nothing computed until something asks for it. I would rather understand one stack deeply enough to defend every trade-off out loud than collect frameworks I have touched once.
I design for the failure case before the happy path. That habit came from four years running a manufacturing operation — production, quality, procurement, finance — where a tolerance drifting means a batch is scrap and a supplier slipping means a line stops. Physical systems teach you quickly that a process which fails loudly is cheap and one that fails quietly is expensive. The ordering carried straight into how I write software.
Graph search and C take up much of the rest of my time, and both changed how I design in Python — one for how I reason about structure, the other for what an operation actually costs. The degree formalises this, with a concentration in computing systems and systems programming.
Longer term I'm building toward AI/ML systems. Serving, data pipelines, evaluation and behaviour under load are infrastructure problems with a harder correctness story — which is exactly the kind of work I want to be doing, and exactly why the foundation matters.
Everything on my GitHub is meant to be read: clean repositories, honest documentation, and projects I can stand behind in a technical conversation.
Before the happy path, I want to know what breaks it, what happens when it breaks, and whether it breaks loudly. A process that fails quietly is the expensive kind.
One stack understood well enough to defend every trade-off out loud, rather than a list of frameworks touched once. Breadth comes after, and it comes faster from a real foundation.
Code and documentation both have a second reader — usually a later version of me. Clean repositories and honest READMEs are part of the work, not paperwork after it.