Helping 60K+ Developers Improve .NET Skills and Craft Better Software | Microsoft MVP | Technical Lead
Developers think Software Architects have the easiest highly paid job. Well... not quite 👇 Here's what devs imagine an Architect does: - Doesn't write code - Draws diagrams all day - Just makes decisions in meetings - Gets to choose the "cool" tech stack - Always says "yes" or "no" with confidence - Doesn't have to deal with bugs - Works only 4 hours a day - Has a high salary But here's what actually happens: - Writes the core code everyone else will build on - Spends hours reviewing pull requests for critical changes - Explains the same architecture to 5 different teams - Balances business needs with technical debt - Makes trade-offs nobody will be happy about - Deals with production issues at 2 AM - Handles conflicting opinions from stakeholders - Documents decisions so future devs understand why - Manages tech stack upgrades without breaking things - Tracks performance, security, and scalability risks - Mentors developers while staying hands-on - Negotiates scope and timelines under pressure - Reads endless RFCs and framework updates - Constantly defends architecture choices with data - Stays accountable when things go wrong - Learning new things each week to keep up with changing technology Being a Software Architect is rewarding — but it's far from easy. It's not just about drawing boxes; it's about owning the outcomes. What's the biggest misconception you've heard about Software Architects? — ♻️ Repost to help others learn about Software Architect role ➕ Follow me ( Anton Martyniuk ) for more
- Owning uptime and speed targets (and living with the numbers). - Saying “no” with receipts: cost, risk, impact. - Designing how teams work together, not just services. - Cutting cloud costs without killing velocity.
"Makes trade-offs nobody will be happy about" - what should nobody be happy about the tradeoffs?
Biggest misconception is not realizing that being at that position means living with the choices made and then trying to continue the development resisting urge to rework everything :) Writing software from scratch is much easier then understanding the current state of a system, that got there over the years of decisions.
If an architect isn’t still writing some code, they lose the respect of their dev team. Boxes and arrows are useless if you can’t jump into thee codebase when it matters Anton Martyniuk
Hah, as an architect the only thing I say with confidence is "it depends" :P
I would expect anybody calling them self senior developer, would be able to do this.
I once worked with a Software Architect who gave me advice I still carry with me: 👉 “Stay close to both the codebase and the business. If you don’t understand the business, you can’t design a good architecture.” He never treated architecture as just drawing diagrams he was deeply involved in the code and always tied decisions back to business needs. That mindset shaped how I see architecture today.
Speaking as someone who spent years as a senior developer and is now living the role of an architect, I can totally see where that simplified view comes from. Before stepping into the role, I also thought it would be mostly about picking technologies and drawing nice diagrams. But reality hits differently. The shift in perspective is huge. What surprised me the most was realizing it’s not just about code or isolated technical decisions, but about connecting all the dots: business, team, technology, and the long-term vision of the system. Very often, the challenge isn’t writing the best solution, but negotiating deadlines, dealing with conflicting opinions, and still keeping the team motivated. And honestly, I still write code, but the weight of the decisions is very different now, because any wrong choice can affect a lot of people.
How can I be the guy on the left?
Simplifying System Design
2moFor me, the hardest part of software architecture isn’t picking tools, it’s making trade-offs where there’s no perfect answer. Every decision has a cost.