William Rients, software engineer

Selected work

Work I've shipped

Making a production database cheaper

SQL Server, Query Store, Application Insights, Redis

Monthly database cost down ~40%, with the slowest queries over 100x faster.

Problem: The main transactional database was the biggest line on the infrastructure bill, and the standing answer to slow pages and busy weekends was to buy more capacity. Nobody knew which pages or queries were actually expensive.
Approach: I measured before changing anything. Application Insights showed which pages were hit hardest and loaded slowest. Query Store showed which statements were burning processor time behind them. The two lists overlapped in a handful of places, and a single page turned out to be using about a third of all database processor time. From there the fixes were about doing less work: one query instead of one per row, caching values that were recalculated on every request but changed a few times a day, fixing a query plan regression that had quietly taken over half of all processing, and removing indexes and jobs nothing read. Only then did I scale the hardware down, in stages timed around peak traffic.
Result: The database does a fraction of the work it used to while traffic kept growing. Cost dropped ~40%, the worst queries run over 100x faster, and the same measurements now catch the next regression before it costs anything.

Rebuilding a statistics engine

C#, T-SQL, Redis, Microsoft Fabric, Python

Every statistic updates the moment a play is scored, and players can slice their numbers dozens of ways and see where they stand against their class.

Problem: The platform holds hundreds of millions of plays, and its stats were a fixed set of totals recomputed overnight for whoever played that day. There were two ways to group them, a scoring mistake took a day to show up, and only an engineer could correct it. Nobody could ask a question the system had not already answered.
Approach: I moved the computing to the transaction. As each play arrives it is credited to the batter and the pitcher right then, reprocessing a half inning when a rule depends on how a runner reached base. The nightly job survived, but only for what truly needs the whole picture: career totals, leaderboards, and percentiles against players of the same class year with a comparable sample. Underneath, I stored the data at many grains instead of a few, so any stat can be split by opponent, context or equipment, like a left handed pitcher, a ranked opponent, a pitch velocity range, or a ballpark, and adding a new split is a small change rather than a project. The analytics platform handles the big questions, like how top ranked hitters perform in a given count. I built it end to end: the data model, the formulas, the interface and the tools the stats team uses to fix scoring errors themselves.
Result: The products built on it serve tens of thousands of paying subscribers. A player can now see not just a batting average but what it means: their percentile among peers, whether they are on pace for their class, and how their team controls a game inning by inning.

Standing up an analytics platform

Microsoft Fabric, PySpark, Power BI, Postgres

Reporting moved off the transactional database onto its own platform, fed in near real time, and most teams now answer their own questions.

Problem: Every question about the business was a ticket. Someone emailed a request, an engineer wrote custom SQL against the live database, and the same question asked twice became two reports, sometimes with two different answers. Anyone who could open a report could see everything in it.
Approach: I started the platform from an empty repository and learned the stack as I built it, having only ever written stored procedures for .NET applications. The source databases, the same ones that serve millions of accounts, are mirrored into Fabric in near real time, so nothing reports against production anymore. Pipelines and notebooks clean, deduplicate and shape the raw data into fact and dimension tables once, in one place, so every report starts from the same numbers. On top sit semantic models and Power BI reports with row level security, so one report serves finance, operations and each region while each person sees only what they should. The same platform moves data out to partners and into the sales and marketing team's own tools, so they build their own dashboards instead of asking.
Result: Leadership, finance, operations and sales answer most of their own questions, and reports refresh on their own schedule instead of once a night. The platform became the foundation for the recommendation engine, the statistics rebuild and year over year event tracking, and it is where I learned data engineering.

Recommending events with machine learning

Python, PySpark, Microsoft Fabric

~8% of accounts that click a recommendation go on to register, most of them for an event they had never attended.

Problem: Finding an event meant a long list and a wall of filters: date, region, age group, classification. Families scrolled to the ones they already knew and went back to them, so new events went unnoticed and most of the catalog was never seen.
Approach: The model learns from what people did and what they said. Registrations are the strong signal, recent ones weighted higher, with clicks counting a little and a thumbs down counting against. Events are grouped into series by their year over year lineage, or by sport, type, director and location where no link exists, so a decade of history in one series informs the recommendation for its next event. Distance is scored on a fixed curve whose start is learned per family from how far they have actually travelled. Every candidate is then checked against what matters: is it open, is there room, is this family eligible. Lists regenerate nightly when they go stale, and the model retrains weekly, evaluated on a time based holdout against popularity baselines rather than on the rows it learned from. Before launch, staff compared it blind against a second model on real accounts and picked it.
Result: About 8% of accounts that click a recommendation go on to register, most for events they had never attended, and it serves close to a million accounts. Its honest limit is next season: it knows what a family did, not that a player just aged up, so the eligibility rules do the work the history cannot.

Experience

Where I've worked

January 2026 to now

Senior Software Developer

Lead analytics, statistics and data engineering across the public site, internal tools and partner API. Own the analytics platform and the database. Lead projects across three engineering teams, mentor junior developers and interns, and interview candidates.

September 2024 to January 2026

Software Developer II

Rebuilt online tournament registration and checkout after a contractor led rewrite stopped. Created the analytics platform. Built the recommendation engine, the team ranking system, and the self serve tools operations staff use to set up a season.

September 2023 to September 2024

Software Developer I

Backend services behind the admin tools and partner API. Rebuilt the event day stream monitor into a live broadcast health dashboard. Became the person production issues got handed to.

November 2022 to September 2023

Software Developer Intern

Built an advisory tracking system that is still in daily use, and fixed production bugs across the public site while finishing school part time.

BS, Software Engineering
Western Governors University, 2024

AAS, Software Development
Kirkwood Community College, 2023

AWS Certified Cloud Practitioner
2024

Stack

What I work across

Highlighted items are where I spend most of my time.

Databases

Schema design, query tuning, keeping it fast under load.

SQL Server
T-SQL
Query Store
Azure SQL
Cosmos DB
Postgres
Redis

Data platform

Pipelines, warehousing, modeling, self service reporting.

Microsoft Fabric
PySpark
Power BI
Azure Data Factory
Lakehouse
Dimensional modeling

Backend

Services and APIs that stay up and stay cheap.

C#
.NET
ASP.NET
REST APIs
Caching
xUnit

Machine learning and analytics

Models that ship and get measured.

Python
Recommender systems
Rating systems
Model evaluation

Operations

Production triage, observability, delivery.

Application Insights
KQL
Azure DevOps
Git
CI pipelines

AI tooling

Setup that makes the tools reliable, not just fast.

Claude Code
Codex
MCP servers
Custom skills
Repository rules

Front end

Enough to ship the whole feature.

TypeScript
React
Next.js
JavaScript
CSS

Approach

How I work

Measure, then change

Before a rewrite I want the number that says what is actually slow or expensive. It is usually not the thing everyone assumed, and the measurement is cheaper than the guess.

Example: the database that got 40% cheaper started with measurement, not code.

Fix causes, not symptoms

A patch that makes the alert stop is not done. I keep going until the problem cannot come back, and I say so when my first explanation turns out to be wrong.

Example: two reports disagreeing was not a reporting bug. Every report ran its own SQL, so the fix was one modeled source every report starts from.

Leave a record

Subsystem documentation, status updates, the reasoning behind each change. The next engineer should not have to find me to understand the system.

Example: the statistics engine ships with the subsystem documentation the team works from.

Build the tools around the work

I write most of my code with Claude Code and Codex, and the leverage is in the setup: repository rules that hold the tools to the team's standards, custom skills for the work that repeats, and servers that let them reach the systems I work in. The design, the data and the review stay mine.

Example: skills that triage support tickets, bring an on call engineer up to speed on a product they have never touched, and scope a ticket or a project end to end.

Contact

LinkedIn Resume