Tools I've actually shipped

A multi-stage job search pipeline that turns job board noise into signal. It uses custom adapters for common ATS systems to pull job posts, based on a registry of desired companies and what ATSes they use. It normalizes the posts into a common format, using a hash function for deduplication and idempotent database upserts. It then sends new postings to the Anthropic API, so an LLM can score them scoring against a pre-written candidate profile and salary floor. Finally, it stores the roles in SQLite and sends a daily email with a ranked digest of roles, including numerical 1-10 scores for fit and career risk.

Inspired by Dan Vacanti's work in his Actionable Agile Metrics series and When Will It Be Done?, I set out to implement these concepts in a web app teams could use in their day-to-day syncs. By the end, it offered four different types of flow visualizations, all drawn from live Azure DevOps data:

• The classic Cycle Time Scatterplot of all work done in a given timeframe, along with 50/70/85/90 cycle time percentiles.
• A Cycle Time Swarmplot where teams can compare active work to the same historic cycle time percentiles.
• Monte Carlo simulations forecasting the amount of completed work over an iteration, a Program Increment, any arbitrary due date, or any arbitrary quantity of work items, all with 50/70/85/90 percent forecast confidence lines.
• Both mean- and median-based XmR Statistical Process Control charts for Cycle Time, total Work Item Age, and daily throughput.

The Cycle Time and Monte Carlo pieces of this application were the centerpiece of a 45-minute talk I gave at exp.oCon 2026, Expeditors' annual innovation conference, called Ditch the Points; Look at the Data! Probabilistic Forecasting for Predictable Delivery.

One night, Chef broke. It started spewing old versions of my team's code across random production servers around the globe, bringing freight to a grinding halt. I was on call, and it was awful. Because the only way to find the state of a given server was to go to a very specific URL for that particular server to show its status. There were 150+ servers. The next morning, after the smoke had cleared, I started writing a Flask dashboard that queried those individual URLs automatically, aggregating status across all 150+ production and pre-production servers into one view with near-real-time visibility, so on-call engineers could stop hunting page-by-page in the dark and get instant situational awareness.

My team was responsible for mapping hundreds of data fields from legacy COBOL and DB2 applications into a new medallion architecture in Databricks. On top of this, the Databricks Silver layer would be an entirely new data model designed from scratch to more accurately describe the process of shipping freight. This produced a knotty problem where different fields from different places in the legacy DB needed to be mapped to Silver, in the priority that business needed them. I took the YAML files my colleagues were writing to do the mapping and turned that data into a simple Flask dashboard. It showed not only the details of what the mappings were, but also a used a not-null-vs-total count to show the percentage of Silver fields that had been successfully mapped. Because it ingested directly from the source data, it gave senior leadership a daily up-to-date view of "how far along are we?" based in ground truth.

Related to two other efforts, but worth calling out on its own. My Statistical Delivery Forecasting tool and the Mapping Progress Dashboard initially lived on small on-prem Linux VMs. As I got ready to give my exp.oCon presentation, I was worried about the ability of a small VM to absorb 200+ attendees all trying to hit it at once. An architect basically dared me to set my two webapps up as Azure Container Apps instead of on-prem ones. This turned into a journey of teaching myself GitHub Actions (we were migrating off GitLab), Azure Container Registries, Azure Container Apps, Azure App Gateways, and how to tie all that together under the hood in the cloud. By the end, I had set up all required resources and coordinated with the Networking and Datacenters teams for IP address space, hub-and-spoke VNet peering, and DNS assignments for two custom vanity URLs in the company's internal URL format, so nontechnical users wouldn't be intimidated trying to find them.

My first foray into improving processes through code. I wrote Python code to access the Azure DevOps REST API and automate common housekeeping tasks. Moving active work items to the current iteration, activating parent items whose children were active, and sending emails when items might need to be closed. I started writing it in 2018 shortly after joining the company and getting my bearings, and it was an ongoing project for my entire tenure. It started out as a pile of scripts on a random on-prem Windows VM that was all I could get. Over the years, I hosted it in GitLab, ported it to RHEL 8, and moved it to GitHub and Azure. By the end, it was a fully containerized small cloud-native application with its own CI/CD pipeline, authenticating against its own managed identity in Azure and using the Microsoft Azure DevOps Python libraries. A true microcosm of my own technical learning and growth.

As an outgrowth of my Admin Bot work, I started exploring the idea of automating required software change requests, which were hosted as Azure DevOps work items. My team used a SharePoint list to host required QA approval documentation, so I created a Python tool that polled our build environment for both the latest prod release and the one staged for deployment, scraped Azure DevOps for all work items identified with the version numbers of the upcoming release, then used a template to take the information from those work items and build a QA approval document in SharePoint via the Graph API. Then I wrote more code that would close out the QA approval in SharePoint, create a Change Request in Azure DevOps using the work item info, and send a QA approval email to the required addresses. I hooked all this up to a GitLab pipeline so QA testers could simply push a button to trigger a "Create QA docs" job, then push another button to trigger a "Create Change Request" job.

As a side project, given my company's interest in tracking freight and the availability of IoT devices to give GPS location, I decided to use my personal HoloLens 2 to explore the idea of holographic freight tracking. I used the Bing Maps API and the Mixed Reality Toolkit in Unity to develop a prototype map display which showed pins on a holographic map with item locations. Air tapping on those items showed details about the object. This could have been extended via access to streaming location data in order to show the live location of an object holographically. It wasn't accepted as an idea; I still have access to the code since I worked up the prototype on my own time on my own personal gear. I later pitched the idea of QR-based holographic freight tracking and warehouse navigation to a VP, but this also did not gain traction.