Understand the Problem First
I do not start with a framework just because it is familiar. I start by understanding what is happening and what needs to change.
Multi-tool software engineer
From Components to Code
My technical career started with physical electronics and troubleshooting, then grew into software, cybersecurity, cloud and distributed systems, full stack development, automation, and AI.
I learn and use the tools required to solve the problem.
One engineering story
The Tools Changed. The Mindset Stayed.
I have spent my career learning how systems work, troubleshooting problems, and building practical solutions.
Curiosity started with physical things
Before software became the main tool, I was interested in electronics and how individual components worked together. I liked taking a system that felt complicated, following the connections, and figuring out why it behaved the way it did.
The Navy made troubleshooting practical
My military technical experience included component-level electronics troubleshooting, understanding interconnected systems, working through faults methodically, and solving problems with my hands. It reinforced a habit I still use: observe the system, narrow the problem, test an idea, and keep going until the behavior makes sense.
Boeing continued the hands-on work
I later worked as a Boeing technician. That kept me close to physical systems and the practical side of technical work. The details of the systems changed, but the need for care, persistence, and methodical troubleshooting remained.
Moving into software required a new toolbox
The progression from physical systems to software systems took significant self-learning, practice, and persistence. Instead of only tracing components and signals, I learned to trace data, dependencies, services, user actions, and code. Software gave me new ways to build solutions, but the underlying problem-solving process still felt familiar.
Microsoft broadened the kinds of systems I work with
My Microsoft experience has included software engineering, cybersecurity, full stack engineering, distributed systems, cloud systems, automation, and AI. I have worked across backend services and user-facing experiences, choosing tools based on the problem instead of treating one framework or language as the answer to everything.
The career story is continuous: learn how the system works, find the failure or friction, and build something useful with the tools the problem requires.
Engineering mindset
How I Work
A practical process matters more to me than loyalty to one language, framework, cloud, or specialty.
Follow the System
Inputs, outputs, dependencies, failure points, users, and constraints usually reveal where the real problem lives.
Use the Right Tool
The technology should serve the problem. I learn and use what the solution requires.
Make Repetitive Work Easier
When a safe automation can remove unnecessary manual work, I would rather engineer the process than repeat the task forever.
Keep Learning
Tools change constantly. The ability to learn, test, and adapt is part of the engineering work.
Engineering breadth
Areas I Work Across
This shows the kinds of systems and product surfaces I have worked with. It is not a claim of equal depth in every tool.
Backend and Systems
APIs, backend services, console applications, distributed systems, cloud systems, data workflows, and automation.
Frontend and Product
Web applications, user interfaces, user experience, full stack development, React, and TypeScript.
Mobile
Experience working with Swift, iOS, and Android technologies as part of a broader engineering toolbox.
Cloud
Azure, AWS, backend services, APIs, data workflows, and the practical concerns of connected systems.
AI
AI agents, Retrieval-Augmented Generation, RAG, Cache-Augmented Generation, CAG, and AI-assisted workflows.
A restrained list of tools
- C#
- .NET
- Python
- TypeScript
- React
- Swift
- Android technologies
- Azure
- AWS
I am familiar with additional tools and languages, and I learn others when the work calls for them.
Featured work
Problems I Have Built Around
The useful story is the problem, what I built, and why the solution mattered.
Public project
FacetVibe
A public project you can visit and experience directly online.
FacetVibe is publicly accessible. I keep the description focused on what can be verified through the working project instead of inventing audience, growth, feature, or architecture claims.
Visit FacetVibeMoteThing
A personal hardware and software project I designed and built from scratch, connecting the hands-on and software sides of my engineering story.
Personal build
Hardware and Software Still Belong Together
MoteThing gives me a place to keep working where physical devices and software meet. It does not have a public URL yet, so the page does not present a broken or invented destination.
Internal engineering tools
Building Away Repetitive Work and Blind Spots
These tools are described at a level that explains the problem and approach without exposing private systems.
internal project
DARTS
A CAG-based request triage system designed to help technical program managers and engineers review incoming requests.
The problem
Incoming requests can be difficult to act on when required information is missing, priorities are unclear, or the same questions need to be asked repeatedly.
What I built
DARTS stands for Data App Request Triage System. I designed and created it as a CAG-based system that helps technical program managers and engineers identify missing information, check whether required information is present, and prioritize requests.
Why it mattered
The system helps reduce repetitive back-and-forth communication and unnecessary manual effort. This is an internal project, so the description intentionally excludes private data, prompts, source code, infrastructure, workflows, and implementation details.
internal project
Synapse Pulse
A pipeline usage, lineage, and status engine for understanding connections and activity across a Synapse workspace.
The problem
Understanding pipeline dependencies, upstream and downstream relationships, status, failures, and possible data-loss context can require manually clicking through many connected pipelines.
What I built
Synapse Pulse is a pipeline usage, lineage, and status engine designed to make those connections and current conditions easier to understand across a Synapse workspace.
Why it mattered
The tool reduced the time required to manually investigate pipeline relationships. This is an internal project, so no private screenshots, customer information, architecture, confidential data, internal URLs, or proprietary details are included.
internal project
Cosmos DB Schema Modifier
A tool designed to support controlled changes across many Cosmos DB documents without editing them one at a time.
The problem
Repetitive changes across many documents are slow and create more room for inconsistency when each document is edited manually.
What I built
I designed a tool to support controlled modifications across Cosmos DB documents and make the update process easier to manage.
Why it mattered
The work turned a repetitive data-modification task into an engineered process. This is an internal project, so the description does not include document counts, schemas, company data, production details, source code, or private infrastructure.
Practical AI engineering
AI Is Another Tool in the Toolbox
My experience includes AI agents, RAG, CAG, augmented AI engineering, and AI-assisted workflows. Adding AI is not the goal by itself.
The useful work is deciding where AI fits, giving it the right context, checking its output, and keeping human judgment where the situation needs it.
Questions I start with
- What problem does it solve?
- What information does it need?
- How should context be provided?
- How should outputs be checked?
- Where does human judgment still matter?
The larger system
Security, Cloud Systems, and the People Using Them
Technical depth matters, but software is ultimately built to help somebody do something.
Cybersecurity
My professional Microsoft experience includes cybersecurity work. That engineering work is distinct from the community-focused cybersecurity education provided through Tech Teacher.
Explore Tech TeacherCloud and Distributed Systems
I have experience with Azure, AWS, distributed systems, backend services, APIs, and data workflows. I focus on how the parts connect and behave without claiming unsupported scale or performance metrics.
Building for People
Backend systems and frontend UI both exist to support a person or workflow. I try to understand the user's problem, reduce unnecessary steps, and make technical systems easier to use.
Software engineering resume
Resume Publication Pending Approval
The software-engineering-focused resume remains unavailable for public download while its contact information is reviewed for publication approval. There is no broken or placeholder link.
Start with the problem
Let's Talk About What You're Building
Tell me what the system is supposed to do, what is getting in the way, and what you have already tried. We can start there.