Technical depth
Years of experience across C#/.NET, SQL Server, APIs, web applications, integrations, production systems, and legacy modernization.
ABOUT RINGERWORKS
Experienced enough to know code isn't the whole job.
I'm Marianne Ringer, the software developer behind RingerWorks.
I build, maintain, modernize, and troubleshoot business software — with an emphasis on understanding the problem before deciding what technology belongs in the solution.
THE PERSON BEHIND RINGERWORKS
Hi. I'm Marianne.
I've spent much of my career building, maintaining, troubleshooting, and improving software that businesses depend on.
My work has included business applications, databases, APIs, integrations, web applications, legacy systems, and the kinds of production problems that occasionally make perfectly reasonable people stare suspiciously at their monitors.
I've worked both on new development and inside existing systems where the answer isn't simply "start over." I enjoy learning how a system works, understanding why it was built the way it was, and finding a practical path from where it is to where it needs to be.
Over the years, I've found that the best technical solution usually starts somewhere decidedly non-technical: understand the people, the process, the constraints, and the actual problem first.
Apparently my preferred hobby is staring at something that isn't working and refusing to let it win.
WHAT I BRING TO THE WORK
More than writing code.
Good development requires technical skill, but it also requires judgment, curiosity, communication, and the willingness to understand a system before changing it.
Practical judgment
Not every application needs a rewrite, every problem needs a framework, or every good idea needs another layer of abstraction.
Problem solving
I like tracing problems across application, database, API, and integration layers until the actual cause makes sense.
Communication
Software exists to support people and organizations. I work comfortably with both technical teams and the people who simply need the system to do its job.
HOW I APPROACH THE WORK
A few things I believe.
Understand before building.
The fastest way to build the wrong thing is to start solving a problem before understanding it.
Complexity has to earn its place.
A clever solution isn't necessarily a good one. Technology and architecture should be as complicated as the problem requires — and no more.
Details matter.
A query, validation rule, integration edge case, or seemingly harmless assumption can have surprisingly large consequences.
Useful beats impressive.
The goal isn't to show off the tools. It's to create something that works well, makes sense, and continues to be maintainable.
OUTSIDE THE IDE
Curiosity tends to follow me home.
I tend to like things that reward patience, experimentation, and learning how they work.
When I'm not writing software, I'm often reading, making something, repairing something, learning something new, or disappearing down a rabbit hole because I wondered how something was done.
This occasionally results in the acquisition of tools so specialized that explaining why I own them takes considerably longer than using them.
HAVE A SOFTWARE PROBLEM TO SOLVE?