I am highly opinionated about what constitutes good code. When it comes to software architecture, my views incline heavily toward John Ousterhout’s The Philosophy of Software Design rather than Uncle Bob’s Clean Code.

While I agree with the core SOLID principles for the most part, I tend to diverge from the industry mainstream on strict architecture patterns. You won’t find me introducing heavy boilerplate for the sake of it—I don’t believe in forcing a mandatory ViewModel for every single screen, nor do I think a codebase always needs a dogmatic breakdown of Use Cases and Repositories just to conform to Clean Architecture. Instead, I value pragmatism, deep modules, and reducing cognitive load over rigid design patterns.

To put it frankly, I am obsessed with developer tooling precisely because it helps us ship features faster to real people, and seeing people using the apps I built motivates me after all.

• I don’t build monuments to frameworks: A beautiful, 10-layer abstract architecture means nothing if the app takes six months to ship and users hate the actual product feature.
• Pragmatism over perfection: I would rather ship a working, clean-enough feature today that drives business metrics than spend three weeks abstracting a network request that might change next month anyway.

While many mobile developers enjoy crafting pixel-perfect UI designs or fluid animations, my interests have shifted toward what happens behind the scenes. I am far more drawn to the underlying infrastructure of software development.

Right now, my engineering focus centers on:

• Developer Productivity & Tooling: Building workflow automation, optimizing build systems, and creating tools that eliminate friction for engineering teams.
• Systems Programming & Backend: Exploring niche areas like SwiftNIO, Swift on the server, and low-level system design.
• Infrastructure & DevOps: Learning low-level system mechanics, DevOps practices, and server scaling.

I believe in using tools that promote clean architecture and maintainability without sacrificing performance.

• iOS & Mobile: Swift is my primary language. I can navigate Android (Java and Kotlin) when needed. For cross-platform development, I prefer sharing business logic via Kotlin Multiplatform (KMP) while keeping the UI completely native. I choose not to work with UI-abstraction frameworks like Flutter or React Native.
• Go & TUIs: Outside of mobile, I love working with Go. I use it to build cloud tooling, internal infrastructure, and Terminal User Interfaces (TUIs) for my hobby and internal projects.
• Web Ecosystems: I can write JavaScript and TypeScript if necessary, though it isn’t my preferred stack.

While I am enjoying my current work on a large-scale product, I keep an eye on where I want to grow next. For my future roles, I am looking to transition toward:

• Developer Tooling Companies or specialized Platform Engineering teams.
• Mobile Architect roles focused on foundational architecture rather than features.
• Developer Relations (DevRel) where I can focus on developer experience and engineering ecosystems.
• Scaled product-based companies that value deep technical engineering.