C# / .NET developer Based in Lebanon, Indiana.
I was involved with IT and print operations at Hachette Book Group, where I started proactively
building tools to address short comings of legacy systems. What started as scripts became
full applications that ran in daily production. I taught myself C#, PowerShell, and
PCL by building them, and learned Sybase ASE and PowerBuilder
working alongside the team's senior developer.
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. It keeps the same workflow, with more readable code, a clearer live monitor, and a Teams summary posted after each run as a record that it ran.
Imagine working as a server at a busy, high-end restaurant that has a POS system, but a dumb one. You keep a notepad to track your tables, which items each customer at a table ordered, and which items are done and ready to serve. You have to type in each item by hand instead of picking it from an available-items list. If you mistype one, the kitchen doesn't guess what you meant. The only way you find out is once the order goes to the table and the customer complains something's missing. If something needs to be remade, there's no clean way to resend just that one item. You dig up the original order and copy out just the item they want remade. Then you resubmit it, praying you only grabbed that one thing and nothing more. At the end of the night, you have to manually type into the POS every unique item ordered, which tables ordered it, and how much of it each table ordered.
PrintFlow is like finally getting a real POS. It tracks your tables, what's been ordered, and what's already done, so none of that lives in a notepad anymore. Items get picked from an actual list instead of typed by hand, so one never quietly goes missing. Need to remake something? Pick just that one item and resend it, with the right range grabbed for you automatically, instead of copying it out by hand and hoping you only pulled that one thing and nothing more. And every item ordered, by table and quantity, gets tallied automatically instead of retyped by hand at the end of the night.
This not only helped me but other operators as well. PrintFlow was praised for making a fast, high-pressure job less stressful by simplifying the software operators interacted with everyday.
Running four industrial printers already took the print operator's full attention, watching for jams, page misalignment, and toner that wasn't curing properly. On top of that, operators had to find files by hand across several waves and label types running at once. Reprinting meant Ctrl-F'ing to a line range without breaking the label order. And paper counts were hand-logged on paper, then again into a spreadsheet.
PrintFlow is a terminal app for monitoring, queuing, searching, 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. It also logs paper counts, user actions, and which printer each file went to.
Multiple operators used it daily to queue, monitor, reprint, audit, and look up print jobs. It replaced several disconnected manual steps with one tool and let the operator focus more on the job they're actually paid to do.
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.
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.