I've always been drawn to how things work underneath — not just that something is slow, but why it's slow. Not just that data moves, but what happens to it along the way. That instinct to dig until I find the real answer is what pulled me into software engineering, and it's still what keeps it interesting.

How I think about backend

Think of a restaurant. The frontend is the dining room — how the menu looks, how the food is presented. I work in the kitchen. Who supplies the ingredients, how they're stored, how everything gets assembled into something that actually lands on the table. That's backend: managing the flow of data, keeping it secure, reducing friction at every step.

I didn't choose backend because frontend was too hard. I chose it because the architecture is where the real decisions live. How do you move data without losing it? Where does the system break under pressure? What's the actual trade-off between this approach and that one? Those questions are what I find genuinely interesting.

How I work

When something breaks or slows down, I profile first. Logs before assumptions. If the logs don't explain it, then I zoom out and think about the architecture. I try not to jump to conclusions — or to solutions.

Clean code to me means as few moving parts as necessary. No unnecessary dependencies. No microservices where a monolith does the job. Easy to read, easy to delete. If someone has to read your code and think too hard, something's wrong.

Where I am now

Since December 2024 I've been at LG Sinarmas, building manufacturing MES systems in partnership with LG Energy Solution and LG CNS. Production-critical systems where correctness matters more than cleverness.