C# / .NET developer
Based in Lebanon, Indiana.
I was involved with IT and print operations at Hachette Book Group, where I proactively
started building tools to address shortcomings of legacy systems. What started as scripts became
full applications that ran in daily production. I came out of a full-stack coding
bootcamp, then picked up C#, PowerShell, Sybase ASE, and PowerBuilder
to match the team's stack.
I am currently looking for a developer role, ideally in the Indianapolis
area.
A printer-agnostic print spooler built from scratch. A REST API and Blazor Server dashboard that queues print jobs, delivers them to network printers over IPP, pushes live status to the browser with SignalR, and logs a full audit trail of every job. Printers are discovered over mDNS and picked up at runtime.
Each printer gets its own monitor with its own cancellation token, so one stalled printer never blocks the others. After a crash, unfinished jobs are re-checked against the printer and marked failed if completion can't be confirmed. Verified end to end against a physical printer.
A terminal application built for Hachette Book Group, releasing carton label print jobs in its distribution warehouse and watching them through to completion. It splits the release file, distributes the pieces across five label-rendering instances, tracks every file with folder watchers, retries failures, and can be cancelled and rolled back cleanly mid-run.
A C# rebuild of an earlier PowerShell script written by an IT staffer. I talked through the original logic with its creator and read the script myself to confirm the new version's output matched before building on it, keeping the same workflow while adding more readable code, a clearer live monitor built with the Spectre.Console library, and a Teams summary posted after each run as a record that it ran.
Built for Hachette Book Group, generating shipping labels roughly 300 times faster than BarTender, the commercial software we used, measured on the same production hardware. Builds printable label pages from order data and sends PCL directly to printers over raw TCP on port 9100. Templates are JSON, with layouts positioned on a normalized 0 to 100 scale, and pre-rendered elements are cached so they aren't regenerated. Built for the 4-up layout. Rewritten from PowerShell to C#, roughly doubling throughput.
Demoed as a proof of concept for print-on-demand. A 15,000-label release that took about 40 minutes through BarTender would render in about 10 seconds, so labels could be generated when the floor needs them instead of pre-generated in bulk.
While building it, I found the format's documentation didn't say which of the 100 data fields each label type actually needed. I started a tool to analyze a year of real files and classify each field as required, often used, optional, or never used, so a production version could validate input properly.
Running four industrial printers already took the print operator's full attention, watching for jams, page misalignment, and toner that wasn't curing properly. Operators also had to find files by hand across several waves and label types at once, reprint by Ctrl-F'ing to a line range without breaking the label order, and hand-log paper counts on paper, then again into a spreadsheet.
PrintFlow is a terminal app for monitoring, queuing, lookups, reprinting, and logging label print jobs. Files are picked by number, supporting single, list, range, or wildcard input, and queued to multiple printers at once. Reprints go by header or by label range, with the order auto-corrected, and it logs paper counts, user actions, and which printer each file went to.
Multiple print operators used it daily. It replaced several disconnected manual steps with one tool and let them focus more on the job they're actually paid to do.
Here's how PrintFlow actually handles all of that:
Queue: files are listed as
#. waveNumber.waveType labelCount and picked by single number, list
(1.2.3), range (1-5), wildcard, or combos of those. Bad input is caught and returned
as a plain English error. Once files are picked, one operation runs on all of them:
select a printer and send (or pick more files first), split a file into two even
files, clone it, delete it, or exit and reset the selection. Sending drops you into
monitoring, which runs on a persistent pipe server that keeps going even if you
close the program. Ctrl-Q clears any selection and returns to the main menu from
anywhere.
Reprint: by header (start header to end header) or by label (start to end label number, auto-correcting the order if you go over or back), plus a search step and a "today's labels" option for pulling different sections from a single wave.
Also: splitting a wave across two printers, cloning, deleting, an auto-archive on submit, a CSV log of paper counts, a generic user-action log, and a printer log of which files went where.
PrintFlow didn't unify everything into a single interface. A full rebuild aiming for that was planned but never shipped. There were plenty more improvements planned beyond this. If you're curious what I was working on, feel free to reach out or send an email.