From Microns to Microservices: Why I Traded Dental Drills for C#
How 6 years of physical precision in dental technology shaped my approach to software architecture, type safety, and error handling.

The 50-Micron Margin
In the world of software, if you miss a semicolon, the compiler yells at you. You add it, hit save, and the problem is gone.
In the world of dental technology, there is no backspace. There is no Ctrl+Z.
For six years, my life was defined by the gap between a ceramic crown and a plaster die. The industry standard for a "perfect fit" is a marginal gap of less than 50 microns. For context, a human hair is roughly 70 microns thick. If my work was off by the width of a hair, the restoration was a failure.
If I ground away too much material, an expensive block of Zirconia was trash. If I left it too bulky, a patient somewhere would feel pain every time they bit down.
This environment instilled in me a zero-defect mentality. When I sit down to write code now, I don't just "hack it until it works." I look at a function signature the same way I looked at a dental impression: Does this fit perfectly? Is the foundation solid?
In dental tech, you cannot hide a bad foundation with a shiny glaze. In software, you cannot hide bad architecture with a pretty UI. The discipline of physical precision gave me an obsession with clean code, strict typing, and robust error handling long before I knew what a "Stack Trace" was.
The Scalability Problem
Despite the satisfaction of crafting perfect restorations, I ran into a wall that physics wouldn't let me break: Scalability.
Dental technology is manual, linear work. If it took me one hour to design and finish a unit, doing ten units took ten hours. There were no for loops to automate the contouring of a molar. My output was strictly bound by my physical time.
But the bigger problem wasn't the manufacturing; it was the management state.
Our lab was processing hundreds of cases a week, managed entirely by paper tickets and whiteboard scribbles. It was a distributed system running on analog hardware (paper), and it was failing.
- Race Conditions: Two technicians reaching for the same pan, causing delays.
- Data Loss: Paper prescriptions getting wet or lost in the plaster room.
- Latency: Clients calling to ask "Is my case ready?" and us spending 15 minutes physically hunting for it.
I realized that while I was great at the micro (making the tooth), the macro (the system) was broken. We didn't have a talent problem; we had an architecture problem.
I started looking for software to manage this workflow, but everything on the market was clunky, expensive, and rigid. That’s when the realization hit me: I know the domain better than any developer. Why don't I build the system myself?
I traded my handpiece for a keyboard, and I began architecting Oscar Lab.
Hello, C#
I didn't start with Python or JavaScript. I started with C#.
To many self-taught developers, C# feels heavy and verbose. But to me, coming from a world of rigid physical constraints, it felt like home.
In dental tech, materials have strict properties. You can't mix Zirconia with Lithium Disilicate; they are chemically incompatible. If you try to force them together, they shatter. C#’s type system felt exactly like that.
csharppublic class DentalCase{ public Guid Id { get; } public string PatientName { get; } public DateTime DueDate { get; } // The compiler prevents me from assigning a Date to a Name. // It prevents "structural failure" before the product ever ships.}
When I discovered that the compiler would stop me from making "structural" mistakes before the code even ran, I was hooked. It was the safety net I never had in the lab.
I dove deep into WPF (Windows Presentation Foundation). I loved the separation of concerns—XAML for the UI (the aesthetics) and C# for the logic (the framework). It mirrored the dental process: the metal coping provides the strength, and the porcelain layering provides the beauty. You need both, but they are fundamentally different layers.
Building "Oscar": Domain-Driven Design
My first major project wasn't a Todo List or a Weather App. It was Oscar Lab Management, a full-scale enterprise resource planning (ERP) tool for our laboratory.
Without knowing the academic term for it at the time, I was practicing Domain-Driven Design (DDD). Because I was the domain expert, I wasn't just guessing at requirements; I was modeling reality.
I mapped the chaotic physical workflow into a relational database schema:
- The "Pan": Became the
CaseIdentity. - The "Stations": Became a State Machine (
Received->Designed->Milled->Finished). - The "Technician": Became a
Userentity with role-based access control.
The challenge wasn't just storing data; it was handling offline state. The lab had spotty internet in the plaster room, but technicians needed to scan barcodes to update case status instantly.
I architected a solution using SQLite for local caching and a background worker to sync with the central SQL Server when connectivity was restored. This was my crash course in distributed systems, conflict resolution, and the CAP theorem—solved not because I read a textbook, but because the business required it.
When we deployed Oscar v1.0, the "latency" of finding a case dropped from 15 minutes to 3 seconds. That was the moment I knew: I am no longer just a technician. I am an Engineer.
The "Undo" Button
The most intoxicating part of my transition to software was the discovery of the Undo button.
In my previous life, a mistake was a catastrophe. If I slipped while grinding a margin under the microscope, that was it. The case was ruined. I had to call the doctor, apologize, and ask for a new impression. It cost money, time, and reputation.
Software is forgiving in a way physical matter is not.
I remember writing my first Unit Test. The idea that I could write code to test my code—simulating thousands of scenarios in milliseconds without wasting a single gram of material—felt like a superpower.
I embraced CI/CD (Continuous Integration / Continuous Deployment) aggressively. In dental manufacturing, "deploying" a case meant physically shipping a box via FedEx. If it was wrong, it came back in a box three days later.
Now, "deploying" meant pushing a commit. If Oscar.exe crashed, I could push a hotfix in 10 minutes. This feedback loop was addictive. It allowed me to take risks, refactor aggressive architecture changes, and optimize performance without the fear of permanent failure.
I realized that Senior Engineering isn't about not making mistakes; it's about building systems that make mistakes recoverable.
Conclusion: The Architect's Mindset
Today, I build distributed cloud systems instead of ceramic bridges. I wrestle with race conditions instead of occlusion contacts.
But the mindset hasn't changed.
The precision I learned under the microscope is now the precision I apply to my database schemas. The obsession with "fit" is now an obsession with clean API contracts. The need for a solid foundation is now a need for scalable infrastructure.
I am a System Architect. My background isn't a traditional CS degree, and I consider that my greatest asset. I don't build software for the sake of code; I build it to solve the messy, chaotic, high-stakes problems of the real world—because I’ve lived in it.
Whether I'm designing a microservice architecture or a dental crown, the goal remains the same: It has to work, it has to last, and it has to fit perfectly.