Patterns I Keep Returning To
These are the working habits, behavioral patterns, and loops that explain why I build the projects I build.
01.I value simple questions over master plans.
CampuGrid didn't start with a multi-page design document. It started because I was looking at my own setup and couldn't stop asking: 'Why are thousands of consumer GPUs sitting idle while cloud instances remain expensive?' The entire project grew out of trying to answer that single question, not from a predetermined plan to build a distributed scheduler.
02.Virtualization was a black box I had to take apart.
I didn't set up a Proxmox homelab because I needed local file hosting. I built it because virtual machines, LXC namespaces, virtual switches, and Tailscale segment routing were abstract concepts I had only read about. I needed to configure the physical hypervisor, route the subnets, and break the bridges to understand how logical networking layers translate to hardware.
03.Immutable operating systems change how you treat your workstation.
I didn't install Fedora Silverblue because it was trendy. I installed it to see if a read-only filesystem root could change my relationship with maintaining a development environment. Running toolboxes taught me that isolating workspaces inside rootless containers is far more stable than trying to debug system-level package conflicts on a host machine.
04.LLM context is a finite resource that must be managed like physical memory.
Building context-pilot was a reaction to watching AI coding agents waste thousands of prompt tokens on redundant code imports. I wanted to understand if we could treat LLM context limits like hardware registers—responsibly compressed, pruned using tree-sitter AST queries, and managed like limited memory pools.
05.Real software is complex because human organizations are messy.
Spending six months building the OBE platform for Thapar Institute taught me that business software isn't difficult because of complex algorithms. It is difficult because institutional regulations, course attainment matrices, and academic exceptions are highly messy. The developer's job is to write software that absorbs that messiness without reflecting it in the architecture.
06.I almost never stop at 'it works.'
Once a query executes or a container runs, my immediate reaction is to ask: Why? Can I prove it? What happens if I pull this system plug? Optimizing raw SQL grouping queries or debugging tree-sitter byte offsets is about wanting to know exactly where execution spends its bytes under pressure.
07.I have to fight the tool to understand the documentation.
Books and manuals make sense to me only after I've broken a system. I learn by building things slightly beyond my current understanding, running into a wall, and debugging the runtime errors. Fought experience is what makes technical documentation click.