Greg Duffie

About

Greg Duffie

I've been working in SQL Server, infrastructure, and web services for over 20 years. That time spans healthcare, legal e-discovery, direct marketing, and banking — the kind of breadth that comes from doing real work across real industries rather than staying in one vertical long enough to only understand one set of problems. Right now I'm embedded with Fresenius Healthcare through Randstad Digital, serving as the lead SQL Server architect and developer for scheduling software that coordinates care across more than 2,500 dialysis clinics nationwide.

I watched this industry develop from the beginning — the shift from on-premises everything to cloud, from mainframe to client-server to distributed, from waterfall to agile to whatever we're calling it this year. That history informs how I think. When you understand why architectural decisions were made the way they were, you develop better instincts about what holds up over time and what's going to be expensive for whoever comes next.

I'm not interested in climbing a ladder, accumulating titles, or attending meetings that exist to demonstrate that meetings are happening. I'm interested in doing good work and being trusted to do it — and two decades of that approach has served me well.

Outside of client work, I run sqltesting.com — a consulting and content site focused on tSQLt unit testing and SQL Server CI/CD pipelines. It exists because the resources I wanted didn't, so I built them. That's how most of my projects start.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability.”

— John F. Woods, comp.lang.c++ newsgroup, September 1991

How I Work

I communicate directly, but running a client-facing business for 20 years has taught me that directness and tact aren't opposites. Hard news lands better when it comes with context and a path forward. You'll get a clear picture of what's broken and why — framed as a consultant, not a complaint.

I write things down — runbooks, decision rationale, enough context that the next person isn't starting from zero. Not exhaustively, but thoughtfully.

I don't need weekly check-ins to stay on task or accolades to stay motivated. Clear goals and the latitude to make decisions — that's the environment where I do my best work. If something is blocked, I'll surface it. Otherwise, assume it's in progress.

I keep things simple on purpose. Not because I can't handle complexity, but because I've cleaned up after people who confused complexity with competence. The John Woods quote above isn't a joke I'm using as a rhetorical device — it's a principle I actually work by. The best code I've ever written is the code that made the next engineer's job easier. That's the goal.