In May 2026, I spent time turning scattered project history into clearer documentation.
On the surface, that looked like a batch of case studies, profile material, and organizing work. But the more interesting outcome was that the pattern underneath the work became easier to explain.
I have never fit neatly into one professional category. Some of the projects documented that month involved live event production. Some involved instrumentation and data collection. Some involved communications systems, procurement, or physical environment problem-solving. Put side by side, they made something obvious that is easy to miss when the work is spread across years and contexts:
I do some of my best work where technical systems, operational constraints, and human communication all meet.
The Throughline Is Not A Single Tool
One part of the May documentation pass focused on work from Missouri S&T, especially around the Light and Sound Committee.
That included live front-of-house sound engineering across roughly 45 performances and events, from small rooms to audiences in the thousands. It also included the less glamorous but equally important work around that environment: reading technical riders, configuring systems, troubleshooting in real time, training other people, and keeping the whole operation reliable under pressure.
It also included work that was adjacent to the stage but just as important to the system itself.
I documented the marketing collateral I designed to make the committee legible to the campus it served. Brochures, flyers, event posters, and pricing materials were not side tasks. They were part of building an operating system that people could understand and use. If people do not know a capability exists, it is functionally the same as not having it.
I also documented a capital purchase proposal that helped secure better equipment through a formal university funding process. That project was not really about buying gear. It was about translating technical needs into a business case, showing return on investment, and making a complex request understandable to decision-makers.
That combination still feels representative of how I work now:
build the thing, explain the thing, and improve the system around the thing.
Systems Thinking Shows Up In Very Different Environments
Another set of May updates made clear that my engineering work has never been limited to one domain.
One project used LabVIEW and CompactRIO to collect high-accuracy measurements for a solar thermal electric panel experiment. Another used low-cost ESP8266 hardware, Nginx, Aurora, and Tableau to demonstrate that devices could still be fingerprinted through WiFi probe behavior even when MAC addresses rotated. Both projects lived in different worlds, but the method was similar:
instrument the environment, collect useful data, make the behavior visible, and use that visibility to answer a real question.
That pattern matters to me more than any individual technology choice.
The tools change. The operating posture does not.
I like work where there is a messy system, an unclear signal, and a need to turn scattered behavior into something observable enough to reason about. Sometimes that looks like a data acquisition pipeline. Sometimes it looks like security research. Sometimes it looks like debugging a workflow that nobody has properly named yet.
Practical Problem-Solving Includes Physical Systems Too
The May updates also included projects that were more physical and situational, including experiments around airflow and cooling at Magnolia.
That kind of work is easy to underestimate because it does not always look like traditional engineering on paper. But I see it as the same discipline expressed in a different medium: understand the constraints, prototype within cost limits, measure what changes, and improve the system without pretending the first answer has to be perfect.
In that case, the work was about testing a lower-cost approach to a real comfort and HVAC problem before a larger system change happened later. I have a lot of respect for projects like that. They reward curiosity, observation, and practical iteration more than polished theory.
Documentation Is Part Of The Capability
The most important update from May may have been the simplest one: a clearer definition of what this body of work is for and how it should be maintained.
What I want from documentation is not bureaucracy. I want continuity.
If work only exists in memory, scattered files, or one person’s head, it becomes fragile. It becomes harder to explain accurately, harder to build on, and harder to connect to new opportunities. Good documentation does not just preserve facts. It makes judgment reusable.
That matters even more now that AI tools can help transform, summarize, and reorganize source material. If the underlying record is vague, the output will be vague. If the source material is specific, structured, and grounded in real work, it becomes much easier to produce something useful for a website, a proposal, a conversation, or a collaboration.
What This Month Made Clear
What the May 2026 documentation pass clarified for me is that the common thread in my work is not a single title like engineer, marketer, operator, or strategist.
The common thread is that I am usually trying to make a system more legible and more effective.
Sometimes that means running live sound with no room for failure. Sometimes it means writing the materials that help other people understand a capability. Sometimes it means building instrumentation, testing a physical environment, or proving something with data that was previously only intuition.
The labels matter less than the pattern.
I like stepping into situations where the technical layer, the communication layer, and the operational layer are tangled together, then helping make them clearer, steadier, and more useful.
That is what May helped me see more cleanly. Not that the work was broad, but that the breadth was coherent all along.