What Software Architects Do That Programmers DON'T

How does being a software architect differ from a typical programmer? In this episode, I share the 10 aspects I've approached software architecture from that I learned over 20 years of doing it.

I was promoted to be a software architect at just 20 years old, and while I was qualified with some aspects of software engineering - I didn't really know what I was getting myself into. Being a great software architect takes a variety of skills that a typical software developer will also benefit from, but are actually essential to software architecture.

Yes, using coding patterns, knowing how to interview as a software architect, and making technology selections are required. But there are also other things that if you don't focus on, can hamper your ability to pursue a software architect role either at your current job, or the next one.

I hope this episode helps you understand that while there is some overlap between a software architect and a programmer, the less "fun" aspects of the job are actually essential to being a really great one.

Get free access to TechRolepedia here:

Download my free Career Guide here:

Need help with your career? Learn about career coaching:

CHAPTER MARKERS

0:00 Introduction

0:51 10 Aspects of Being a Software Architect
1:03 1. Zoom In / Zoom Out
2:17 2. Domain Sensitive
3:07 3. Understand Tradeoffs
4:02 4. Selfless Decision Maker
5:02 5. Embrace Change
5:44 6. Communicative Mastery
6:26 7. Infrastructure Aware
7:40 8. Strategic Coder
8:50 9. Consider Scale
10:28 10. Cost Sensitive

11:49 Episode Groove

#softwarearchitecture #programming #softwaredevelopment

[HealthyDev]

Do you agree or disagree with these aspects of Software Architects? What other aspects are important?


Chapter markers / timelinks

0:00 Introduction

0:51 10 Aspects of Being a Software Architect
1:03 1. Zoom In / Zoom Out
2:17 2. Domain Sensitive
3:07 3. Understand Tradeoffs
4:02 4. Selfless Decision Maker
5:02 5. Embrace Change
5:44 6. Communicative Mastery
6:26 7. Infrastructure Aware
7:40 8. Strategic Coder
8:50 9. Consider Scale
10:28 10. Cost Sensitive

11:49 Episode Groove

[simonedwards]

That is a solid list. One big item which is missing is "Saying No".

"No. We don't need to rewrite that in Go. It works fine the way it is."

"No. We should not write our own authentication server. Just use a 3rd party."

"No. This feature the Product Owner wants doesn't fit the product and we will never get the bugs out of it if we try."

"No. We our current DB is fine. Just leave it alone We would need 10x more users before it even became an issue."

[KarlHenryMartinsson]

I have been developing professionally for 30+ years, and I am currently in a systems architect role. I think the list is spot on, those are all very important skills to have in this role. Knowing how to push back on the client/stakeholder is also an essential skill.

[Rcls]

My first job as a software architect fell into the first trap you mentioned: I was simply a developer with a fancy title. And nobody else in the entire department cared about architecture, besides the head of the Ops team. I left the company as I saw no opportunity to grow any further, and the Ops team head became the lead architect in the company.

Good books to read on this topic:
- Just enough software architecture (risk driven design)
- Fundamentals of Software Architecture
- Clean Architecture
- The Software Architect Elevator
- Domain-Driven Design
- Building Microservices

All of these taught me something. As an architect you sell options. Different solutions. You are a good communicator. Know that people will challenge your decisions. Office politics play a part in this. Learn the architecture ilities. Some upfront design to any project is okay. DDD gives you another perspective into designing code.

Then you can slap in a few DevOps + Agile books in there to understand continuous improvement and iterative development, and spread those ideas around.

[TheEvertw]

Something I would add is that a great Software Architect takes a risk-driven approach to coding, i.e. he will be aware of the technical and other risks surrounding a project and try to nail the biggest risks down first. That means that he will do performance and scalability tests early in the project if that is expected to be an issue, or mock-up user interfaces to verify their design with actual users, or make a proof-of-concept, design-space exploration, etc, etc, etc. In systems design, he will be aware that the plans other teams make have risks in them and help them nail their risks as quickly as possible. For example by mocking a robot's control software so that it can be put through a realistic movement scenario early on in prototyping.

A colleague of mine did that to find that a vacuum pump was under-dimensioned, something that would have put the project back several months had it been discovered later on.


(note that "he will make" usually means: "he/she will let the team make")

[sndgamingchannel]

Enjoying your videos man.

Realizing I've been doing lots of different job roles under my one job role is a bit of an eye opener.

[nivrith]

Love your guitar tone!
Very insightful video as usual.

[queenstownswords]

Test-ability: A big one that is often missed. How a tester will test the solution and/or its parts is important for rapid releases and the bottom line. If the solution lends itself to automated vs manual testing is also an important consideration.

[BrianReindel]

Speaking as a software architect, you did a fantastic job summarizing the responsibilities. One thing I'll add is the ability to deconstruct abstractions presented by the business, and use them to create concrete requirements for senior devs. I know a lot of very talented engineers who recognize the architect role is not for them because of that. It's the "just tell me what you want" vs. "I'll help you decide what you want" mentality.

[prinselijkcoder]

Interesting how strongly material and human costs feature in this video and your recent one on tech stacks. It feels like that's one of the aspects of leadership that's easily overlooked in technical roles?

[StarRaven]

You are incredibly on point here, all of it is so true. I have been an architect for 8-10 years now, and you just listed all the things I do without knowing them. Good work 😊

[thomasjaeger]

From my many years being an architect, this was great advise and can confirm of what you listed. Thank you for making this video and I hope many will learn from it.

[Stalker-ofbn]

The list is without a doubt a good one. It's hard to have each skill individually (I'm not talking about all 10 at the same time, and certainly not at 23 years old). But as a reference point (like a road map), it is very useful. In fact, all these skills are the result of a high level of awareness when meta-knowledge about knowledge emerges.

[forlooplogic]

Another great video. Your content is down to earth and always relatable.

[shahindohan]

When I was an architect I found myself having to ironically fight against developers using different design patterns that brought 0 value to the project. The most notorious one was CQRS. I hate seeing that pattern used so often when it's NOT NEEDED!!!!

But honestly I wasn't a great architect, mostly a coder with more responsibility and desicion making power about libraries and patterns... I did enjoy the role though.

[chimmy]

This has been the best explanatory video that describes the role and expectations of an architect, of all the videos i have seen so far. I am aspiring to be one and since I am not in a tech field yet, this video really sets the tone and bar for me.

[techforserious]

First one you listed is a golden nugget as far as im concerned, I have had that problem so many times before, I'm the dev that is too bogged down in the details, many times i've paid the price for it, I've put too much importance on some small thing I was working on when the bigger picture barely even required it

[qingyuhu]

The thought process/ability to zoom in and out of any part of project is very well said. Also the ability to map the project end to end or from business process to fine technical details/solution, plus the ability to simplify everything to as simply as possible.

[RichardTammar]

This is a great list. I think the only thing I would expand upon is an awareness and sensitivity to how both requirements and context will change over time. Engineers are often inclined to focus on building new things and think less about maintenance costs and ongoing QA processes... over the course of my career, I feel the costs of standing still have skyrocketed, given our growing dependency on evolving third-party libraries, frameworks, and APIs...

Though I thought that this is how every experienced software engineers operate, one important thing I'm missing is that they are good at asking questions and they dare ask questions. My experience is that a lot of times people don't ask enough questions. Sometimes because the answer seems obvious (i.e. they think they do know the answer), somtimes because they think that they should know the answer so it would look bad, etc. But, in my experience, more often than not, at least one out of 5-10 such questions will result in a answer or it will point out that the other party (say the stakeholders) are not really sure themselves maybe haven't even thought about that specific issue. (BTW, it works pretty well outside of software as well.)