The lie they tell .NET devs about software architecture

Myth:

.NET devs have architects who guide them every step of the way.

Brutal reality?

For many teams, the above statement is a big, fat lie.

Many companies, especially smaller ones, don’t have an official software architect. No design reviews. No architectural planning. No roadmap for evolving the system. But the architecture still happens.

So who does it? The most senior dev in the room. If you are a senior .NET developer, that person is you. Or might it become you.

But here’s the thing:

• As you progress from junior to senior developer, you don’t get promoted for your software architectural skills.
• You get to the senior level by shipping features, fixing bugs, and being a good soldier.

So, once you find yourself in a situation where you need to define system boundaries, manage trade-offs, and think 12 months ahead, you require a different set of skills. Skills that no one has taught you.

You are not a soldier anymore. Blindly following orders.

You become a general. Boldly giving orders.

So, what can you do to become better at software architecture?

1. Learn what software architecture is and why it’s important to you (even though you are not an architect yet).
2. Discover how to analyze client requirements to extract non-functional requirements (scalability, performance, maintainability, security…).
3. Get familiar with the process of building an application from a simple monolith, through a modular monolith, to microservices
4. Research different architectural styles and when to use them.
5. Focus on security and different practices to build production-ready solutions.

But if all of that sounds overwhelming to you, don’t worry.

I’ve started to work on a book, “Zero to Architect: A .NET Developer’s Playbook for Making Confident Software Architecture Decisions”.

This is for you if you are a .NET developer who wants to confidently:

• Design and explain the architecture of a system from scratch.
• Choose the right patterns for structuring the codebase, plan for scalability, and security.
• And have other developers look to you for technical direction.

So you can feel like you finally earned the title of “senior” not just by years, but by impact.

I’ve just started working on the book, but my promise is to cut the fluff and include:

• Lots of practical examples every step of the way
• Tools, techniques, and practices for a better software architecture decision-making process
• Visuals, tables, and other assets to make learning easier
• A practical and story-driven walkthrough of building an app from scratch and evolving it to microservices

If you would like to:

• Know more about the book as I progress,
• Get updates,
• Help me shape it with your feedback,
• And have early access,

You can join my newsletter because I’ll post updates there.

No hard release date yet. But the work is already in progress.

And remember:

If you don’t intentionally design the architecture, one will still emerge. Just messier, slower, and harder to maintain.

It’s time we stop waiting for “the architect” to show up. You’re maybe already doing the architect’s job.

Now it’s time to get good at it.