Who I am

how I work

The examples on this site say more than a list of strengths could. Here are a few patterns in how I approach the work.

↳ usually starts with who controls the data

At Dynamox, I work on tools for industrial inspection. A change can touch the screen an inspector uses, the API behind it, and copies of the same data in other services. I try to understand that whole path before deciding where a fix belongs.

Some work starts with an architecture decision; some starts with a report that a number looks wrong. In both cases, I test my explanation against the system's behavior and make the trade-offs clear enough for other people to challenge.

engineering philosophy

When several services hold a version of the same fact, the hard question is which one gets to change it and how the others catch up. A clear rule at that boundary can prevent a lot of special cases later.

I write down the alternatives and the reasons for a decision. That gives the team something concrete to review, revisit, or use when a similar problem comes up.

career evolution
Today
Full-stack engineering at Dynamox
Product-facing features, backend architecture, and data that has to stay consistent across services.
2025
Designing distributed systems
Dynamox. Cross-service consistency, event-driven systems, and decisions that span the stack.
2024
Building frontend systems
Design System, reusable frontend components, standards the team adopted voluntarily.
2023
Building production frontend applications
Frontend Intern at AQTech. Vue, real users, real constraints.
2022
Learning professional software development
Freelance work under an experienced engineer. Git, code review, delivery discipline.
how i think
Before changing production behavior, I want to know what the data says—and whether my way of measuring it is sound.
If two services calculate the same value, I look for one place to do the calculation and a clear way for the others to catch up.
For asynchronous work, I ask what the system can honestly promise now, and what happens if later processing fails.
When a decision crosses team boundaries, I write down the trade-offs before implementation so people can question the boundary while it is still cheap to change.
strengths
  • —Tracing a data change across interfaces, APIs, consumers, and stored copies
  • —Finding where a shared rule belongs across services
  • —Building frontend flows alongside the APIs and data models behind them
  • —Writing decisions so teammates can review the reasoning, not just the conclusion
  • —Taking a feature from problem framing through rollout
preferred problems
  • —A value that changes depending on which service or screen you ask
  • —A useful feature slowed down by data spread across a large hierarchy
  • —A production discrepancy where the first explanation does not fit the evidence
  • —A workflow that needs to keep working when a request or message fails halfway through
currently into
Distributed SystemsSoftware ArchitectureFrontend EngineeringDeveloper Experience
“Before I fix a system, I want to understand what it promises—and whether it keeps that promise.”