Transcript for What Software Architects Do That Programmers DON'T by Jayme Edwards aka Healthy Software Developer.
autogenerated Amazon transcript run through ChatGPT4 for punctuation
Introduction
It's really important, if you're going to be an effective software architect, that you don't let the company you work for push you into being the lead developer on projects or just pitching in anywhere people need help. If you get sucked into writing code for just any old application or any old feature, then you don't have time to really be an architect. Ever wondered what makes a great software architect or how to get promoted to be one? Well, over 20 years ago, at 23 years old, I was promoted to be a software architect, and I messed up pretty bad back then. But, I'd like to think I've learned quite a few things in the 20 years since. So, here are 10 aspects of being a software architect that, if you do them, I think will not only help you increase the chance that you'll get the job, but actually do it really well.
1. Zoom In / Zoom Out
One thing that many software architects are really good at is what I call zooming in and zooming out. I had a manager at my first job right out of college, and after a couple of years of working for him, he saw something in me that told him that I might make a really good software architect. Once he helped me get the promotion, one of the things he told me that really sets people apart as a software architect is being able to look really detailed and deep at the code you're looking at, knowing every single detail of what you're dealing with, and not glossing over things. But then, when you need to, coming way back up and making sure you look at the big picture of what you're doing and not getting bogged down in the details. You'll find many programmers fall into one or the other camp. You'll find programmers that are really good at understanding all the most detailed and difficult parts of some aspect of the code, and others that are really big picture and can really think about the overall solution or architecture as a whole. But to be a really great architect, you need to be able to do both and know when the best time is to do it.
2. Domain Sensitive
The second thing that makes a really great architect is being able to care about the domain. This doesn't just mean domain-driven design, like you've probably heard of in that really famous book from Eric Evans. This actually means caring about the business that you work in and understanding its problem domain. For example, if you work for a company that does shipping, understanding all that you can about how that company looks at shipping, what all the different business systems are at that company, and actually doing a good job of trying to figure out how to represent this problem domain in the software in the best way possible.
3. Understand Tradeoffs
The third thing software architects are really good at, that sets them apart from your average programmer, is they're masters at understanding tradeoffs. What I mean by this is, when you go to select a technology or figure out how to do some deployment aspect of your code, or you're picking an API of some sort, there are often a lot of positives and negatives. Some of the less experienced developers I've worked with will see some really positive aspects of the code but they won't look at everything else that's going to be impacted if they choose that technology. So knowing how to look at all the variables that come into consideration, like training costs, ease of use, configurability, complexity, when you go to make a decision about software technology decisions and patterns and architecture, is one of the biggest things that'll set you apart if you really want to consider becoming a software architect.
4. Selfless Decision Maker
The fourth thing that I think really great software architects do, that sets them apart from, let's say, a tech lead or a lead software developer, is they're very humble about gathering technology decisions. What I mean by this is, some of the people who I've worked with who are not maybe the best choice for being a software architect will go out and find technologies that they really want to work on. They go out and find solutions and patterns and frameworks that they are really excited about working with, but they don't put enough consideration into the rest of the team and the rest of the company. So, a really great software architect, when they go to make decisions about technology investments, knows how to talk to all their team members and knows the history of their team members and the preferences of their team members, and they take that into really strong consideration anytime they're making a technology selection or decision.
5. Embrace Change
The fifth thing that makes a really great software architect is that they embrace change. They know that the decisions they're going to make about technology and the patterns they choose are not necessarily going to stay fixed or work for the entire lifetime of the project. So, they put just enough planning in upfront and enough design to
put some good architecture in place, but they're really realistic in thinking about the fact that once the team, or whoever they're handing that architecture off to, begins to use it, there's a really high likelihood that the decisions they made aren't going to solve every problem and they're not going to be suitable for every use case.
6. Communicative Mastery
The sixth thing that makes someone a really strong candidate for an excellent architect is their mastery of communication. They know how to use diagrams to effectively convey both details or high-level things about the software that they're building. But they also know how to talk to a lot of different audiences: the business people, support people, developers, the CTO, and executives. They know how to communicate the architecture decisions in a way that helps each of those different types of people and each of those audiences really understand what's important to them and not get bogged down in all the details that might not even be related to what's important for them to support the architecture.
7. Infrastructure Aware
The seventh thing that a really strong, great architect knows how to do is to be aware of the infrastructure. They know that when you choose technology to use, eventually it's going to run in a production environment. It's going to have real users hitting that software, exercising it, using it, and they don't think about last whether the technology they picked is going to perform well. They actually consider that at the very beginning. So a really strong architect is usually very interested in DevOps technologies, cloud architecture, and cloud platforms and services, or whatever kind of hardware or software infrastructure is needed to run the application. It's one of the biggest things I see when a programmer does not care too much about that. They may like to choose technology and mess around with frameworks and APIs, but I wouldn't consider them quite yet at the point where they really would make a great architect.
8. Strategic Coder
The eighth thing that a really strong software architect will do is they're a very strategic coder. Now what I mean by that is they don't just write software for any given piece of code that a team or a company needs. They actually protect their time and make sure they don't get sucked into working on features, let's say, for the software. In some of the projects I've worked on as an architect, I'd often come up with patterns or initial code, or initial frameworks, you know, combining stuff together, and give them to a team. And sometimes, along with the documentation and everything else I would provide, I would help that team with a little bit of code to kind of get going. But it's really important, if you're going to be an effective software architect, that you don't let the company you work for push you into being the lead developer on projects or just pitching in anywhere people need help. Because if you get sucked into writing code for just any old application or any old feature, then you don't have time to really be an architect.
9. Consider Scale
The ninth thing a great software architect does is they consider the scale of the application or the services or the company that they're making architecture decisions for. If you're working at a company and they're going to have at most a thousand users if they're really successful in their market, choosing microservices and really sophisticated cloud architectures is actually going to cost that company a lot of money for the return on investment. Not just the money to pay for all the services, but all the engineering thought overhead that everybody has to now grapple with to maintain that application. At the same time, if you're working at a company where they're going to have millions and millions of users, something at the scale of a FANG or just below it, making decisions that are appropriate for getting the code working simply and having a really nice framework to program in, but don't really meet the performance needs of the application, is going to get you in just as much trouble. So whether you're choosing how your app's going to be tested, you're choosing monitoring platforms, you're choosing how to integrate various different libraries together, I think some of the best architects I've worked with, and what I've tried to get at least better at myself, is to know how to ask questions of the business and gather data, let's say from existing business systems, let's say they're rewriting a product or they're introducing a new product but they have existing users, and be able to interpret that data and know what is the true scale that we're expecting to have for this application and how do I actually mimic that before we roll it out to production to make sure it doesn't fall apart once people are using it.
10. Cost Sensitive
The tenth and final thing that really great software architects do is that they're sensitive to costs. Every architectural decision you make has implications for your company's costs. It might cost them in terms of licensing fees, which is pretty obvious if the software costs something. But it also costs in terms of how difficult it is to troubleshoot. They may have to pay, let's say, support engineers more money to support the product for the company. They may have to pay more just for the engineers to develop the software if the development experience is really complicated. They may have to pay for custom work done by outside consultants or third-party firms if it becomes too complicated to integrate. And if you can't figure it out, you may need to hire a really high-paid expert to ensure you can use the technology. So, really great architects, I think, set themselves apart by being realistic about the fact that every technology decision they make is not free.
Do you agree or disagree with this list of what I think is important to be a really great software architect? What are some things about being a great software architect that I haven't mentioned? Leave me some comments and let me know about it. Until next episode!