About
Cloud, data, and platform engineering with a systems mindset.
My work combines cloud architecture, data engineering, and platform discipline. The strongest thread across it is a preference for full systems: infrastructure, networking, identity, ingestion, transformation, orchestration, serving, and the operational habits that keep all of it healthy.
Profile
What I build.
I build data platforms with real operating boundaries: cloud foundation, networking, storage, transformation, orchestration, analytics serving, and the delivery discipline that keeps the whole system healthy.
The work I enjoy most is full-platform work, not isolated pipeline tickets. That has meant building an AWS enterprise data platform repo by repo, then carrying the same standards into GCP through identity, governance, and environment design in a second cloud.
I also care a lot about clarity. Strong systems should be maintainable by other engineers, explainable to stakeholders, and documented well enough that the next person can extend them safely.
Snowflake, BigQuery, Redshift, Databricks, Athena, AWS, and GCP
Python, SQL, Terraform, PySpark, dbt, Kafka, Airflow, Streamlit, FastAPI
Principles
How I approach engineering work.
Make data boundaries real
Bronze, Silver, and Gold should mean something operationally, not just visually in a diagram.
Treat delivery habits as architecture
Branches, CI/CD, environment separation, and least privilege are part of the system design.
Build once, configure carefully
Reusable logic and explicit inputs beat environment-specific drift and hidden shortcuts.
Leave the system easier to understand
Good docs, naming, and structure reduce future mistakes and raise team speed.
Working style
How I like teams and systems to operate.
The strongest engineering environments make good decisions easy to repeat. Clear architecture boundaries, predictable workflows, and documentation that lowers confusion are part of the product.
Think from infrastructure to user outcome
The strongest platform work connects identity, data movement, transformation, governance, and the final analytics experience.
Prefer calm operating models
Clear ownership, explicit workflows, reliable deployments, and cost awareness are part of good engineering, not process overhead.
Optimize for maintainers as well as builders
If the next teammate cannot reason about the system quickly, the design is still incomplete.