Why I Chose to Become an Engineer
A reflection on curiosity, problem-solving, building things from first principles, and why turning abstract ideas into working software felt like the right path.
Before writing software or studying distributed systems, engineering began for me as simple curiosity—a persistent habit of taking things apart to understand why they worked, and occasionally failing to put them back together in their original state.
Growing up, I was naturally drawn to systems where cause and effect were deterministic. There was a unique satisfaction in taking a complex mechanism, breaking it down into basic components, and figuring out the rules governing its behavior.
1 / Software as a First-Principles Canvas
Computer science appealed to me because software is one of the few fields where complete systems can be designed, tested, and iterated entirely from first principles. Unlike physical infrastructure with high material costs, software allows instant experimentation: an idea can be transformed into executable code, benchmarked, debugged, and refined within hours.
2 / The Intersection of Logic & Composition
What makes systems engineering compelling is that technical correctness alone is insufficient. Clean code requires structured layout, intuitive interfaces, observable metrics, and maintainable abstractions. Designing distributed services or interactive tools requires balancing computational efficiency with human clarity.
3 / Embracing Failure as a Core Feedback Mechanism
Along the way, the most valuable lesson has been learning to treat failure as feedback. A failing test, a concurrency race condition, or an unexpected edge-case exception isn't a disaster—it's an invitation to understand the system at a deeper level.
Debugging forces you to abandon assumptions and inspect empirical log evidence. It teaches humility, patience, and analytical discipline.
4 / Observable & Understandable Systems
Above all, I believe engineering work should be transparent, inspectable, and reproducible. Code should be clean, setup prerequisites should be explicitly documented, and system behavior should be observable rather than opaque.
Whether designing a hybrid RAG retrieval pipeline or a distributed in-memory cache, I prioritize building mechanisms whose internal state can be inspected and understood. True engineering maturity lies in taking difficult technical problems and building software that is both technically sound and aesthetically compelling.
Ultimately, I chose engineering because it isn't just a profession; it's a continuous practice of showing up, thinking deeply about complex problems, and constantly refining one's craft through real work.