My work has spanned both ends of the scale, and each end teaches something the other
cannot. Enterprise infrastructure, where a change to a shared system has a blast
radius and you learn to respect it. Small and mid-sized businesses, where there is
no layer between you and the client who needs the answer, so you gather the
requirement, build the pipeline, and present the result yourself.
I spent four years in an enterprise environment on infrastructure monitoring and
incident response, and the data engineering around it: thresholds and event-driven
alert routing on the detection side, telemetry pipelines and dimensional models on
the side that turned resolved incidents into failure patterns. All of it through an
on-premise to hybrid AWS migration. Since then, systems integration, ETL pipelines,
BI reporting for leadership, and freelance application development.
The through line in my work is system design. Good architecture has less to do with
knowing services than with asking what tradeoffs you are making with a decision, and
being able to answer. Reliability against cost. Simplicity against flexibility.
Shipping now against unwinding it later. There is rarely a correct answer, only one
that fits the requirement in front of you, so I reach for the smallest thing that
meets it rather than the largest thing that impresses. I treat those decisions as
revisable rather than permanent, and let telemetry rather than my own opinion tell
me when one needs revisiting. The habit came from presenting technical decisions to
leadership and non-technical stakeholders, who were never going to accept "because
it is best practice" as an answer.
Lately I have been pointing that at generative AI and machine learning workloads,
in Go, Python, and Terraform on AWS. MLOps is the direction I am headed. I am an AWS
Certified Developer, studied computer science at Vanderbilt University and cloud
engineering through the AWS Cloud Institute.