The .NET on AWS Show, Featuring Laïla Bougriâ (again!)

🎧👉 https://www.art19.com/shows/net-on-aws/episodes/36feb18b-69ce-4e7e-829e-2b12ce2f6c3c

Unknown Speaker 1:00

Brandon,

Brandon Minnick 1:10

hello everybody, and welcome back to another episode of the.net on AWS Show. I'm your host, Brandon Minnick, and with me today, we have a very special guest co host, Brooke. Jameson Brooke, welcome to the show. Hi.

Brooke Jamieson 1:26

Thanks for having me. Very exciting. Slowly, I will infiltrate every show on the AWS Twitch channel.

Brandon Minnick 1:33

Love it. Super excited to have you just like last show. Francois still out on holiday. He was at the Olympics, and now, I guess he's just enjoying life in France, Francois. We wish you the best. We'll see you soon. But Brooke, for folks who haven't met you yet, who are you and what do you do?

Brooke Jamieson 1:50

I'm Brooke. I'm annoying on the internet. No, I am a senior developer advocate here at AWS. I'm from Australia, which is why I say things like data and aluminum. But I am now in New York City, I moved for this job, and I specialize in AI and machine learning. I write lots of blog posts, I make lots of video content, and I do lots of speaking as well.

Brandon Minnick 2:11

Love it, that's right. And I'm sure everybody out there has seen you somewhere online. But if you haven't, be sure to follow Brooke, you can see your handle here at Brooke underscore Jameson online and Brooke, we were chatting before the show. You mentioned we were talking about reinvent AWS, big yearly conference coming up, and you're gonna be there.

Brooke Jamieson 2:30

Yes, the fever dream is on again. So I'm speaking with Faye from Pluralsight, which is super exciting. All about the ABCs of generative AI, I'll like, pop the link in the chat for people, but it's going to be super exciting. I would say follow me for the update about when you can RSVP for the session, because every year I get sad messages from people outside the door who did not RSVP. And at reinvent, as some people would know, the rooms fill up and then for various reasons, like fire, things like that. There's like, hard limits on capacity and rooms, and every year I get these sad messages from people that did not RSVP when they could, and then they're outside the door, and I can't go and let them in, because there's security for this reason. So I will post the moment you can RSVP for the session, and I recommend following me to get on there initially, because, I think especially because Faye is speaking in my session, it's going to book out, and I want to decrease the sad messages I get this, yeah,

Brandon Minnick 3:32

yeah, that was a surprise to me in my first reinvent Well, the AWS employees aren't allowed to make reservations for sessions, which is a bummer. But, yeah, there is a standby queue. So there's a couple I tried to wait in line for, and they all sold out. So yeah, make sure to reserve your slots or get there super early. Be the first one in line. Cross your fingers. But because the other thing

Brooke Jamieson 3:54

is, if it books out really early, they do actually put on extra sessions. So my first year speaking at reinvent I did it actually twice. So the first session booked out in record time, and then they put a second one on, and that also booked out, and they were threatening me with doing a third one. So if you want to go to recession RSVP, because then this can help them. There's like all of these, as you can imagine, algorithms running behind the scenes to see which sessions they should add repeats for. So if you ever looking at the reinvent calendar, and it's got like, the code of boa 208, or something, dash R. That means a repeat. So if you've seen it once, you don't have to go again. But these repeats happen because the earlier sessions get booked out by people. RSVPing.

Brandon Minnick 4:34

Love it all the insider tips for my

Brooke Jamieson 4:36

reinvent tips.

Brandon Minnick 4:40

Well, Brooke, we have a amazing guest on the show, so don't want to delay any further. You've seen her on the.net on the AWS show before. She's an international speaker. She keynotes at conferences all around the world. Layla, welcome back to the show.

Laïla Bougriâ 4:57

Thank you. Thank you for. Having me again, and thank you for such a nice introduction. I appreciate it.

Brandon Minnick 5:04

Of course, always a pleasure. We'd love to have you back for a third time, fourth time, but for anybody who didn't catch the last show, tell them who are you and what do you do?

Laïla Bougriâ 5:16

Well, I'm a Solutions Architect. I work for a company called particular software where we build in service bus. And for those of you who don't know what that is, it's basically a framework and a platform that makes it easier to build distributed systems with messaging, any messaging service that you may already be using, like much of the AWS services, SQS and SNS, but also Azure surface bus and also revenue gear, for example. And there are plenty more as well. And the idea is that we provide a programming model that just makes it a lot easier to deal with a lot of things that you're exposed to when you are building a Message Driven architecture, which is a challenge of its own sometimes. And yeah, I've been there for a couple of solving distributed riddles like I tend to say,

Brandon Minnick 6:04

yeah. And we were chatting before the show, and it sounds like we have so much to cover. We might even need a part two for this part two show. So Leila, where should we dive in first?

Laïla Bougriâ 6:17

Yeah, well, one of the things that I've been working on over the last few months I continue to work on very intensely right now is actually to provide more guidance for people building these types of systems. Now I remember because I was using messaging and end service bus long before I was working at the company building systems out there in the wild, and it was like being thrown in a pool, and it was like, okay, learn how to swim, and the only thing you could really rely on was a lot of great blog posts, a lot of good talks. But it was always tough to put it all together and to really understand, how do I apply this to my own domain and get some practical advice? So one of the things I'm doing now is I'm building a workshop to basically tie all of those things that I wish I could tell my younger self, if you will. And yeah, that will be for the first time at Tech Rama in the Netherlands, and then in Porto at NDC conferences,

Brandon Minnick 7:13

two of my favorite conferences. I'm actually in Copenhagen right now speaking at NDC. Copenhagen this week. Big fan of NDC. I'm bummed I won't be able to see it Porto, but we'll share the link in the comments for for Porto and turama, if you're in the area, if you're anywhere near the Netherlands or Portugal, go attend these conferences. They're incredible. I was it just like,

Brooke Jamieson 7:42

No, you go, go ahead. Sorry.

Brandon Minnick 7:43

I was a decorum of Belgium couple weeks ago, a couple months ago, and it's, it's incredible conference. But also, they had a whole carnival there. There was literally a Ferris Wheel. There was carnival rides, carnival games that you got to ride and play for free, just as an attendee. So even if you hate tech talks, convince your company to get you a ticket and then go ride the rides.

Laïla Bougriâ 8:09

It's a good way. Yeah, it's actually crazy. The karama is actually you're an Antwerp, which is where I'm based. So that's like home for me. So yeah, that was great. So actually, the reason that was so festive this that this year is because of their 10 year anniversary, and it's going to be their five year anniversary in the Netherlands this year as well. So it's like a double festivities.

Brooke Jamieson 8:30

So good. My favorite thing about any of like that conference socket is how many adversarial people I get to meet that don't like AWS. My favorite thing about these conferences, because the thing is, is, like, so often I'm going to AWS only events, and I never get to hear people, oh, is everything dropping out perfect, but I never get to hear people like, really roasting AWS on stage. And it's so good because, like, this is what helps me get really good feedback to take back to the service teams. So for this reason only. I just, I love going to NDC. I love even people just talking about different things that they wish AWS would do differently. And I'm like, perfect. Tell me all about it. This is my job. I would love to make this better for you. So, yeah, it's always,

Laïla Bougriâ 9:12

that's exactly what we want to hear. Especially, yeah, when we're when we're building a product or a platform, like, even though it's it can be like an experience with friction. Sometimes that's where we can learn from and make it better. Absolutely, I do agree with that.

Brandon Minnick 9:27

Yeah, same. And I always tell people my favorite part of conferences are don't get right. I love the talks. I go to as many as I can, but lunch, dinner, getting to sit down with somebody you haven't met before. Learn what they do and yeah, hear, hear where their pain points are, because that's the feedback we can bring back to our team internally and help them prioritize certain things and let them know about those, those rough edges. Maybe there's missing documentation. So yeah, if you ever see any of us, I. On the conference circuit. Feel free to chat us up. Let us know what you're working on. We love hearing about it. But speaking of the Workshop, will the workshop be focused on?

Laïla Bougriâ 10:14

Well, there's a couple of topics for two days, of course, actually the tikrama one is one day, so I'll have to somehow find a way to grab it until one day. That's going to be the biggest challenge. But one of the questions that I get regularly, and that's also where one of my talks came from, is, okay, there's like, two coordination mechanisms that are super popular in message based systems. You have orchestration and you have choreography. And which one should I choose? Which one is better than the other? And you know, as a consultant or just a software person in general, the only answer you can give is it depends. And the thing is that any good or any well designed distributed system has both coordination mechanisms. But to even start explaining that, I feel like I always have to take steps back, because one of the sort of sources, or one of the sources of friction that we're always trying to tackle in software is the oldest thing, which is coupling, right? That that's what we're really trying to that's what we're really trying to tackle. That's what we're trying to balance. We don't want to get rid of coupling. We don't, I don't really like the term decouple that much in the sense that coupling is not something you can entirely remove, because the system without any coupling is inoperable, right? So it's about finding the right balance and the acceptable points of coupling to make a system work well together, so that you're able to evolve it without too much pain. So, yeah, um, that's that's where it all starts, yeah. So when it

Brooke Jamieson 11:48

depends earlier. I love asking this, because, like, as a reformed Machine Learning Consultant, it depends with, like, a computer. But what does it depend on? Because I know people want to get, like, one specific answer out, and usually, if someone gives you that immediate answer, they're probably wrong. So when we're talking about it depends, in this case, like, what does it depend on, and what factors should people really start to unpack, right?

Laïla Bougriâ 12:13

Well, one of the things that I have the silver to because when people ask this question and they get the one answer. The one answer tends to be, oh, you should use orchestration within a single surface boundary. You can use it within many single surface boundaries, but always within a service boundary. And choreography is something that you should use when you are communicating across surface boundaries. And that's the rule of thumb. That's like the first answer you could give. And theoretically it, yeah, I agree with it. But the thing is that there's one major flaw in that advice, and that's the assumption that you got your service boundaries right. Because if that's not true, then you might actually be hurting yourself a lot more by just blindly following that advice. And that's why I sort of, like I was, spent a lot of time diving into, okay, what are the pros and the cons of each coordination mechanism? And what do you see here? What do you see there? What type of coupling Are you exposed to in each coordination mechanism? And I think that's where it depends what type of coupling Are you willing to live with. And one of the things that I ended up doing is bringing it back to five main questions, if you were and if you want, I can share those with you. The first one is basically like, what type of communication are you even using? Like, are you using synchronous communication or asynchronous communication? Because we are talking about messaging here, and by default, that is asynchronous. But there are many systems that use synchronous communication as well. And you could be orchestrating using synchronous communication, but you can orchestrate using asynchronous communication as well, and the things that you're exposed to are quite different. Then, because you get all of the benefits of using a message queue, like temporal decoupling, and you have better resilience and all that, so the coupling is not removed. But like we, like a lot of blog posts, a lot of documents, a lot of stuff that I read tends to tell you that cues decouple. No, they don't, they help and they they can inverse coupling. They can reduce certain types of coupling. But it's not as if it just makes all of the coupling disappear.

Brandon Minnick 14:41

That's a really good point before we dive into that. What? What is coupling,

Laïla Bougriâ 14:48

right? Wow, now we're really going back back and

Brandon Minnick 14:53

why do we want to decouple?

Laïla Bougriâ 14:54

Why do we want to decouple? Well, coupling is basically how to. Two components, services, objects. It doesn't matter what we're talking about, basically depend on each other, right? And then the most basic form to think about it is afferent and efferent coupling, where afferent measures all of the incoming coupling. So all of the services depend on you as a service, like I'm service a who depends on me. That's all my efforts are incoming coupling and efferent coupling is all of the outgoing coupling. So all of the services that I depend on for my service to work well. So that's sort of the like, basic, basic, basic. But the thing is that usually when we build applications, we start with really good intentions. We try to really understand, like, what is the scope of this product, and where are we going? And we try to really take time understand the domain. But things evolve all the time, and I see where I see the friction come from, also from my experience. I've been doing this for almost two decades, even though I don't always like to admit it. But what I've really seen is that the more time you spend with people from the business, the more you can really understand where the points of coupling are, because it's not about finding the coupling in software first. It's actually finding it in the business first. Yeah, and when they're not really

Brooke Jamieson 16:19

where the points of coupling are. But why those are the points of coupling is what really starts to come out as well, because some things you can change and other things you can't. I guess this ties back into what you're talking earlier, about, like the coupling you can live with.

Laïla Bougriâ 16:32

Yeah, yes, yes, yeah. And where we want to end up coupling is where also we believe that the coupling will remain stable, because then it will hurt us less something that changes all the time and is then tightly coupled together and changes because of this requirement changed. Or, you know, that business requirement changed, that's really how we end up building those monsters where nobody can understand why we have 100 API calls from just a single click, or all those types of fun situations that we've probably all encountered at some point in our careers.

Brandon Minnick 17:10

Yeah, so So we're thinking about in code, it's almost like coupling, is code depending on other code, and so with decoupling, we want to break that direct dependency. And you know, in.net especially in enterprise apps, I think of immediately think of interfaces, but you also mentioned message queues, what? What are the recommended ways to handle that so that we can prepare for future? But also it still needs to work today. We still need to test it. We still need to meet all of our requirements, right?

Laïla Bougriâ 17:45

So to circle back to that comment that I made, is that queues don't necessarily decouple, right? One of the things that I tend to read a lot is that publish, subscribe will help you decouple. And that's not really true. What you're doing is you're inversing the direction of the coupling. Because before you had, let's say, a sales component that called an invoicing component, right? So you had that coupling there, and now sales depends on invoicing for that. And then we say, oh, you know what? Instead of doing that, sales is going to forget about invoicing. It doesn't even know that it exists. And instead, invoicing is going to subscribe to a message that comes from sales. But basically, if you draw this, and that's where you really see it, there's an arrow. It just changed in direction, and that's what I found, is really important for people to not forget, like, you've inversed the direction of the error. They're still coupling, yeah.

Brooke Jamieson 18:46

And especially, like, this is why it's really important to talk to the business as well, because sometimes you can reverse that arrow and sometimes it makes exactly zero sense to do that. So yeah,

Laïla Bougriâ 18:55

yeah. And to understand also that that's where I think those, those conversations with the business are so important, and it's also a little bit about trying to understand what is more likely to change, right? So a lot of our work, I feel, or I that's a personal I feel, is always tied to that, to ask the right questions, to try to understand what is stable and what is not stable, what is more likely to change because all of all of the things that we are taught, or that, at least, personally I've been taught, and I already said it 20 years ago, okay, when I went to school, like when I went to university, they taught me to think in terms of entities, but it just doesn't make sense. It's like an order. Like every possible application in retail that I have seen in my career has a table called order, right? But the thing is that it contains so much information that has a different life cycle. And I think that is that is really. Important is that we try to think in terms of attributes, like, what are the attributes of an order? Oh, it has a date that it was placed on, and there's a total amount, and I don't know, like all of those things, and that you look at each of them, and you try to ask themselves yourself, Does this change from the time it's created? Does this ever change? And if so, when does it change and which attributes tend to change together? And basically, the rule of thumb that I'd like you to take away is the things that change together, keep them together. And you will therefore find that if you follow this approach, you end up with services that are even sometimes really hard to name. And it's like, what is this thing? Well, I don't really know, but all of the stuff that's inside there tends to change together, and therefore that's a good idea to keep them together.

Brooke Jamieson 20:55

Yeah. Experience focused, flow of design. It seems like it happens a lot when sort of a different thing, but when companies, internal org charts change the customer facing products, and this is sort of the opposite like that, like the customer who's having that experience at the end of the day does not actually care what your table is called. They care that it works, optimizing for like logically named things. It can be really difficult for your end users who you're trying to build for. So it seems like a good example of that in

Laïla Bougriâ 21:26

practice. And what they also really, really care about is they, when they come and ask you for the next feature that you don't tell them that first you have to rewrite a bunch of services. That's tricky. I mean, that's definitely one of the biggest challenges of our work. I think

Brandon Minnick 21:45

we got a interesting question to comments chat was asking, Would it be fair to say coupling gives more visibility into our application to understand and pinpoint if something's acting funny? Also I'm pro coupling, as you see,

Laïla Bougriâ 21:58

yeah, I'm also pro coupling. I'm pro the right balance of coupling. As I said, I'm not in favor of the word decoupling per se. So I think yes, it can give you that visibility. But a lot of it also goes back to the type of application that you're building. How large is the system that you are building? Because the larger the system is, the more there becomes a need to split things apart, because people can only take so much information in the same context before they run into cognitive overload, right? And that's one of the reasons that we try to decouple things also from an infrastructure point of view, right? Where do we have the most load? We want to create an infrastructure that is not, you know, killing our bank account by having to scale everything because we don't know exactly what. So there is a lot of importance in splitting things up. And even though I would say that I'm a distributed systems advocate, but I would be the first also to tell you that if you don't have to, don't distribute, like, Don't split things up, unless you really, really have to. That's the first rule of distributed systems, as we always say. And I feel like I'm in a bubble of people. We all say this the first rule of distributed systems, don't distribute if you don't have to,

Brooke Jamieson 23:25

there we go, if I could share my screen. I even asked Amazon Q this question to see what it would say, and then I want us to confirm or deny if this looks right. So I asked it this question, and it says coupling the context of software architecture can provide more visibility. Here's how. So the first thing is tight coupling. Then it goes into observability, traceability, debugging and diagnostics, and as you can see, there's details on those and at the end, however, it's important to note that while tight coupling can increase visibility, it can also lead to other challenges like reduced flexibility, scalability and maintainability. You want that balance between coupling and decoupling, which is necessary to achieve the desired level of visibility. How do we feel about this? Should I give it a thumbs up or thumbs down? Leila Brandon and chat?

Laïla Bougriâ 24:11

In my opinion, it looks pretty good, especially because it also calls out the downsides, right? Like when you start decoupling things, and that's what you see a lot in a choreographed approach, is that you lose visibility. It's it's like, okay, you do one thing, and there's like, thinking all these events going off in the system, and you have to figure out what connects to what, and where did this come from? And that's one of the pain points. It's also called pinball architecture. Find that, like, brilliant term for this type of architecture, and that's where it becomes really important to make observability almost like, you know, it's it can't be an afterthought. If you're building a system like this, you have to think about upfront, like, how am I going to be able to debug? Application. Because, yeah, once you start decoupling things, you don't have a call stack anymore, because now you have scalp call stacks right across 1015, 20, 100 services. Yeah,

Brooke Jamieson 25:12

no, this is great. I'm going to go ahead and give it a thumbs up. It did a good job. There we go, perfect.

Brandon Minnick 25:18

Boom. And we got a couple of thumbs up from chat as well. And I'm glad too, because I was going to give it a thumbs up, but I really did want to say thumbs down and then the wrong, especially not in front of Layla. So lately you mentioned, and I love and totally agree with the point that you shouldn't start with a distributed system unless you already know you need it. So how, how do you know you need this?

Laïla Bougriâ 25:51

Yeah, that's tricky. That's tricky. I also worked at a couple of startups, and the thing is that it's very conflicting, right? I've worked in situations where we we said, No, we're going to start small. This is, in essence, a POC that we're going to put in production, but we don't even know whether we're going to sell this yet, right? So we don't want to invest too much. And then I've seen that completely grow into a monster that we're like, oh my god, we should have split this thing up upfront. Like, why didn't we just take some time to think about the architecture? But in essence, you couldn't, because you didn't really understand what you were building yet. And I think that would be the first thing to keep in the back of your mind, is that if you are in a startup, if the business or what you are selling is unclear, don't because the thing is, the rate of change is going to be, first of all, very high, and second of all, extremely unpredictable. And building a distributed system with a lot of moving components, it's just going to make your life a lot more difficult. And that's why you also see the rise of the module monolith, right? So think in modules, so that you can keep things a little bit decoupled, but still, like you can deploy it as a monolith. You can debug it as a monolith. You can work with it as a monolith. And the thing is that those modules that you'll come up with in the beginning, they're going to end up being completely wrong at the end of the exercise. Like, that's reality for us. We would always love to be able to go back with the knowledge that we have today, right?

Brooke Jamieson 27:26

Yeah, to your point earlier, this comes down to talking to the business as well, like understanding what good enough looks like. This is such a thing in machine learning as well, in lots of consulting, people would ask, what does good enough mean in terms of what you're actually inferring and predicting, but that really depends on what the business is going for. So this is such a good example as well. Like, if you're in a startup that's going to be very different business use cases and needs and motivations to working at a bank, or something that's much more established and has a different attitude towards risk, and even for the same sort like, even across banks, different companies would approach this differently. So it really does come down to understanding the people and their motivations before you get started on the tech.

Laïla Bougriâ 28:09

Yes, I think there's something to build upon. What you what you said, Brooke, that we can add is to have that conversation also with the management team, the the product owners, the salespeople, to say, hey, we may be making a lot of speed in the beginning, right? We're able to build features and spit them out, like, here's the next one, right? And it's super easy. And I think it's really important that they understand from the beginning, from the get go, that that's not going to remain that way, and that as the business stabilizes and you find what your core business is, that you will have to take time to then sit down and really think about okay, we understand this business inside out. These are the service boundaries that we should be designing. This is how we could split up our components, and then you could build a distributed system if you need it, even then, but and build it with all of that knowledge build up and with a lot more stability. And that's why I'm saying, like, don't, don't start with a distributed system in a startup. Like, I can't, I've done it. I can recommend it.

Brooke Jamieson 29:23

Learn from layla's mistakes. A new talk title for you.

Laïla Bougriâ 29:29

Yes, actually,

go ahead. Brandon,

Brandon Minnick 29:34

oh no, I was just gonna say, I agree so much. But also, I'm thinking about how, how would this really? How would this work in the real world? You know, let's say I'm a software engineer at a startup. Do Do I go around and talk to the Vice President? Do I how do we even know what the business the business is, businessing? Uh, as a software engineer,

Laïla Bougriâ 30:03

well, I think one of the advantages is that startups tend to be small, so there's less of that. Oh, I need to somehow talk to the VP, and I wouldn't even know how to reach them. There's a lot less of that. The startups I've worked with, I was working with the CEOs and the CTOs and and I would be able to have these conversations. And if I would be able to go back 10 to 15 years in the past, I would be having those conversations. And I would be saying, Hey, you are trying to get something on the market, and you want speed and you want flexibility. Software is not necessarily made to be incredibly flexible and right so, and we have to take so much into account, so we can give you all of that, given that at the moment that we start to stabilize, that you are also willing to reinvest back into your own product, and that we can then create that stability. I think, I really believe that that's a conversation that anyone should be having, whether you're, you know, you're a tech lady or the lead of the team, or you're someone that is part of a team, have that conversation first with your tech lead, with your team lead, and if, if they don't agree, and if they're not listening, well then tell whoever wants to hear it.

Brooke Jamieson 31:23

Yeah, I

think a good rule here is, if you're not getting asked good questions, you're not doing a good job of explaining it. That's always served me so well working in startups, because the other piece of this is startups as well, have a lot more coupling with their boards, I think, especially when they're in an early stage, even if it's just an advisory board of investors, and those boards really need to understand the risks and the risk register that they update pretty consistently. So if you're not working with the people who report into the board to help them update that risk register, because if you make this decision now, what's the risk of that changing in future, if you're not really helping them to understand, like they don't need to understand like they don't need to understand the technology, they need to understand the implications of it, and if they really start to understand the implications of the choices that you're making together, then they're going to ask you much better questions from it. So

Laïla Bougriâ 32:13

it just makes it easier, too, yeah, because you make a really good point, because if you would have to have this conversation with someone who's in a financial position right now, you could tell them, like, Okay, you're trying to build to kick off something off the ground, right? You're trying to create something. What do you want to do in the beginning, invest little, right? And you want lots of outcome from that. You want lots of profit from that. And once you have all of that profit. Well, part is going to be not only cashing out, but reinvesting it back into the product so that it can continue to evolve to the exposure that now it has and to the needs that it's now exposed to. And I think that if we try to translate our, you know, software, scaling and reliability and all of those fancy terms that we have into their language will will be a lot better off.

Brooke Jamieson 33:07

Yeah, for sure, even things like making sure they're getting ready to hire the people you'll need. So like, lo and behold, you're actually getting budget and funding to make some of this properly in future. Like, do the people in culture HR team. Do they know they need to be hiring a specific set of skills by that time to line up with that project starting so really keeping everyone in the loop of like the decisions you're making now, and just helping people understand it as part of the coupling in a way that will speak their language?

Laïla Bougriâ 33:36

Yeah, I think early on, it's a bit tricky, because there, there is the financial part to to look up for, right? But I think if you, if you have a couple of people on the team who have worked on larger systems and who understand what is needed to be able to build something like that, right, understanding the business access to to business people, that's, that's the biggest issue, I would say, in our industry, by far, is that usually software engineering teams, they don't have consistent access to business experts. They don't like, Oh yeah, you can schedule a meeting. I have an hour every other Friday. I actually worked at a bank for four and a half years, and I to this day, I would say that that was the most successful project I ever worked on. And the approach that we basically rewrote the entire mainframe with the.net application cool. And the way we did it is I was actually in the loans department. I did every calculation around loans that you can imagine was super fun to work on. Lots of numbers, lots of fun, and the way that we did this is what I would have to do to talk to a business expert. It was literally this turn around just behind me, someone who had worked like face to face with customers. Her entire career. So looking for a new opportunity, something different, she wanted to do something different. And they were like, Hey, we're rewriting the mainframe. How about you come and join our engineering teams and explain to them how this works? That's how I understood the business inside out, and that's still running stable. So that's I in that regards. I find that, yeah. I find that the biggest success that you can have as a software engineer is that your code 10 years later, so running in production. Yeah, perfectly fun.

Brooke Jamieson 35:33

I think people forget the most important language you can learn when programming, and that's the language that all of your peers speak in the office. So yeah, just honestly making friends with people. I called it the biscuit method. But this only makes sense if you know that in Australia, biscuits are what people call cookies. But like, I would bring cookies into the office and give people a cookie to answer various questions, or, like, do things, and it just, like, gave people a reason to come and talk to me. Or if I needed to ask people, it would be what I don't know, if it was a fancier place that I worked at at the time, I would have called it use of research. But instead, I just had cookies, and I would get such good information about, like, how systems worked, what they were coupled with, what their motivations were, even things that they had, like, tried to solve for in future, in the past, and it just wasn't working now. It saved me so much time just from like, being a friendly face that people would willingly talk to, which I did a lot of technical things there as well, but the cookies helped a lot. That's actually

Laïla Bougriâ 36:32

an amazing tip, and I'm gonna remember it for myself if I could seal it.

Brooke Jamieson 36:35

Biscuit method, yeah, it's a scientific approach.

Laïla Bougriâ 36:42

If it works, it works. Yeah, absolutely no. Actually, one of the, one of the interesting things as well, is that when we when, when we were working on this, it's also, it's also very interesting to them, because they get also insights behind the scenes and into what that means. And also, for us software engineers, we focus so much on learning technical stuff and the latest framework and and I understand it. I've done it for years myself, because there's so much to keep up with right right now I'm at a stage where I truly believe that technology is just a means to an end. I mean, it's going to change in next six months anyway, right? So it's really important to have an understanding of of what is available out there. And I'm not saying don't keep up, but I'm really saying that it's it. I don't believe that it's the key to success. The key to success for me will always be understanding what you're building what people are doing with it. One of the questions that I also always like to ask early, that in the beginning of my career, used to always be the afterthought that would then destroy everything, is reports like, what do you want to report on? And when you have that report, what do you do with it? Because the interesting part is that that's where a lot of the hidden business processes are, right? That's also one of the things that I cover in the workshop, is, how do you even identify which business processes you have in your organization? And lots of it is hidden from us, not because it's secrecy, but because they don't necessarily even realize that there is a significant business process there. But sometimes they'll say, Oh, yes, I use this report. I need it every week, and I'm looking at that number. Okay, what does that number mean? Well, if it's below five, then this and that and that. If it's higher than 10, then whatever else. Those are things that you want to know up front.

Brooke Jamieson 38:40

Yeah, yeah. User research around reporting is really, really interesting. So often people will say that they need a specific chart on a report or something, but so often it's because they're actually looking at a number next to that chart, and it's like a sign for them to know to look at this number. It's really interesting when you start getting in the weeds about, like, what people are actually using. And then, if you redesign it, like doing it in a way that the things that they care about are where they actually need them to be on the screen, it's so interesting, and it tells you a lot about like you're talking about these underlying processes. And I always really like as well, if they end up pulling any of the data out of a report and putting it in Excel or something, what are they doing? Because so many people have these, like, secret menu items,

Laïla Bougriâ 39:23

very complicated functions. And, yeah, yeah, yeah, absolutely. So that's definitely one of the things that I will ask early on and try to understand, what is it that you're doing with that data? And they always take these reports into meetings. What are you discussing? Because the meetings is where they share stuff across multiple teams. Yeah, coupling, right?

Brandon Minnick 39:50

Love it. So Leila, we're chatting before the show, and we have feels like a whole shopping list of resources on where do. Get Started code we can look at, yeah, what should we share first?

Laïla Bougriâ 40:05

Well, as I mentioned earlier, I worked at a bank for four and a half years, right? And when I was building my talk around orchestration versus choreography, I first I thought, I'm going to use retail examples, because everyone understands understands them. Everyone you know, can reason about it. And then I was like, for the life of me, I can't do this anymore. Like, it's just, we've talked about the domain so much that I was like, I need something else. I was like, Well, I worked at a bank. I kind of know what I'm talking about. You know, after four and a half years, so I used that domain. And one of the things I did is I started to discuss the loan broker example that many people who know Gregor hofi may have heard about. Now. He used this example to explain, for example, how you could orchestrate, and has examples on also how to do that with AWS step functions. And it's a really, really good example. I mean, his blog is full of like, just, it's a gold mine. Every book is written. It's and he's the father of messaging, so if you will, with the enterprise integration patterns, which I also dropped in the links for you, if you're interested. I love a prop. Yeah, yeah. It's really useful to be standing here, you know, doing this, and then hoping book is not by my, you know, nightstand or something. No. So, yeah, I started there. And then, interestingly, at the same time within the company, I work for particular software, another team has actually been working on the same example, and they've built the same sort of example, but using inservice bus in our platform to also showcase a lot of platform capabilities. Like, how do you create visibility into a structure like that? Like, what do you do when something goes wrong using observability with open telemetry and things like that. So that's available for you to try out. And a couple of my colleagues built this. You should definitely invite them over, Mauro and Sarah, and they could chat to you about this, probably for hours. So if you're looking for more guests, there you go.

Brandon Minnick 42:15

Absolutely

Laïla Bougriâ 42:17

yes. And then I went from this example, then going really deep into the domain that I've, I've helped build with a team back at a Belgian bank here and and it's, it's been a really interesting exercise. It's also been fun to work in a bit of different domain. And I think it can also be insightful for people, because the downside of reusing the retail domain. Okay, everyone understands it, but what I see a lot is people struggle applying it to a completely different domain. So what I'm trying to do is use the knowledge of this domain that I have to bring up examples that could work there, so that at least you have two examples. And that usually tends to make it at least a little bit easier to then go and apply it to even a third or a fourth domain.

Brooke Jamieson 43:03

Yes, humans need examples just like llms,

Laïla Bougriâ 43:06

yeah, I see what you did there. Brooke, yeah. So it's a it's an interesting new domain to discover, and let's see how that works.

Brandon Minnick 43:23

Yeah, that's such a good idea. Because I totally agree. I'll be sitting in a workshop, sitting in a conference talk, watching a video, whatever it is, and you're just going, oh, yeah, that makes total sense. I totally get it. And then, yeah, you get back to your your job on Monday, and you're like, Wait, how do I do that here for us? We're not selling T shirts or hamburgers like they were in the examples. So now,

Laïla Bougriâ 43:53

yeah, that's definitely one of the challenges. Yeah, so at least with another example, it can be helpful, yeah,

Brooke Jamieson 44:00

and it's why really talking to the business is so important, because you might think it's doing one thing, but if you haven't talked to enough people, it could be doing something totally different, like the number of people who just, like, can't give a straight answer when you ask what their company does is truly incredible. But I think when you really start, if you're going to be designing systems that really impact how, like ways of working and how the business actually runs. You really need to have a core understanding of the business. So I think, like if people are struggling with getting to that level of abstraction, what some good questions they can start asking to really start to unpack the core of what they're doing at the company. Do you have any tips? Leila,

Laïla Bougriâ 44:38

that's an interesting question. It's tricky, because this is something that for me, I've always been a very curious person. So even in the beginning, when I was still a junior and I would just have to, like, build out a simple use case, I was too curious. I was like, why is. This. What does this have to do with that? And, and I got told that I was annoying more than one time, and I don't care, because go figure that that was one of the best, best skills that I had, is just asking, Why is this, and why is that? And and taking this curious approach. Now, one of the things that I was also exposed to through a lot of colleagues, through udidahan, who's the CEO of the company as well, and and many others in the in the industry, is the concept of using anti requirements, which is basically when you start to look at certain things in your domain, attributes of of certain things, and you start to ask intentionally illogical questions, like, for example, if I change, if I change the image of a product, does that also impact the price? For example, and sometimes you'll get like these weird looks like, Why? Why are you asking this? Like, this sounds like such an irrelevant question. Like, do you even know what we do here? Right? Right? And I think it, a lot of it is getting comfortable with asking those sometimes irrelevant, or what we tend to call stupid questions, although I don't like that term, because they are not stupid questions, because they can really give you an idea of those things aren't connected at all. Well, fine, then don't put them together in a table. It's like they don't they don't change. They don't evolve together. They don't have to be together. And sometimes you will ask a question and then really find something that you just did not know, right? And that's where the gold mine is. Like, oh, I just uncovered a business requirement that nobody thought to tell me about because I asked this question. Also really good to make sure that you are not making assumptions, that you are making sure that you check, like, I'm assuming this is how it works, like, is really true, or am I telling this also here, this

Brooke Jamieson 47:05

is why I'm very passionate about rebranding stupid questions as brave questions, because it is and people is too nervous to ask them. Like, that's why people think they're a stupid question, because they're too nervous to ask them. But if you're the one that's actually brave enough to do it and put yourself on the line. This is where, like, you're talking about, this is where you really start to uncover what's actually happening. So I think if people are struggling with that, just tell yourself, it's a brave question, and it gets a whole lot easier.

Laïla Bougriâ 47:33

Yes. And even if they say, like, what? Well, fine, they've just given you, like, a very strong signal that those things are not correlated at all. That's a really good thing to know, yeah,

Brooke Jamieson 47:46

and especially to ask it like, that's why it's a good question to ask, especially if there's some sort of, like, you're worried about an external political factor or something like, that's why it's a great question to ask,

Laïla Bougriâ 47:57

right? Yeah? So yeah, I think I've, I've taken on this attitude of of trusting that, because it served me over the years. And I know that sometimes I'll think, okay, yeah, okay, that was not a super useful question. And I'm fine with that, because maybe the next one is and the previous was, and that's, I think, what we should focus on. But I do also believe that it's tied a lot to culture, right? You have to also be inside of a culture that you feel safe to do that and that people are not, you know, gonna look at you weird and think that you're incompetent. So I do realize that that's definitely a factor that can scare people off, for sure, but

Brooke Jamieson 48:37

it's also a way that you can drive that culture within your company, like when I'm talking about being more coupled with your executives, or even the board, having a culture where it's like encouraged to ask these brave questions is going to help save the company a lot of money in the long run, in many ways, and it will also help people to have those honest conversations a lot easier. So it's a great way of showing like culture and tech. People, for a long time thought that they were decoupled, but they're actually very finished. So I think it's a good way of showing that in practice. And you'll know it's working if the executives start being brave, too. Yeah, yeah.

Laïla Bougriâ 49:14

That's one of the things that I would love to see change, like, like, just change for once and for all, is the idea of the IT department. There should be no such thing. I mean, tech, tech is ingrained in our entire lives at this point, and tech is part of the business. It's not a separate department that is doing some stuff for us. And having a good connection between people that work on the business side and on the tech side is important because, I mean, it's like you learn from each other. Business people will also get insights from tech people who don't have a clue, because we're asking all of those brief questions, right?

Brooke Jamieson 49:51

Yeah, this is the thing that excites me the most about generative AI, I think, like as teams become, not. Necessarily smaller overall, but more smaller teams where they're working on, like, more directed efforts, those teams are going to have a mix of tech and business people in them, but Gen AI is going to help them have those conversations with each other, even if you think of like a hackathon, how much more big echoes here, like non technical person can get done in a hackathon by being really smart about how and when they're using generative AI, and what types of questions they're asking the models, and even what sort of information they're using to communicate with those models and each other. This is the piece of Gen AI that gets me the most excited, even in industries that have nothing really to do with generative AI, if they're just using it as like a dev tool in the background.

Laïla Bougriâ 50:38

Yeah, I think AI can definitely be an aid in that. And it also, it all comes back to this basic thing of communication, right? But I also believe that practice is really important. So one of the things that, for example, I really like about what we do in particular, is that whenever we have a meeting, that it's like company wide, right? And we have a technical product, right? So you tend to throw around a lot of technical lingo, but there are people there who don't have that technical background. And one of the things that we do by default is, when we use a term like that, we in the same sentence, explain what it is that we mean, but in humanly understandable terms, and by doing that in internal meetings where you're in a safe place with your peers that you know, that you trust, you build up that confidence on how, what kind of a metaphor would I use to explain this overly technical term, and you start to get more confident in adjusting your communication and Finding those metaphors and therefore improving your communication, also with people outside the organization, maybe customers and things like that, that can be really helpful.

Brandon Minnick 51:50

That's such that's such a great idea because, yeah, I've sat in meetings, and especially when you're when you're new to a team, new to a company, new to a role. Yeah, sometimes you'll be sitting in meetings and just like, am I the only one here who has no idea what they're talking about? And that's kind of where I started asking brave questions when I first started. So I was like, Well, yeah, I'm the new guy. I can get away with it, so I'll at least raise my hand, like, hey, you've said this word like, seven times. What? What does that mean? And then sometimes, yeah, you look around, everybody goes, Oh, that's what he meant, yeah. Nobody else stopped it.

Brooke Jamieson 52:34

Has this happened to you? Because it has absolutely happened to me. The number of times I asked about an acronym and I got like, different responses,

Laïla Bougriâ 52:44

absolutely right? And that's exactly what I meant with uncovering false assumptions, right. Because what's happening is that everyone is making an assumption on what that means, but it translates differently, like think of all of the things that we build wrong because of stuff like this.

Brandon Minnick 53:01

Yeah. Well, even measuring right, like there was that Mars probe that burned up in the atmosphere of Mars, because one team is using metric and the other was using imperial units. So you might, you might even mess up there, and, yeah, even in chat, you know, saying they found a lot of DEV struggle to do that. I'm myself a dev, and sometimes struggle to translate tech to English. And I, I love what you said, Leila, that if, if you can, if you can do that translation, it also makes you a better developer, because you have to to explain it. You have to understand it even better. You know? I can, yeah, I can type the code, I can click Compile, and I understand what the code's doing, but what's it really doing? Like, what's that next layer deeper? What's the bigger picture around it is so important.

Brooke Jamieson 53:55

This is, yeah, back on the generative AI thing. But like, so Amazon queue developer in the IDE in VS code, you've got a new thing that's called at workspace, and it goes across the entire repo you have open. And my favorite prompt I do like at workspace, explain this project to me as if I'm a 12 year old computer science student. So good, so good. And it explains the whole thing, like, what the pieces are doing, why it's important. And it just gives you, because I always make a lot of video content about different things, and I like to explain in my head, and then go and see how it explains it, even the ordering of things, how it unpacks it, is really interesting. And it's all of these things are going to help you to use generative AI to be able to explain things in a more human, friendly way, and looking at things in different ways, different abstractions, it's going to help you to apply those. So, yeah, let me know in the chat. If you've tried this out. It helps me a lot. I enjoy it, so give it a go.

Laïla Bougriâ 54:45

That's cool. I'll definitely keep that in mind next time I open a repo. Yeah,

Brandon Minnick 54:51

super helpful. Well, we've only got five minutes. We get cut off at the top of the hour, whether whether we end the show or still talking. But. Yeah, Leila, thank you so much for coming on. Where can people find you who want to stay a part of the conversation, who want to learn more? Where can they find you online?

Laïla Bougriâ 55:10

Well, I have accounts on most socials. So you can find me on LinkedIn, you can find me on Twitter. I will always say Twitter, X, whatever. You can find me on Mastodon, but I'm definitely most active and reachable, I guess, on LinkedIn, definitely number one place. So feel free to follow me there, or say hi or so. I also post content there, not always as consistently as I would like to, because life, but, but yeah, now and then you'll see something appear there from me, and you'll stay tuned also with what I'm working on and where I'm going through next. Thank you so much for having me again. It was such fun. We've diverse so much, but I feel like I've enjoyed this conversation a lot. Yeah,

Brandon Minnick 55:54

me too. We'll have to have you back for a third Layla show and Brooke likewise. Thanks so much for joining us today. Thanks so much for filling in for Francois. Where can folks find you online?

Brooke Jamieson 56:07

I put a link. I have a link to you that holds all of my links that I can update, and that is the easiest way, because there's a lot of platforms. There's always more coming. I don't even think I added threads to this, but incredibly online. If you look me up, if you search like AWS generative AI, probably I'll be there at some point. Yeah,

Brandon Minnick 56:28

love it. So, yeah, you can find Brooke at lick dot trees. Yeah, it's

Brooke Jamieson 56:36

handy. There's just like a wall of links, and it's so

Brandon Minnick 56:39

helpful, yep. So go to the slash. Brooke, Jameson, you'll see you're there. And again, thanks so much for joining us today. Thanks so much for filling in for Francois and and thank you. Thank you for watching. Thanks for listening. If you don't, don't forget to subscribe to our audio podcast. We publish it every other Monday, so you can find the show on your favorite podcast app as the.net on AWS show, and we're back here live every other Monday as well. So we'll see you again in two weeks for The next episode of the.net on AWS show. You