$ cat about_me.md
# personal origin, learning model, and engineering under stress
I build software not to demonstrate syntax, but to eliminate operational friction in real-life workflows. I operate as an Executor: someone who identifies structural pain, learns what is required to fix it in record time, and builds systems that survive production pressure.
My journey began in Mid June 2025. I did not enter software engineering through academic theory or textbook exercises. I entered because I was surrounded by broken, chaotic everyday processes that nobody was fixing.
My university batch was managing critical course schedules, drive links, and notices across fragmented WhatsApp groups and lost bookmarks. Rather than waiting for someone else to build a portal, I sat down and built IPE-24 Classroom. It was my first real project, launched directly into production for 60+ daily users. Seeing immediate real-world utility made me realize that software isn't about code—it's about building operational order out of chaos.
In a very short time frame, my focus evolved rapidly from writing isolated UI scripts to architecting full-stack, multi-tenant SaaS platforms like LogBook and Tutors Hub.
As my projects expanded, I realized that building for scale requires a complete shift in mindset: moving from simple CRUD endpoints to strict Row Level Security (RLS), multi-tenant isolation schemas, offline-first data sync engines, and deterministic business logic. Every project I undertake pushes me deeper into backend infrastructure, data boundaries, and system design.
I am an Extremely Fast Learner because I skip tutorial hell entirely. I don't spend weeks watching passive videos; I learn by reading raw documentation, inspecting open-source reference implementations, and building immediately under real constraints.
When I need to pick up a new technology—whether it's Go, Spring Boot, Supabase RLS, or Redis—I dive directly into its architecture, understand its core memory and data models, build a working prototype within hours, and deploy it to production. I learn by breaking things, reading full error stack traces, and fixing the underlying mechanics.
Root-Cause Diagnosis: I refuse superficial symptom patches or silent error catchers. When a system fails, I trace the data pipeline to find why the underlying contract was broken. A bug is never just a mistake; it's feedback about an incomplete system boundary.
Calm Under Fire: When a production system breaks or deadlines loom under heavy stress, panic is useless. I operate with methodical calm: I isolate the broken component, analyze empirical logs, form a diagnostic hypothesis, verify it with isolated tests, and ship a permanent fix. Stress to me is simply a sign that the stakes are real, and real stakes bring out my sharpest work.