IT operations / infrastructure / networking
Current roleIT Helpdesk AnalystKansas OITS
At Kansas OITS, I handle support tickets, deploy workstations, write documentation, and troubleshoot hardware and software. My homelab takes that work deeper into networking, servers, storage, and automation.
Kansas Office of Information Technology Services
I manage ServiceNow tickets, support users, image and deploy workstations, document fixes, and escalate high-priority issues.
Hy-vee
Assisted with customer questions and issues, communicated events and deals, and assisted with managing stock
The lab is where I configure hardware, network paths, storage, and the services on top. It gives me room to trace problems across every layer and understand why a fix worked.
Servers, network interfaces, storage devices, and the physical connections between them.
Routing, ingress, and the network rules that determine how a request reaches a service.
Backend services, sessions, file storage, and the dependencies they need outside the codebase.
Deployments, logs, health checks, and the routine work required to keep a system understandable.
HunterMCProductions is one example. The homelab and the systems behind it are the larger body of work.
HunterMCProductions is one place this work shows up. I built its shared account layer, sessions, permissions, file tools, and the connections between its private services.
I work on the servers, network paths, storage, and service runtime behind the applications. The homelab makes those layers part of the same project instead of somebody else’s abstraction.
I use logs, health checks, and direct inspection to trace failures across application, data, network, and hardware boundaries. The goal is to fix the cause and make the next problem easier to find.
A slow query can become disk pressure. A bad upload path can fill a volume. A network rule can look like an application bug. Working in the homelab lets me follow those problems down to the machine instead of stopping at the first error.
Hands on / hardware layer
The first successful request proves the happy path. The real work starts after that: watching how the system behaves, tracing failures, replacing weak assumptions, and making the next fix easier than the last one.
Follow the problem across application, data, network, and hardware boundaries.
Fix the cause, document what mattered, and avoid hiding the failure behind retries.
Use what broke to simplify the system and make its next failure easier to understand.
Tools matter because of the problems they solve. These are the ones in the current system.
If you have a system to build, a network to untangle, or an idea that needs both, send me a note.
