{~,~}

How I Approach Engineering Problems

My approach to engineering is shaped by frameworks that prioritize clear thinking over immediate execution. I learned early that the hardest part of software isn't writing code, it's making sound decisions under uncertainty.

How I Think

Software engineering, to me, is not primarily about writing code. It’s about making a series of decisions under constraints.
Early in my journey, I was trained in an environment that emphasized thinking over output. At DeepThought, the core belief was simple but demanding: we don’t need more workers; we need problem-solvers who can think and take ownership. That idea shaped how I approach technical problems to this day.

Before reaching for a solution, I try to understand the problem at its most fundamental level - what is the core issue we are trying to solve? What are the constraints and trade-offs?
Only then do I consider possible approaches.

The Principles I Use

Over time, a small set of principles has become my default way of working:

  • First Principle Reasoning: Breaking problems down to fundamentals before building up solutions
  • Design Thinking: Solving problems and anchoring innovation keeping user needs at the forefront
  • Socratic Questioning: Challenging assumptions to reduce ambiguity and improve clarity
  • The Feynman Technique: If I can't explain it simply, I don't truly understand it
  • Reflection Rituals: Learning deliberately from both success and failure

These are not abstract ideas to me - they shape how I debug, design, and collaborate.

This Thinking, Applied

On the DIU Transport App

While working on a university transportation system, I treated vehicle tracking not as a UI feature but as a real-time synchronization problem. From first principles, this led to choosing WebSockets over polling and using caching to reduce unnecessary load. The architecture emerged from understanding constraints rather than copying a pattern.

On the Eco App Backend

When the admin panel took 10 minutes to start, I used Socratic questioning to dig deeper than “it's slow.” I discovered a configuration error in the deployment pipeline. This wasn't just fixing a bug—it was about questioning the assumption that “deployment scripts just work.”

On Mentoring

When mentoring junior developers, I often ask them to explain concepts back to me. This approach, inspired by the Feynman technique, helps reveal gaps in understanding and builds confidence through clarity rather than authority.

Where I'm Focusing Now

I started with full-stack development using the MERN stack, which gave me early exposure to building and shipping production software. Over time, I became more interested in the backend decisions that shape system behavior under load, failure, and scale.
Today, I'm intentionally deepening my expertise in backend architecture and system design.

My Focus Areas

  • Backend Architecture: Transitioning to Java Spring Boot to understand enterprise-grade systems, concurrency models, and robust API design at scale
  • System Design: Studying distributed systems patterns not as abstract concepts, but as tools for making specific trade-offs

I believe the most meaningful engineering challenges exist where technical decisions have real consequences. I want to build systems that don't just work, but work well under pressure.

Leadership as Systems Thinking

I think of leadership as system design applied to people and processes.

  • •A good team is a well-architected system
  • •Clear communication is a clean API
  • •Mentoring is reducing cognitive load through abstractions
  • •Ownership is designing for failure recovery

In teams, I try to create clarity, ask better questions, streamline processes and build structures that help others do their best work. My focus is less on being the loudest voice and more on making decisions understandable and reversible where possible.

What I'm Still Learning

I'm still early in my journey. I haven't seen every kind of system fail and I don't claim to have all the answers. That's why I'm deliberately studying distributed systems, backend internals, and architecture—not to collect knowledge, but to sharpen my decision-making over time.

Currently, I'm focused on:

  • •Mastering JVM internals and Spring Boot's design patterns
  • •Understanding database performance at scale
  • •Building intuition for distributed systems trade-offs

What excites me is not how much I already know, but how clearly I can see what I still need to learn.

Problems That Demand This Thinking

I thrive in environments where:

  • •Ambiguity is high - problems aren't fully defined yet
  • •Technical decisions have consequences - architecture matters
  • •Learning is systematic - not accidental nor forced
  • •People prioritize understanding why before deciding how

If you're building something that requires both deep technical execution and clear thinking about trade-offs, I'd love to hear about what you're working on