Embedded mindset
Designed around timing, interfaces, observability, and failure modes from the start.
Reliable software for systems that cannot afford ambiguity
I build avionics and embedded software with the debugging discipline to make complex systems behave.
Embedded and avionics engineer working across Ada/C flight software, root-cause analysis, and practical AI tooling that helps real engineering teams move faster without losing rigor.
- Ada
- C
- Flight software
- Root-cause debugging
- Local AI tooling
What I bring
Technical seriousness, clear judgment, and execution that holds up under constraint.
Debugger’s instinct
Comfortable tracing issues across layers until symptoms become evidence and evidence becomes a fix.
Useful AI tooling
Focused on repeatable workflows that help engineers search, document, and execute with less friction.
Capabilities
Range that feels coherent because it all starts with systems thinking.
The common thread is not just what I build. It is how I reason: understand the system, reduce ambiguity, and produce something dependable.
Safety-critical engineering
01
Deterministic avionics software with respect for timing, interfaces, and reliability.
I am strongest when software has to behave predictably and the cost of ambiguity is real. That means disciplined interfaces, careful tasking, and implementation that respects the system around it.
- Ada/C implementation for embedded and avionics-oriented systems
- Attention to deterministic behavior, maintainability, and integration boundaries
- Comfort operating in systems where verification matters as much as velocity
Selected Work
Proof framed around engineering thinking, not just feature lists.
These are intentionally written like case studies: context, contribution, and why the work mattered.
C-130T flight management software contribution
Contributed to avionics software in an environment where correctness, predictability, and clean interfaces are non-negotiable.
- Worked in Ada/C code paths shaped by deterministic scheduling expectations
- Built understanding around how software behavior interacts with larger aircraft systems
- Strengthened instincts for disciplined change-making in reliability-focused environments
Self-hosted RAG and local AI workflows for technical knowledge
Built practical AI-assisted workflows that make engineering information easier to search, recover, and apply without outsourcing sensitive context.
- Designed around usefulness for technical work rather than novelty
- Focused on retrieval quality, local control, and day-to-day repeatability
- Treated AI as an engineering interface problem, not a branding exercise
Reusable debugging playbooks for embedded and integration-heavy teams
Translated troubleshooting into a repeatable process so teams can move from symptoms to verified root cause with less guesswork.
- Codified investigation patterns around interfaces, runtime signals, and assumptions
- Improved scannability and consistency in issue triage
- Made debugging a transferable method instead of a heroic one-off effort
Technical Depth
For people who want to go one layer deeper, the details are here.
This section is designed to reward curiosity without forcing every visitor through dense technical writing on first pass.
Repeatable diagnosis
A debugging workflow built to reduce ambiguity quickly.
My default debugging pattern is simple: build a model of the system, instrument the boundaries that can falsify that model, isolate the failure mode, then verify the fix under the same conditions that produced the issue.
01
Start with signals, not stories. Symptoms are clues, not conclusions.
02
Reduce the search space by checking interfaces, assumptions, and timing boundaries.
03
Leave behind better observability so the same class of issue is easier to diagnose next time.
How I Work
Calm execution for technical work that rewards rigor.
The goal is not to sound intense. It is to be dependable when the environment is complex and the details matter.
Model the system first
Before changing code, I want a clean mental picture of the constraints, interfaces, and likely failure surfaces.
Instrument what matters
I prefer evidence-producing changes over blind iteration, especially in integration-heavy or timing-sensitive environments.
Fix the cause, not just the symptom
Good debugging reduces repeat incidents and leaves behind a clearer system than the one it started with.
Ship with discipline
I like work that can be explained, verified, and maintained by the next person who has to touch it.
Evidence
Signals of credibility, presented like evidence instead of a loose pile of links.
This section gives a visitor multiple ways to validate depth, seriousness, and fit without making the page feel like a document dump.
GitHub
Code and active builds
Explore public repositories, experiments, and implementation work.
github.com/hrcomazingTechnical Notes
Depth without clutter
Use the technical depth section above as a guided entry point into how I think about systems, interfaces, and tooling.
Jump to Technical DepthResume
Detailed history available directly
For teams evaluating fit, I can share a resume and fuller project context on request.
Request resume by emailCurrent Focus
What I am sharpening now
- Deterministic tasking patterns and reliability-oriented design
- Diagnostics for integration-heavy bus and interface ecosystems
- Local-first AI agents for engineering search and documentation
Contact
If you need someone who can think clearly in systems-heavy work, let’s talk.
I’m especially interested in embedded systems, avionics, high-reliability software, and practical AI tooling that supports real technical teams.
hrcomazing@gmail.com
GitHub
Recruiter, engineering manager, founder, or technical collaborator: a concise note with your context is enough.