Who I am

declaration — technical identity, not a biography

Not a biography — a technical identity. What follows is how I work, evidenced elsewhere in this repository.

↳ mostly opinions about who's allowed to own what

I'm a software engineer whose career has evolved from implementing frontend interfaces to designing distributed systems. I don't optimize for the number of technologies I know; I optimize for understanding why systems are built the way they are.

I enjoy problems involving architecture, distributed systems, developer experience and frontend engineering.

engineering philosophy

Good engineering is mostly about decisions, not code. I treat every system as a set of claims that must stay true over time, about ownership, consistency, and who is allowed to compute what. When those claims are implicit, systems drift; when explicit, they stay correct.

This knowledge base is written the way I believe engineering should be documented: context, constraints, alternatives, decision, trade-offs. Never just the output.

career evolution
Today
Platform engineering, architecture and AI-assisted development
Interested in the systems that make other engineers faster and safer.
2025
Designing distributed systems
Dynamox. Cross-service consistency, event-driven architecture, ownership.
2024
Building frontend systems
Design System, component architecture, 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
Start from invariants. Before designing, I write down what must never be false, then choose the architecture that makes violations impossible rather than unlikely.
Prefer boring correctness. A provably correct system beats a clever one, even when the clever one is faster to build.
Make adoption the easiest path. Standards, design systems and processes only survive when following them is less work than ignoring them.
Decisions are documents. If a decision isn't written down with its alternatives, the team will re-litigate it in six months.
strengths
  • —Cross-service consistency and data ownership design
  • —Turning implicit team knowledge into explicit standards
  • —Component architecture and design systems
  • —Written technical communication
  • —End-to-end ownership: proposal to implementation to adoption
preferred problems
  • —Systems where multiple services disagree about the same fact
  • —Teams that ship fast but can't explain why things are built the way they are
  • —Frontend codebases that need architecture, not more components
  • —Workflows where AI can assist without removing human judgment
currently into
Distributed SystemsSoftware ArchitectureDeveloper ExperienceAI-assisted EngineeringPlatform EngineeringTechnical LeadershipEngineering DocumentationKnowledge Management
“The goal isn't to collect technologies. The goal is to understand how to make good engineering decisions.”