About Michael

Context

I design and build software frameworks and libraries that help teams and individuals write correct, maintainable, and expressive code. My professional focus is on framework and API design, where long-term usability, consistency, and correctness matter more than short-term convenience. I care deeply about the shape of software — not just whether it works, but whether it communicates intent clearly and stands the test of time.

I am a strong believer in Framework Design Guidelines (hereafter referred to as FDG) as non-negotiable foundations for sustainable software. Well-designed APIs reduce cognitive load, prevent misuse, and scale gracefully as systems evolve. I apply first principles thinking as a way to understand why these guidelines exist and to apply them deliberately and consistently — not as an excuse to reinvent software design from scratch.

The .NET ecosystem is built on deliberate, well-documented standards taught by Microsoft and codified by the architects behind Framework Design Guidelines. Conventions such as Async-suffixed methods, exception-based error handling, and consistent API model exist to create a shared mental model across the platform.
 
Reusable libraries are expected to uphold these standards—not replace them with personal preferences. Innovation in .NET starts from alignment, not deviation.
 
Framework and library authors carry a responsibility: align with the platform first, innovate only when there is a clear, principled, and defensible reason to do otherwise. Consistency is not conservatism—it is respect for the users of your API.
 
Help promote consistent code and try the ChatGPT version of FDG here: https://chatgpt.com/g/g-682614f060b481918a8b767baf2dd918-framework-design-guidelines

For me, first principles thinking and established practices are not in conflict. FDG, SOLID principles, and architectural patterns such as Onion-/Clean-/Hexagon Architecture are hard-earned conclusions, validated through decades of real-world systems. I treat them as defaults, not suggestions.

Experience at a Glance

I have worked professionally in IT since 1999, spanning multiple technology shifts—from early enterprise systems to modern cloud-native and distributed architectures.

Those years of experience informs how I evaluate trade-offs, recognize recurring failure modes, and apply proven design principles with context and restraint.

My Approach

My work is guided by a small set of core principles:

• First principles thinking — I reason from fundamental truths of a problem domain to validate design decisions and avoid accidental complexity,
• FDG — I advocate for consistent naming, meaningful abstractions, strong typing, and APIs that are easy to use correctly and difficult to misuse,
• Longevity over novelty — I favor designs that remain understandable and valuable years later, even as requirements and teams change.

This combination allows me to make architectural decisions with both rigor and pragmatism, ensuring systems are maintainable, resilient, and clear in intent.

Craftsmanship and Engineering Philosophy

I am described as an architect who combines strong architectural vision with hands-on craftsmanship. My work intentionally bridges strategy and execution, shaping systems that are conceptually sound, pragmatically executable, and built to endure.

Peers frequently characterize me as a guardian of engineering excellence. I place high value on clear standards, explicit architectural boundaries, and development practices that scale across teams and technologies. Through well-defined guidelines, thoughtful reviews, and principled decision-making, I aim to elevate not only individual systems, but the overall engineering maturity of the environments I work in.

A core strength is my ability to bridge architecture and implementation. I translate complex topics—framework internals, system design, tooling, and automation—into guidance that developers can apply in day-to-day work. My architectural decisions balance long-term sustainability with realistic delivery constraints.

Mentorship and collaboration are central to how I influence. I invest time in helping others grow through detailed code reviews, technical coaching, and shared learning. My feedback is direct but constructive, focused on enabling better decisions rather than enforcing authority.

While I hold high expectations for quality and correctness, I pair them with calmness, openness, and respect. I engage confidently in difficult technical discussions, welcome constructive challenge, and stay focused on outcomes rather than ego.

Dogmatic About Principles, Pragmatic in Practice

One peer of mine once described me as being both Neo and Mr. Anderson from The Matrix — and I think that captures my approach well.

I am uncompromising when it comes to core principles: clear boundaries, strong contracts, and proven architectural foundations. These are the rules that keep systems coherent and sustainable. At the same time, I am pragmatic in how those principles are applied. Context matters — teams, constraints, and timelines all influence the right expression of a design.

I aim to understand the underlying rules of a system deeply enough to challenge assumptions when necessary, while still operating effectively within established structures when they serve the goal. This balance allows me to be both principled and practical — firm about what must hold true, and flexible about how it is achieved.

Open Source and Community

I am an active contributor to Free and Open Source Software. I maintain several FOSS projects, all publicly available at:

https://github.com/codebeltnet/

While these projects are not built for popularity, they are built with intent. They serve as a way for me to apply the same standards I advocate and to provide concrete, end-to-end reference implementations for others to learn from and build upon.

Each project is treated as a complete product, spanning the full software development lifecycle: design rationale, API contracts, implementation, testing, documentation, versioning, and long-term maintenance. Consistency, correctness, and adherence to established platform conventions are enforced deliberately and repeatedly.

Taken together, these repositories reflect perseverance in craft rather than pursuit of visibility. They exist to demonstrate what disciplined framework and library design looks like in practice—not just in theory.

Principles are only credible when self-applied.

Tools of the Craft

I am picky about the tools I use. Just as APIs and architectures benefit from strong conventions, so does the day-to-day work of designing, building, and maintaining software.

The tools below are not necessarily endorsements, nor are they immutable choices. They are the instruments that currently best support my standards for correctness, clarity, and sustained productivity.

Some are open source, some are commercial, and several are paid services. I consider that a reasonable and professional investment in craft — no different from choosing high-quality components in any other engineering discipline.

Platforms and Infrastructure

• GitHub — collaboration, source control, and long-term stewardship of open work,
• GitHub Actions — CI/CD pipelines for automated builds, validation, and releases,
• NuGet — distribution and dependency management for .NET libraries,
• Oracle Cloud Infrastructure — experimentation and self-hosted systems,
• Google Cloud — managed services and distributed system primitives,
• Amazon Web Services (AWS) — breadth-first cloud infrastructure and operational maturity,
• Microsoft Azure — cloud-native services tightly integrated with the .NET ecosystem,
• Ghost — a focused, content-first publishing platform with minimal abstraction leakage.

Development, Quality and Engineering

• Visual Studio 2026 — primary environment for .NET and reusable library work,
• Visual Studio Code — lightweight tooling and polyglot workflows,
• GitHub Copilot — assisted coding with human-in-the-loop control,
• JetBrains ReSharper — static analysis and refactoring support inside the IDE,
• SonarQube Cloud — continuous inspection of code quality and maintainability,
• GitKraken — visual clarity for complex repository histories,
• xUnit — for unit and integration testing in .NET,
• BenchmarkDotNet — empirical performance measurement and regression detection,
• Google Antigravity — an AI-native development environment, conceptually similar to VS Code,
• Lens — observability and operational insight into distributed systems.

Creative and Documentation Work

• Adobe Photoshop — visual assets and presentation material,
• ComfyUI — controlled experimentation with generative workflows.

Research and Reasoning Aids

• ChatGPT,
• Perplexity,
• Claude,
• Grok,
• Google Gemini.

These tools are used as thinking partners, research accelerators, and editorial challengers — never as substitutes for judgment or accountability.

Tools shape outcomes. Choosing them deliberately is part of taking engineering seriously.

What I Care About

At the core of my work are a few guiding concerns that shape how I design software, collaborate with others, and evaluate technical decisions:

Systems That Evolve Gracefully

Great design anticipates change. I invest in frameworks and architectural foundations that allow systems to evolve without accruing unnecessary complexity.

Developer Experience

APIs are contracts with developers. I strive to make those contracts predictable, expressive, and aligned with human expectations.

Continuous Learning

Software design is a craft. I continually read, reflect, and refine my approach — learning as much from failed abstractions as from successful ones.

Outside of Code

While software design is a big part of who I am, it’s not the whole story:

• I enjoy science fiction (Star Wars), adventure (Lord of the Rings), and well-crafted comedies (Seinfeld) across both movies and TV shows,
• I appreciate experiencing great storytelling through a state-of-the-art home cinema setup, where sound and image quality matter as much as the content,
• I have a soft spot for DJ BOBO — a reminder that enthusiasm and enjoyment don’t always need justification.

How I Can Help

I collaborate with teams and individuals who want to:

• Elevate their API and framework design practices,
• Build systems guided by principles rather than trends,
• Improve developer experience across the software lifecycle,
• Balance architectural soundness with pragmatic delivery.

If you’re looking for a partner in thoughtful design, clear reasoning, or framework strategy, I’m always open to an async conversation.

Connect

I’m active in .NET and broader developer communities. Reach out if you want to chat about design principles, API ergonomics, or engineering craftsmanship.

Email: michael@rubberdux.dev

GitHub

• https://github.com/rbrdux
• https://github.com/gimlichael
• https://github.com/codebeltnet

A Note on Transparency

This profile was written with assistance from ChatGPT v5.2, Gemini v3 and Perplexity Pro.

The tool served as a collaborative aid for structuring ideas, refining language, and challenging phrasing — comparable to other modern engineering tools. The content, intent, and final editorial decisions remain the responsibility of the author.

Transparency in tooling and process is treated here as a natural extension of good engineering practice.