1:4 - Tools, Domain, and the Architect's Role!

You are listening to diverse software engineers podcast, which inspires engineers to serve clients better, break glass ceilings and enjoy lucrative work. Your hosts are Eric Lau, Chief consultant at Brittany Butler solutions and Fatima Agheli, up and comin engineer. We focus on th software essential skills whic engineers, managers and client need to upgrade their softwar projects

Hello, listeners, welcome to diverse software engineers podcast. Today I have a very special episode with a person that I've worked with that I greatly respect. And he doesn't know it yet. But he's the one who showed me really what architecture is like what what does it mean to really mean to be a solution architect and what it's all about. But before I introduce him, or and Fatima get into that, I want to ask you off the table. This is your first week of a new semester. So how are things so far?

Things have been pretty good so far, considering it's only been about three classes like not nothing too crazy has happened yet. But I thought it was kind of interesting how in one of my programming classes actually to get students more engaged. Every once in a while one of the lectures will be hosted with a co hosted with a few students as like a group. And so like one day I might be be able to co host and then do polls and interact with other students. And I think that'd be very good for like, learning to speak to other people better and learn like leadership skills, stuff like that. Yeah.

And this is a programming course. Right? This is not an elective, correct?

Yeah. So I thought that was interesting.

Yeah, very much so because, I mean, Hussein you can chime in here. But when I was in, in school and computing, or think computer courses, they were no, not talking about that. No, I mean, you almost got this sense that at the time that programming is a bit of a lonely thing. And that's the mentality. What do you think Hussein?

Yeah, I'd say that that's, that's generally perception out there, that it's an individual activity, that you're just burning the midnight oil, and sitting there in front of a dark in a dark room with a computer screen glaring at you. And that's, that's your life, but that's actually just a part of the life. And it's great to see that they're, they're focusing on some of the other aspects, because most most, most software is built by a team. And, and individuals, you know, contribute to that team, but you need to make sure the team can operate. And people need to talk to each other. So make sense?

Absolutely. They work as a team and teams are what accomplish great things. I am always reminded that, you know, the saying, The truism, if you want to go fast, go alone. If you want to go far, you got to go as a team.

Yeah, that's actually quite wise, for sure.

Wow. So thank you, first of all, Hussein, for being on the diverse and software engineers podcast.

Oh, well, thank you for having me. I'm interested to, to catch your questions, and then have a great conversation here.

Absolutely, this is all for all you listeners out there who saying I've actually worked together for about over a year, by year at issues calm, and I will circle back to that in a in a bit. But let's, let's start with Hussein. Now, why don't you introduce everybody who you are, you know, maybe that 30 second / one minute pitch about who you are? What? What is it that you do?

Okay, sounds good? Well, I'd say I started out as a studied engineering, electrical engineering and a little bit of computer science back in university. And very, you know, towards the end of my engineering degree, I started to understand I was more interested in what you can do with a cell phone rather than how to build one. And that led me in the direction of moving more towards business and how you apply technology to solve business problems. So I started first at a at a software company, that sort of supply chain management software. And then after a couple stops ended up at a growing, fast paced e commerce company. You're in Vancouver, Canada. And yeah, it started out as a six month project that was to implement an e commerce system. We were doing a new system implementation. But you know, one thing led to another one project to the next project and then ended up being there for nine years and was there as the VP of it after, I would say, most of my time being the solution architect of all of our applications there at clearly.ca. Since then, I've kind of gone into more of an independent consulting role, and really looking to help businesses understand how to manage their portfolio of technology, because it's getting more and more complicated and costly and risky to do so. So looking to help medium sized companies in particular, where they might not have the full budget, to, to build out a full tech team. So that's the mission I'm on and looking to find a way to get others involved with me on that journey.

You said earlier, something that caught my attention, like you more interested in how we can use a cell phone versus how to build one.

Yeah, just you know, both both problems are interesting and important, right. But you know, depending on who you are, what you're motivated by, you might be interested in one or the other. And, you know, some people are very interested in the deep technology and sort of making things that much more optimized and, and focusing on a piece of the puzzle. whereas others are more interested in the entire puzzle and how the different pieces come together. And then obviously, those two groups need to work well together, as well. So I'm more of the second kind that, you know, I'm always looking at, okay, I'm working on this one piece. How does it fit into a bigger puzzle? And how do I work with the other people that are working on the other pieces of the puzzle to make something bigger?

Fatima, do have questions for Hussein? What what are your thoughts?

Okay, earlier, I was looking at your LinkedIn actually, and I saw that you've got you've gone Sauder School of Business. And I was actually quite curious on that. I was wondering how much did business school help you in your careers?

Yeah, that's an interesting, interesting one. It was later on in my career that he went to UBC Sauder School of Business. But it was something that I've been thinking about doing for a really long time. So I must have graduated sort of around 98, from engineering, and worked in my, you know, three to four years. And that's a typical timeframe when some people would go back if you were going to go back and get an MBA, etc. So I heavily considered it at the time. But it turned out, I kept running into issues with you know, why exactly do I want this MBA, it wasn't really clear, most people would go into it, because they needed it for the next job opportunity. And then there was a significant uptick in their salary. As a result of it. I wasn't necessarily looking at a very clear sort of ROI in terms of salary improvement at the time when I was going into it. But I really felt it was an important piece for me to understand all the various domains of the business that I'm going to be supporting. So that I can do so with more confidence, because at clearly, I had the opportunity to, you know, learn about all different parts of the business. Because we implemented a financial system to support the financial team or the finance team, we implemented a warehouse management system to help our operations team. And we implemented, you know, an e commerce system and other marketing technologies to help our marketing team. And so through those interactions, I got to learn a lot about those parts of the business. But you know, I'd often would, would second guess, and maybe not be as confident in putting forward my opinion in those areas, because I felt that maybe there was something I didn't know. And so part of the reason to go into the business, to get the business degree was to sort of put that to bed and say, Look, I've gone through the NBA now, I kind of know what I don't know. And I know you know, that what most other people do know and so I can speak with more confidence. That was the main reason for for really going back. Plus, I really enjoy school and it was a good time to kind of refresh that, you know, re energize the whole sort of journey of learning and infusing that back into into myself. So and also building a network. That was it was important to meet people, I've been kind of heads down at clearly for a long time. So I find, you know, having a separate place to go and meet other people and get to get a sense for what others are up to, was quite interesting for me. So I think I encourage everybody to always have some angle where you are meeting an audience other than the people that you typically spend your days with.

Yeah, I think that's a very good attitude actually. helps you get, I think it gets you farther in life, if you like, always get ready to like, learn more, and always think of like, there's more to know, out there.

Yeah, I guess there's, there's a bit of a respect for, you know, you know, wanting to make sure I'm on firm ground before I start making, making, you know, statements and putting myself out there. So maybe there was a little bit of being risk averse. And a respect or respect for the fact that I've had a certain set of experience and, and maybe there's more to know, out there. Before I get too, too caught up in my own opinions.

or Hussein, I just love the fact that you said, you went to two plus years of MBA school to know to learn what you don't know. That is such a different attitude. Then he went over to sing like even there are classmates her age, who wants to tell give people advice, who say no, they think they know, everything, use you. And you're like, you're probably one of the most qualified people on the subject. And you spend two years to basically just learn what you don't know what what what, I just want to strike that contrast in attitude.

Yeah, and then sometimes, you know, there's always gonna be uncertainty. So you'll never know everything. But often, it's a matter of knowing what you don't know. Right? So you extend yourself, you're like, Look, there's a whole area here. Now I know it exists, right? But before you might not even know that that entire domain exists, that there is a specialty in that, when you go into that area, you might need to go and get some further specialized knowledge. And, you know, look, for people that really know it well. When you don't have even a coarse understanding of it, then you might not even know that there's a fine understanding to be to be had. So I think awareness and awareness of the breadth of what's out there is important so that you can bring the right people to your team when you need them. Sounds great. Now and before we actually get to the next segment, I want to just realize, I think, on all of our listeners, well, maybe even for team I'm not gonna say know, what clearly is maybe they do we, the company is still very much around. But um, who's the mark? Maybe you can spend a few minutes to talk about what, what clearly is we're gonna company there's what and one of the main challenges and, and things that you have to solve a clearly, Yeah, sounds good, I can give you a brief overview. So you know, you know, in a quick word, it's a retailer, and an online retailer of vision care products, that's like eyeglasses and contact lenses, they actually started out first as a contact lens provider, and they were early to the market. And then they entered into glasses. Before you know, people might know more about Warby Parker, that's the name that most people know. But clearly was actually into that business earlier than Warby Parker, they were recognizing that there was a was room to disintermediate, the, the optical industry, and that the losses didn't need to be as expensive as people were paying for them. And so it really ended up being a supply chain business, and a marketing business to try to get people that need glasses connected with sort of more cost effective providers of that those glasses. And in fact, they built out an entire optical lab themselves to, to make those glasses and to cut the lenses etc. So they really were out in front and you know, doing things like you know, get your first pair of glasses for free. On the bat that went once people tried out service and saw that the quality of the glasses was actually quite good, that they would be back for more and be willing to pay for them. So in terms of what the key challenges were, obviously, there's, you know, every business requires a foundation of just general desktop support. There was also, you know, a finance team that needed to take need to always be on top of how much money we were or weren't making on every order because we were trying to be quite aggressive with our pricing and so we were doing a lot of transactions and these financial systems needed to make sure that it broke those transactions down into the component costs, etc. And so we needed a pretty good eirp system, we also had a fairly interesting supply chain, you know, we would buy all the products from various vendors and then ship it out. And shipping around the world, we actually had country with websites in multiple, multiple countries, Australia, New Zealand, Japan, Europe, Canada, United States. Every one of those domains requires all sorts of different pieces of technology. And you know, in the time frame we're talking about between 2006 and say, 2015 is when I was there, you know, marketing technologies and e commerce in general were growing so much the art of it was growing. And there's, you know, if you were to look today at all of the different pieces of technology that marketing teams deploy, there's 10s, and hundreds of tools that they now use to, to manage every different piece of it. And so it becomes, it becomes a problem of finding the right tools that you can then apply to make your marketing even better than it was before.

That's great. You mentioned the tools. And you know, the I think that's becoming the themes of the show, use the right tools and stuff. So that's, I would love to get into more of that. And we'll do that after these messages.

Celebrate your software projects or software careers by requesting a free 30 minute consultation. For details, go to dsepodcast.com.

Welcome back listeners. We're continuing our interview with Hussein. And in the last segment, we talked a little bit about tools, and how companies need to manage and deal with those tools, which I would say is a big part of what a software architect is about. But I like Hussein, tell me what it is and what it isn't.

Architecture is one of those topics that that has lots of different faces to it. And I be curious Fatima, what, you know, when you're when you're in school, and you're going through sort of software development, education, to what degree do they actually cover the topic of architecture? What are they bringing forward as, as that? Is there specific courses about it? Or is it this loose term that people use? Or don't use?

Yeah, actually, I'm not exactly sure on like the definition of architecture myself too well, but I think the closest thing we've covered was like design. And we've definitely taken like design courses and like courses similar to that. But I don't think we've done anything like specifically on architecture yet.

I'm always curious about how it's being taken, you know, in, in the courses these days and what students are picking up in the field, I would say there's there's all sorts of different types of architecture, and at different levels, right. So as a developer, you are, you know, to some degree architecting your, your code at a very low level, there are different patterns, but that you're applying to that code and you know, best practices about how to separate different types of code, class structures. And you know, how you might organize your logic and pieces that are easy to then maintain and extend over time, right, finding those things that are common. And, and breaking those pieces out. It's what's really led to object oriented programming as a common fundamental behind so many different programming languages out there. I would say to some degree, architecture just sort of takes that same concept and sort of moves it in bigger and bigger circles, right? It's the how what are the pieces patterns you want to establish in terms of how different modules within an application will work with each other? how the different components of the application, whether it be the database to the application server, the client, you know, what pieces of work are going to be done in different parts of the ecosystem that you're building? And then, you know, how do different systems interact? How do you actually take messages that one system might want to or want to communicate and get them to some unnamed resource out there that you're trying to conceal, or trying to publish events, there's lots of different patterns that can form give you guidance on how you want to bring to solve those problems. And you know, if you can come up with a standard set, it just makes it easier for the people are actually building the solutions, to do so in such a way that it's more homogenous. And that you can sort of plug and play different pieces. You know, more seamlessly. I don't know if that made some sense. But if I was to, you know, go from the bottom up, you have your developer, and then you'd have a system architect, you then might have a solution architect where you're trying to figure out how does this system really solve the needs of the user that is going to be using this system. So you work with the UX people, you work with the business analysts, to say, How do I bring the functionality to these users. And then, you know, decide what the blueprint of the system is going to be, so that you can chunk out different pieces of work and give it to different developers and development teams to build. And then one step higher than that might be a solution architect, an application architect, and then Enterprise Architect, and then business architects are sort of the different layers that you can go to. And generally, you're dealing with a higher and higher sort of group of people that you're serving. So you might be, you know, at a lower level, you might be just serving the people that use your one application. And then the next level up, you're dealing with the set of users that use a dump a bunch of applications, and they all need to work together to help solve a business problem. And then you might be working on the entire set of tools that will be used by a whole department or the entire business. And how do you actually, you know, make sure that those tools work cohesively. And that over time, if you need to extend or replace one of them, then you can do that without having to rebuild everything. Hopefully, that makes some sense.

Yeah, definitely. That was That's very interesting. I think I learned a lot about architecture from that. Because Yeah, I definitely thought of it in a much more broad way. Like, that actually narrowed it down for me, like the definition. Thank you.

Yeah, for me, as I said earlier, Hussein is the person who really showed we just the way architectures have told me totally different realm with its own set of skill set. Because I've got a little background when I was at shoes.com and we actually both got hired on. On the same day. We bought how to save data, we have so many people at that time. And I and I remember at the time, I had worked with architects before I I I just came off a number of years as a manager as a management and I'm going into shoes.com as a manager. And at the time, I'm aware of architects and before but I will be extremely honest. I felt like architect is just a different term. You know, when when when people don't want to be called developers anymore, and they want to ask for more money. I don't think that now and that's a lot of it is thanks to you Hussein. Because Oh yeah, because I remember going well okay, you know, Lisa smartphones, your little tools, he built some tools in a building, he put them together, okay, like what's the big deal? And then I remember you coming in with that meeting and you had that diagram and this diagram for TV I wish I could show you this. It's got too much proprietary information so I can't show it to you. But it was a sight to behold I mean, to give you a listeners idea about this described as architects diagram, like, like it's, it's got like probably what like a couple 100 plus items in it little each module is like a tool or a tool like either you build it yourself or like a custom tool, like DRP Enterprise Planning like type of tool like dynamics things I'm not gonna get into technical stuff. But you also have like, like MailChimp like mail distributions, and Lillo like SEO for like, you know, advertising, things like that. And, but it's not anybody can list those things. I mean, most people, even in the business work in that industry walk and list them, but to put all the processes and all the arrows and talk about the relationships between them and put them in there. That was like a work of art. I'm just gonna say it's a work of art, because I have never seen at the time, when we're laid out the entire organization's all the multifaceted tools, all of that in the diagram. They go, Oh, this makes sense. Now, I know why he was brought in.

Oh, wow. I had no idea that that had had that impression.

Yeah, definitely. It was very interesting.

Yeah, you know, like I came in, I came into that, that role. And that diagram had not existed yet. In my sort of, before I got it got to shoes. What was interesting is that, when I was like, clearly, I'd had a chance, like I was telling you before, to work with all these different departments. And I'd kind of gotten a sense for what the, what their needs were. But I was so deep into it at clearly and just sort of focused on, you know, the next thing we need to do the next thing we needed to do, I knew that there was a pattern in all of what I'd learned that needed to be extracted to help guide how we would then maintain and move that, that that entire platform forward. But it wasn't until I got to shoes that I really had a little bit of space to see that everything that we had done it clearly, most of the problems, we had the same needs that existed at clearly were also there present at shoes. And there were a couple of new ones that I hadn't actually known about as much before. And so that diagram kind of came together as a way for me to, you know, understand the sum total of all the different pieces of the puzzle that we needed to actually manage. And to be honest, like, we tried to keep it somewhat simple, because there's a lot more that you could put into that, that diagram. But what I think it really did well is to communicate to the business stakeholders, the chief operating officer and the financial officer and the CEO, Hey, you know what, we actually have a fairly complex set of things that need to be managed, right. And so we need to be very focused about where we want to put our effort. And as we are trying to fix one of these boxes in this big diagram, let's make sure we understand that it's just a box, and it needs to play well with the rest of it. Right? And what I find is that you can get a lot of people that know, the innards, the the inner workings of any one of the boxes in that diagram. But when you're talking about how all of those different boxes need to interact with each other, and how do you create a platform that helps all of those functions run smoothly? That's where I think, you know, there's, there's very few people, you can just sort of turn to and hire someone to come and tell you how to do that. That's where you as the team need to figure out a pattern that is going to work for yourself. And I think it really did help us focus on what were the key capabilities that we needed to establish as a business that we could then continue to, to, to extend and use in different ways. Right. So we talked about that portal framework, right? It was basically the recognition that there's lots of systems out there. And because we're going to be using systems made by different companies, that they each have their own user interface, for example. And sometimes those user interfaces don't look like each other. So you might want to have something that sits on top that creates a more cohesive experience for the end users, where they don't need to know, you know, where the business logic sits, and which vendor it was made by, we would present t a UI that is specifically geared for a specific user in our business. And so we thought about building this portal platform to bring those pieces together in a common UI. And I think once we know that that's our goal. I think it puts a different mission to building out a very specific need. Like I think the project you were on was was working on the merchandise management portal. Right. But yeah,

That's right, that the merchandising portal, if I actually that's actually a good one to sort of get into maybe you just explained to our listeners sort of what exactly are the specific tools, which I feel like right now, the conversation can be a little bit abstract, maybe we can get a get they can just one concrete example. That will be great.

Yes, sure, sure. I think that makes good sense. So what I done in that diagram was split things into, you know, four or five big groups of systems and it very much was along the lines of you know, there's your financial systems, then you might have some supply chain systems, for example, you will have order management or procurement management, the place where you actually create all your purchase orders, and you send them to your vendors. And then you would get those purchase orders back you receive goods, then that sort of interacts with your inventory management system. And that was a merchandise management portal. Behind the scenes, it was actually interacting with a whole bunch of different systems, our procurement system, or e commerce system, our marketing systems, it needed to actually push that product information into 515 different places. And so that's what this portal was. But I think what was interesting when we laid out that project is that while we were building that portal, we were cognizant of the fact that whatever portal platform we were building, was not just for this merchandise management use case, it was actually going to be a portal that would eventually help our customer service team, it might also help our internal warehouse team. And we would build different interfaces into it. So that I think, gave the mission of that product, the portal product had a bigger scope than it might have, if we were just solving the immediate problem

is really The takeaway for me is that there's so much like tools and put in putting it together in a way that helps the business as a whole. And as non trivial by no means on imagination. And one of the things I was most amazed by that diagram whose input wasn't the fact that it was very thorough, it was a fact that it was about as clean and and Spartan as you could basically do it. Right. It's brevity is a skill.

Yeah. And finding a way to, to be what we were able to do, I think was tell the story of what we were doing, you know, what was, what were the investments that we were making as a technology group and be able to explain that to the business. I think that was that was a big part of its value. It also, I think, gave people some context as a, as a specific developer working on a specific project, you could see exactly where you are going to be impacting the business in a positive way. Right You see, you get situational awareness about what you're working on and why you're doing it. Which I think sometimes, you know, I do get the sense that in some development organizations, that overall scope and context is missing. They just give you, you know, you'll get a JIRA ticket or something and say go built this one little piece. But they don't do a good job of, of explaining to you why. And I think why is a pretty important aspect that you want to share with as many people as possible because then it'll be more likely that those folks will be making the right decisions and asking the right questions as they're building.

Yeah, the why to me is so important. And so many organizations don't emphasize that, which is a shame. Because there are no shortage of people I've talked to about myself, I've been in situations where I felt like my job was just ticket puncher, right, here's a ticket, there's over a little bit quite the code to solve that a little bit, that make that Wait, make A input a response, or output BCD, depending on condition, bah, bah, blah, and move on. And that's missing a lot of the opportunity and the importance of everybody working together towards a goal. If you can't explain what it is or why you do it, then you're not doing you're not doing yourself any favors. One company that does actually that that explains why very well is Apple, if you look at the way that Apple like does the marketing that they they said we spent like, like three quarters or more of the time talking about the why why they want to change the world and put a dent in the universe, and then how they will spend all that and then the angle, and this is it'll present the iPhone, but this is how and this is how we do.

Yeah, exactly. That's a very good point. Right? I think they've they've made it very clear what their guiding principles are, what their philosophy is, why they why they design in a certain way. And it's still not easy, right? They still need to find the right people that really uphold that that mission. But I think it really helps to make sure that everybody that's contributing to an Apple product is more likely to be building it the right way from the beginning. And they don't have to, you know, course correct as much as they might, if it was just, you know, you know, just outsource a piece of this puzzle to somebody else to build with functional requirements. And that's it. It's more about how it's built. And the overall philosophy of what you're trying to accomplish.

It goes back to that saying, right, if you want to go far, you go with your team, and you want to go with your team, you have to tell them why they're rowing the boat.

Yeah, exactly. Right. You can't just tell people what to do. You need to tell them why they're doing it. And I think that really goes a long way to a build a team, making people feel like they're part of something bigger than themselves. And, you know, sense of camaraderie and belonging, and accomplishment, because they're part of the overall problem that's being solved. They're not just doing the tasks from 9am to 5pm each day, and as you said, just churning tickets, and pushing them out the door.

I certainly can relate to that. And when I was when I started this podcast, I know that I am not punching episode just pump stuff out. I'm doing it. The Why Why am I doing it is because of you, audience, all you listeners out there. So we will take a break. And in a few minutes, we'll be right back.

Celebrate your software projects or software careers by requesting a free 30 minute consultation. For details go to DSC podcast.com.

Welcome back listeners. Hussein. So we talked about architecture and how important and rewarding in our industry or our profession. It is, I'm sure some of our listeners going Wow, that sounds great. I didn't even know that existed. And as a, you know, junior developer or as a, you know, into SIL in computer school, or even in code camps. You know, what, what does it take? How do I get in? What would you say to your 25 year old self if you could go back in time?

Yeah, for sure. You know, obviously there's there's always hindsight can be 2020. And while I'm quite appreciative of you know, all the experiences that I have had, and I think I'm happy with where I'm at. There's definitely, you know, little course corrections that can see that might have been useful. I'd say that early on in my, in my career, it might have been good to focus on getting a lot of exposure. And when I say career, I would say like, right during University, to get more exposure to the types of development teams that were out there, and, and really try to broaden your exposure, because there's, there's so many different settings, so many different styles that people and different teams have that, you know, you won't know until you're in it, whether you like it or not. And then when you're finally making that first sort of job choice, I think if you've had a few experiences during your schooling, you can choose a good first place that will allow you to join a team that you really enjoy being part of, and that you think is going to be sort of setting you up to build the right habits, to build the right habits of how to work together, and how to motivate the people around you. How to, you know, take technology as a tool, but it's not a tool in and of itself. It's not It's not for the sake of technology, it's for a bigger reason. And, and to be part of that type of a culture, I think is is really important in your early days. And so if you can find, you know, a strong team, you need to be asking as many questions about the employer, as they're asking of you. To get a sense for what are you going to be learning, not just from a hard skills perspective, but from a soft skills perspective?

No, that makes sense. No, that makes sense for Tina, why don't you ask the next few questions? I spoke enough.

Yeah, I was wondering about your engineering experience, too. How did that fit into your current position? And how did that motivate you

I would say that, yeah, in my engineering coursework, there was definitely pieces of that coursework that I never really did apply. And, you know, in hindsight, might not have been important to have taken. But there was no way at that time that I would have known it. The pieces that I felt were most valuable were the the the ones that were more systemic in nature, understanding the overall way that different components interact with each other, and how they come together, if that makes sense. So wherever there was a, an application, even if it wasn't in software itself, I think the thought process is what what was the important part? How do you take a problem, break it down into pieces, and then solve the pieces and bring it back together to come to, to come up with with the whole solution? And I think, so there's a general problem solving and systemic thinking, habit that is useful to to exercise while you're in school. And, and then you'll be able to apply it in a particular area once you once you come out into the workforce.

I see. Okay.

Did that help?

Yeah, that makes sense. Yeah, definitely. Definitely. Yeah. Thank you,

Hussein, so you talked about solving business problems. And, you know, in the terminology that we use in technologies called, like, domain knowledge, so to you, like, how important is domain knowledge, software development?

One other thing that I was going to touch on around when you when you come out into into the workforce is that, you know, technology is so ubiquitous now. That it's, I think, quite valuable for you to understand, you know, what are the areas of society? What are the areas of the world that you want to actually have an impact? You know, what is your personal Why? And if you can latch on to companies that are actually addressing a problem that you really think is important, then I think the domain knowledge that you're picking up about that aspect of society whether you know, whether it's like, you know, you're really interested in retail, are you interested in fashion? Are you interested in media? Are you interested in, you know, a different part of the world, there's a lot of value in having both technical skill and also understanding an aspect like a business function or, or an industry and bringing those together. So I would say that, you know, if you if you have a chance to sort of reflect on that, and biess be quite conscious of what what business problems you're solving, I think there's value in that.

It goes back to what I numerous times heard about, do building the right things, versus building things, right engineering school, you can be taught, technically how to build something, right? But how do you know you're building the right thing is really hard to do without a good base domain knowledge.

I would actually say that, you know, as you get further along in your career, I think domain knowledge becomes more and more important, and it takes time to establish. And so you should think about it as a bit of an asset, right? If you're going to spread yourself thin across a bunch of different domains, you know, there is some value to that being versatile. But I think there's more value, if you're able to focus in a particular area, I think you will develop a broader or a deeper understanding of the needs of a certain of your customer essentially, like, and I think there's a lot to be said, for understanding the needs that you're solving, in order to do it more effectively. And again, that just takes time. Did that make sense?

Yeah. Thanks for the information. I really appreciate it.

My pleasure. Thank you for for having me on.

That was a very interesting interview. I think everyone here learned a lot today about architecture and about the education process. And I want to thank our guests who are saying today for joining us. Merci.

Thank you so much for saying thank you Fatima being part of this as well. <Says thank you in Mandarin>

congratulating yourself for listening by engaging with us. You are already well ahead of the pack. Please subscribe, share with others and post about on social media. For feedback and suggestions for future episodes, please go to the podcast website, DSC podcast.com.