Screaming in the Cloud - Helping Each Other and Growing Together with Matt Coulter

Episode Date: July 2, 2024

Matt Coulter returns to share his latest endeavors as he makes a comeback in community work, especially within DevTools and serverless circles. In this episode, he and Corey discuss the significance of the Cloud Development Kit (CDK), CDK Community Day, and CDK Patterns. Matt reflects on his journey into community work and contrasts the challenges of virtual versus in-person events, highlighting Belfast's burgeoning tech scene and his aim to amplify its presence globally. Additionally, Matt discusses Teach Me AWS, his new venture designed to simplify AWS tools and foster practical problem-solving skills.Show Highlights: (0:26) What Matt’s been up to since the last time he was on the show(2:04) How Matt got started with community work(6:09) Learning about the Belfast community(9:57) How technologies are maturing and empowering users to do more(14:51) Matt’s latest endeavor, Teach Me AWS(19:25) How Teach Me AWS educates users(23:02) Big opportunities for Teach Me AWS in the day two experience(30:32) The thread that ties all of Matt’s interests and projects togetherAbout Matt:Matt is an AWS DevTools Hero, Serverless Architect, Author and conference speaker. He is focused on creating the right environment for empowered teams to rapidly deliver business value in a well-architected, sustainable and serverless-first way.You can usually find him sharing reusable, well architected, serverless patterns over at cdkpatterns.com or behind the scenes bringing CDK Day to life., Sr. Architect in Belfast. AWS DevTools Hero and @BelfAWSt_Meetup organiser loving #Serverless so I created @cdkpatterns / @cdkday. Co-Author @thecdkbook. he/him, Matt is an AWS DevTools Hero, Serverless Architect, Author and conference speaker/organiser. He is focused on creating the right environment for empowered teams to rapidly deliver business value in a well-architected, sustainable and serverless-first way.These days you can usually find him behind the scenes running the official Belfast AWS User Group and organising the Belfast AWS Community Day!!!Links Referenced:Personal Twitter: https://twitter.com/nideveloper Belfast User Group Twitter: https://x.com/BelfAWSt_UG Teach Me AWS website: https://teachmeaws.com/ SponsorPanoptica: https://www.panoptica.app/

This is born out of our frustrations with it's so hard to do anything for the first time on AWS. Welcome to Screaming in the Cloud. I'm Corey Quinn. My returning guest today is Matt Coulter, who is a senior portfolio architect at Liberty Mutual, but oh so much more than that. It's been about the Sunday since we've spoken, Matt. What have you been up to? Yeah, it's probably been about a year since we talked on this, and I've been continuing a lot of my community work. I took a bit of a step back for a while, but starting to build up again with a lot of the external work for patterns and things. This episode's been sponsored by our friends at Panoptica, part of Cisco. This is one of those real rarities where it's a security product that you can get started with

for free, but also scale to enterprise grade. Take a look. In fact, if you sign up for an enterprise account, they'll even throw you one of the limited, heavily discounted AWS skill builder licenses they got, because believe it or not, unlike so many companies out there, they do understand AWS. To learn more, please visit panoptica.app slash last week in AWS. That's panoptica.app slash last week in AWS. The community work you do has always been interesting and hard to classify, if that makes any sense. Maybe I'm oversensitive to that particular challenge, given I deal with some of it myself, but you do a fair bit of, you do a fair number of things. You're a serverless hero,

to my understanding. You're a hero of some sort. Is it DevTools hero? I can't keep it straight anymore. I live somewhere in between DevTools and serverless, so both groups claim me, so it's all right. You're also a conference organizer for the first Belfast AWS Community Day is coming up, and I'm sure we'll talk about that in a bit. You've done a lot of CDK stuff with the CDK Community Day, the CDK Patterns site that has been doing a lot of interesting things as far as not making me reinvent the wheel when I want to

do something involving AWS, which is deeply appreciated. Where do you start and where do you stop? The funny thing for me is, so I always try to start with external, which is why a lot of it is the community stuff that people see. Because for me, if I personally struggle with something, I'm like, all right, let's get this out there. So the next person doesn't. And a lot of it started with like the CDK work. A lot of it started bigger than it probably should have because whenever I started doing the external community work, it was over the pandemic. So everything sort of had a lens on it that amplified things. So instead of starting local and going global, I pretty much started global, created a conference that thousands of people have watched. And then when I don't like the fact that I haven't done as much locally as what I could have done, given I had all these eyes on what I was creating, which is why I started coming back

to Belfast and started up the user group here, which started doing regular meetings as opposed to, it was pretty sporadic in the past, how the local community could meet. And then the community actually approached us and said, can you run a community day? And that's where we're like, yes, let's go. That's the whole point of this. It's let's get people excited. Let's try and help other people and let's grow together. Running an in-person conference is a heavy lift. I've been in the periphery of a few of them myself.

There's a reason I don't do that as a primary rule. And online events are in many ways easier depending upon how you want to view your definition of online event. I mean, on some level, it's I'm doing a live stream, come and watch. Most go a little bit further beyond that. There's often a, there's interaction and the rest. I'm curious what you've noticed is the key differences between building events in person versus the virtual side of it. For sure. I definitely think virtual is easier in many ways because, for instance, with CDK Day, the organizing team was quite literally across the globe. We had most continents represented with the group that were just excited to come together. So someone is a terrible time as far as the time zone goes, as far as when the call is going to be.

Exactly. We had to rotate at all times to hopefully get most of the group. It was the same with speakers. We always had people asking us, could we run the event on the other side of the globe? Because, you know, like the main struggle with virtual is time zones for both organizers and speakers. Whenever you start going to in-person, you still have all the challenges you had with remote and that you need to make sure you get diverse speakers coming in. You need to make sure the event actually stands for what it's meant to stand for and doesn't, you know, like sell out immediately in terms of pushing one product or one point of view. It needs to be balanced. So that all still exists when you go in person. But then you also deal with it is quite literally the world around you in the sense of stuff already exists.

People are already used to on a Monday at 2 p.m. I go here. So if you're now saying, please come here instead of going on your original route, it's very different to just saying click this link and join us whenever you're listening in the car on the way home, for instance. Browser tabs are a lot cheaper than tickets to an event. Yeah. And it's people really need to believe in the event that you're hosting to give away their time to physically be present. And it's, I've discovered that that combined with it just costs, it does cost more money to run it locally, even though we we've had an amazing support from the companies and communities around here where we're running this thing on a shoestring budget.

But it's a case of like virtually you can just stand up StreamYard and away you go. You've pretty much got a conference. You have to worry about things like venue space and even getting coffee is a logistical challenge. I've often said that with AWS, it's amazing they can even wind up getting coffee for reInvent, let alone the orchestration of what that entire event must be to get across the line of its current production value. Forgive my ignorance on this, but do you find that there's enough of a community in the Belfast area to put together a conference? I mean, how large are you folks? This is also my American ethnocentrism speaking here, where it's like, wow, I figure that all

the people who care about this are in Seattle and San Francisco, and that is a smattering of other places that I can't find on a map because we have been at war with those places lately. That's how we as Americans learn geography. How sizable is the community out there? Yeah, so it's actually, I'm quite passionate about this one because everybody thinks of Ireland and they go straight to Dublin and think because like Microsoft's down there and AWS is down there that that must be the big tech hub for Ireland as a whole. But Belfast is very, very dense in terms of tech companies in the city centre. And they're not just pure tech companies, you know what I mean? People that just build tech for tech.

We're talking about the tech hub of like insurance companies, finance companies, those kinds of things. So whenever we started running these events, we've, uh, without very much effort in terms of marketing, the numbers have been 50, 60, 70 people turning up to just the regular user group. And given that that's been growing every time we run it, we're pretty sure we'll easily get over a hundred pretty soon just in the regular user groups. So it's, it's sizable and it's a voice that hasn't really been represented on a global stage because I don't hear my accent very often. So it's, it's a motivation for me to try and get more people in America to know the name Belfast.

Do you find that there's a particular sway that the community goes in when you talk in Belfast versus globally? And what I mean by that is I used to live in Los Angeles, but I was doing a consulting project in Iowa every week for a while. And when I went to user group meetings in Los Angeles, we talked about things like how to, in this era, 2010 or so, it was speeding automation. And when I went to Linux user group meetings out in Iowa,

instead, they were talking about how do you sneak Linux into your primarily Windows work environment, which was a bit of a different flavor and a somewhat extreme example. But do you find that there are smaller or more common areas of focus in a local user group as opposed to a global one? For sure. I mean, locally, the big thing people are known for here is the serverless community is very strong here. But even outside of that, the thing that Belfast is known for is engineers and people in the software development industry as a whole can churn well-architected solutions out quickly. So the focus here is really on,

okay, this is great. What did you build, but what was the impact? And then what can I take away from that? So people are very willing to pivot as opposed to jump in and be like, this is my technology till I die. So you get these fascinating stories of these big companies out there that someone from Belfast was almost dropped in and they saved them and then just left again. And that's really what the story is of this city. I saw a great tweet this morning where someone was talking about how Docker is dead and Kubernetes is dead and serverless is dead. If of course by dead, you mean it is now established, stable, and there are defined processes around it rather than figuring out everything as we go.

And that resonated in a bunch of ways, just from the idea that now it's not about the technology anymore so much as it is about what the technology empowers folks to do. It's funny because whenever the term serverless is dead got out there, a lot of people had this real visceral reaction to it where it was like, if it's said on social media, it makes it true almost. And there's always something behind it whenever it goes that deep. But I think the interesting thing about it is the marketing has shifted and that's where people are saying that, oh, I feel like it's not what I signed up for, but it has matured to the point that now it's not the risk it once was to say, let's build a serverless architecture. It meets most needs, but at the same time, the complexity has grown that it's not just, well, it just works. It's somewhere in the middle. And it's the same with the likes of Kubernetes. Whenever it started out, people said, oh,

it's so complicated. I can't go near it. Whereas it's almost simplified over the years to the point that people are like, it's almost easier to run it on Kubernetes. Whereas it's almost simplified over the years to the point that people are like, it's almost easier to run it on Kubernetes. So it's technology just doing what technology does and rapidly evolving to meet the user needs, which complicates and simplifies things in different ways, depending on what the users want. There's something to be said for being able to interoperate with other technology stacks as they grow. My take on serverless is dead, is somewhat controversial. And I assure you, I'm not trying to bring toxicity to this, but I am curious to get your take on it, where I have been increasingly disheartened over the years as AWS has started

referring to things as serverless that don't align with my or some other folks' perspective on what serverless is. Because originally when it was launched, a fundamental aspect to it was that when you're not using it, it scales to zero. So you only pay for what you use. A growing number of services that are badged serverless, Redshift, Aurora, and a few others, don't scale down to zero. They scale down to a minimum number of units that still cost tens of dollars per month per instance. And that's always irked me because it breaks a pattern I love with serverless. Take something like DynamoDB. Every feature branch for every developer can have its own infrastructure because there's no real cost associated with it beyond just storage. That's been, I guess,

the thing that's been irking me. I'm curious to get your take on it. I'm sure there's nuance and aspects I'm missing. I do agree with you in the sense of like, that's what I love about Lambda and Dynamo and SQS and API Gateway, even though API gateway, I've complained about it a lot because it's the most complicated way to just add a URL to a Lambda function. But the whole premise, I can stand it up on my personal account and the cost will be one cent, you know, like it's not going to be a lot. And then I delete it all and it's gone. Whereas if I tried to do anything with the traditional tech, you're going to need to add a credit card to that and you're going to need to worry about it.

And yeah, the big premise of things scaling down to zero is huge. My thing is serverless was scaled to zero, but also it was meant to be the undifferentiated heavy lifting gets put on the cloud provider. So I love that it turned off, but also we had that before with things like Heroku and these various platforms that you could just put a container in and they would just auto scale up and down to zero. And terrible VPS providers before that. Oops, the service just turned itself off. We don't know why. Neither do they. Apparently we'll come back in six hours. Yeah, exactly. So the scaling to zero is awesome for people to experiment with,

but there's a certain point where if you're building for a company, the scale of Liberty, the savings are less than you'd think it would be on a production app by the time you add in all the configurations that we need in order to meet all of the compliance. Um, so, but where it still hits us is that, like I said, the undifferentiated heavy lifting is still on the developer. So now that divided things like container images, the Lambda, all of a sudden it has all the dependency issues that it would have had if I deployed it to a container platform. Whereas Lambda was meant to handle all those things for me because out of the box, I was only going to send it the class file that it was going to have the logic in. And it was meant to be like 12 lines of code. So the underlying way that we develop

with serverless has shifted, which has meant that the piece I loved is kind of niche now. And I think it's okay, but it definitely has made it harder for people to get started because like you said, should it scale to zero, it should be cheap and it should be minimum amount of lines of code to get people in the door. I think that people adopting serverless on a cost basis is a bit of a post hoc justification. People, in my experience, tend to adopt things because of the capability story, especially when it comes to cloud. Now, yes, pricing means some things are complete non-starter. Oh, I took one look at the pricing page. We'll just close that browser tab and never go back there because I don't have that kind of scratch. But there are other stories where it leads to a cost savings, but that's not the reason

that people build processing queues with Lambda. It's because the capability story is there, the lack of maintenance overhead is significant, and you're effectively letting the cloud do the undifferentiated heavy lifting, and you can stop solving global problems locally in somewhat significant ways. That's something that I think

is what led to a lot of the excitement around serverless. The fact that it was less expensive was just a nice cherry on top i would argue most developers didn't know the cost of what they were deploying before serverless came along they just used the best developer experience well now that we're using serverless i would say that almost no one understands the cost of what they're deploying in an absolute sense unless they've really done a great job of instrumentation which i am as guilty as anyone else in not really having that across the board as well as I would like.

In theory, it's great. You can figure out the cost per request or per thousand requests. In practice, I find that's one of those aspirational items on the to-do list. For sure. It's the most difficult skill in AWS to be able to know the cost.

So your job, I have so much respect for it because it's an art form. Yeah, it is not what I ever expected to find myself doing, but there was a need. I figured, oh, I'll fill this for a couple of years until the problem goes away. And it somehow only ever got bigger and bigger and bigger. There was no magic solution here waiting around for folk. Crazy. They were just waiting for you. Exactly. You also have something else coming out in the somewhat near future if we're allowed to talk about it. Yes, we can. We can definitely talk about it here first. By all means, tell the story. I dare not tell your story for you.

Yeah. So it's something that Christy Peralta and I have actually been working on together. So Christy is another hero in the AWS community, and we've been working on a product called Teach Me AWS. This is born out of our frustrations with it's so hard to do anything for the first time on AWS. And by that, I don't even mean, like I do mean, but I don't just mean the first person in the door whenever you're like, I want to learn AWS. I've never touched it before. I mean, I haven't gone back to EventBridge in six months. What does it do now? It is very hard to catch up the second that you stop. And that's why we are trying to launch a product that should make it really easy

for you to be able to go in and understand exactly what capabilities are there, which ones realistically you shouldn't be using at this point in time, unless there is a niche use case for it, as well as provide you with the code CDK pattern style that you can actually just get up and running with those features so that ideally you don't need to go anywhere else than go to TeachMeAWS and you can catch up with every piece of it and get going. Few things are better for your career and your company than achieving more expertise in the cloud.

Security improves, compensation goes up, employee retention skyrockets. Panoptica, a cloud security platform from Cisco, has created an academy of free courses just for you. Head on over to academy.panoptica.app to get started. One thing I notice about most things that teach people how AWS works is they have an either explicit or implicit drive towards the certifications. As in, okay, effectively they wind up in the fullness of time teaching to the test. What you're describing does not sound like it's headed in that direction. No, and full disclosure in the interest of the podcast,

I'm not even AWS certified at this point. At this moment, neither am I. Because as far as I'm concerned, certificates are great, but in terms of whenever you're on a dev team and someone just says, okay, we need to build this feature, the certificate doesn't necessarily help you in that moment. Whereas if you have a tool that can turn around and say, okay, you're trying to build some kind of event-driven flow, let's talk about it. These are your options. All of a sudden, you've now gone into direct problem solving and meeting the needs of the user instead of, well, the certificate wants me to know that SQS has this feature and blah, blah, blah. You know, it's one is very textbook.

I need to know this knowledge. And the other one is I have a job to do and I need to get in and quickly solve this thing. There's a definite strong sense of how to frame this, at least for me, that I guess aversion towards certifications. I've seen in other people and I've noticed it in myself, and I only recently picked up the vocabulary to explain what it is that rankles me about it. And it's that they tend to bias for process rather than results. And in some cases, yes, that's terrific. And for some folks, that's awesome. But that's always been nails on a chalkboard for me. It's why I don't do well in academia. It's why I don't do well in large companies. It's why the military is certainly not for me. And certifications have

always felt like they teach certifications from the vendor perspective and the world a vendor imagines. And trivia is not really the best way I've found to assess someone's ability to get things done. So it's always been strange to me, but I don't want to be too negative about them because some people find that that resonates with them. And especially early career, it acts as a differentiator and unlocks value. I'm not dunking on people who go for certifications. Truly, I'm not, but they're not for me. It's interesting because like you say, people work in different ways. And I find that my particular skill set is I can amass a large amount of information really quickly to solve a problem and then it's gone. So the idea of keeping all the certificates up to

date is a nightmare for me because that would just be constantly me trying to absorb all this information, do the exam and then forget it all. But it does make me really good at solving problems and architecting and doing my day job. But for other people who have that more process driven flow, like you say, the certificates are brilliant for keeping that information up to date. It's just some people work in different ways. I've found that as I look at the way that I learn things, curricula, a standard classroom instruction do not work for me what does is you have a problem to solve go solve it have fun and that's awesome if there's a problem that i can that i can throw myself out in the right way whereas with with a lot of the way that these

things work it's like oh here's how to learn how to do this thing and i won't remember that eight months from now when i need to actually do that thing for real. I'm going back to look it up. How are you approaching this from the Teach Me AWS side? Is it videos? Is it blog posts? Is it something else? Yeah. So it's a little bit different in the sense of, so we want to have a couple of different angles to it. The first one we almost described as, I think this translates to America and no one's a big UK thing, but whenever you buy a car, you used to buy the Haynes manual, which you opened it up and it told you everything about the gearbox, the Haynes. Haynes manual or Chilton guide, depends on what religion you have, but yeah. Yeah. So that's, we need that for every piece of AWS that you can go in and you can just like look up EventBridge and be like, oh, okay, I see this particular flag

I can set or this particular property. I see that, for instance, there's a difference between the event bridge scheduler and scheduling an event on event bridge, not the same thing. So like, there's that kind of people who just want to jump into an answer. There's the videos that you're talking about where somebody goes through and breaks it down in a more visual form. But then also there needs to be exercises almost with guardrails around it that say, okay, we're going to deploy something for real. And we're going to make sure you do it in a way that it is for real. It's not a case of let's click a few buttons. You've got something deployed, but if you put this into production, let's be honest, it's going to be a tier one breach tomorrow. So it's sort of combining jumping quickly, learn things with maybe a bit of, you could follow the video feed channels to be

like, okay, we just like the vibe with, I want to do practical exercises and learn on these things. And it should all be done in a way that it's too agnostic because I always felt that CDK patterns downfall was that CDK was in the name. So it made it really hard to pivot to help other communities. So therefore, this will support, you know, like CloudFormation if you want to do it. Obviously, CDK, SAM, whatever else makes sense in different programming languages to try and make it one place that you can really come back and build that habit of going through different exercises, different days or dip in and out to solve the problem. Not being prescriptive around tooling is a big part of it. I always liked Ian McKay's

Console Recorder 2 extension, because what that did was it watched whatever API calls you made in the console and then spit out CloudFormation if you wanted it, or Terraform, or Troposphere from back in the day, or here's how to do it with curl requests or the AWS CLI. It's amazing stuff. It's not prescriptive about how to do this in any particular language or tooling framework. That, I think meeting people where they are, people are in a lot of places, goes a long way toward this. I like your approach better than most that I see. This sounds like something I would actually use. Thanks. And the other thing we want to do is, so the funny thing is I'm a TypeScript developer at heart and Christy's a Python developer at heart.

So therefore we're going to try and bake the best practices of the languages we know best into it. And I mean, we've all come from an enterprise, so Java, I have a very heavy Java knowledge set. So we'll obviously try and support those developers who've been long neglected in this space. Yeah. My first outing with the CDK was with Python when it was not very well baked. So I

picked up enough TypeScript to learn how to stumble through that, and I finally got it, and that was great. But yeah, learning a new language to understand some sort of tooling has always been strange for me. That's my challenge historically that I've always run into whenever I have to deal with the nonsense of a different tooling that requires its own specific language. I want to cache to Kubernetes demanding YAML knowledge, but that's neither here nor there. But Terraforms, HashiCorp, CustomDSL, Chef had the same problem once upon a time. I like being able to not have to pick up an entire new syntax and understanding of the universe to use a tool. The one gap that I still see out there that

there's big opportunities for is the day two experience of all this stuff, because day one, it's awesome whenever you can use your same tools. But I remember, I don't know, 18 months ago, I talked to a lad from Wing, formerly AWS, who built the CDK. And he was telling me that from his perspective, when you said the syntax, you reminded me. The reason why he created a new programming language in Wing is because he wanted to build a new experience on top of the cloud and have this almost, he called it, he's probably changed his term since then. I should really check what the new marketing is, but this like fighter jet cockpit for developers where they don't even need to leave it, you know, they

understand everything that's going on. And I do still think there's a real gap today in that even if I can hold your hand to get you to deploy a solution on AWS, because the whole platform is 5,000 individual pieces that you can stitch together yourself, it is very hard for people on day two to understand if they weren't there. Number one, what you deployed. Number two, how well architected it is. And number three, you know, are there any kind of logs, dashboards, metrics? What's going on? How do I even diagnose where the errors are in this thing?

And that's day one. We want to solve the idea of, okay, let's use a piece of AWS. But the longer term vision, I do think that the day two experiences where people have picked up on the patterns and then stopped and been like, we got people to production day one. That's good enough for us. And that's where we need to solve next.

I've encountered myself the pattern where I'll set something up with serverless or the serverless framework historically, or the CDK, and then it just sort of works as its own little microservice. I don't have to touch that thing again for years at a time. And then I go back to do that. It turns into a half-day project every time I do because, oh, there's several major language versions behind

now and I have to wind up doing a bunch of updates to the code base and dependency hell where things start breaking left and right. It feels like it's almost like even to change a single string in this thing, I have to rebuild a tool chain in order to get there. That's always been challenging. I'm starting to think that the right answer here is to have a CICD build automatically on a scheduled basis, weekly or monthly or something. And then when it breaks,

you go in and you fix it iteratively rather than having to go and spend half a day on it every time it breaks. But then again, you still, then you wind up spending a lot of time throughout the year on things that don't need to be touched. And I can see both sides of it. It's still frustrating. It's hard because I've talked about in the past where I would love a way almost that you can tag out of using a tool like CDK, because I know you

can't straight export to cloud formation, but it's whenever I say tag out, I want a way to tag back in again, because I see these tools as a developer accelerator when they're in the mindset to do some kind of large change. Like you just said, when the thing is stable and you're not making many changes, it's more effort than it's worth to keep all the dependencies up to date. And you can, like you just said, like automate it where you do your regular builds and things, but it is a constant reminder in the back of your head. So if you could tag out to something else serverless, that you don't need to worry about the burden of it. And then whenever you want to come back to do

your development work, all of a sudden you can spin it up again in Python or TypeScript or whatever, do your code, check it back in again, and then not worry about maintaining it until the next time. I think that's what everybody wants. It's just no one's worked out how to do it from a technical perspective yet. Oh yeah. Especially since I found that a great way to relax some of the Lambda constraints was to run Docker containers where you can specify exact libraries, versions of it and the rest. Awesome. But then it's just this opaque thing. You can't really edit the one line string you need to change in there. And oh great. Now we're trying to remember how this whole code base works because it turns out i'm bad at documenting even for myself sometimes you think the whole thing was working and then like today i found out that my sqs queue was sending a bunch of things to the

dead letter queue because of one configuration in sqs that you have to tell it that you've throttled the lambda function down and if you don't set that flag all your events just go straight to the dead letter queue and you you know like it's's stuff like that, that if you make a tweak, you've come back six months later and you forget that you'd even set up a dead letter queue on that to check it. So it's definitely like a day two is a big deal. And I'm surprised more people aren't focused on it. I am as well, to be perfectly honest with you. There's a, there's a strong sense that in what I'm seeing that people are just trying to get the thing

out the door today to make it work and not operationalizing it, not thinking about, okay, it's great now that it works, but when it suddenly stops working for a variety of reasons, what is that going to look like? It's the idea,

it's the difference between a mad science experiment or as I think of it, a shit posting app that I build for funsies and something that actually has to bear production workloads at serious companies and that i think is it's a bit of a strange i guess metamorphosis because me building something ludicrous and putting it on the internet is amusing for everyone no one really cares and now here's how i'm going to make this something that multiple people can collaborate on and here's how we're going to do get flow with

this and and go down that process because no one cares. That is not interesting to most people. And even the constraints are artificial when I impose it on something like that. So it's not even a realistic example of what it is that I'd be talking about. I know we haven't mentioned the buzzword of Gen AI, but even the tools that are out there

that help you generate the code as you go, I mean, they're only making all of this worse from that perspective of it helps you get something working really quickly. But I would not put that in production without somebody who knows what they're doing, taking a look at it first. And like I said, day one is getting a bit sketchier at the same time as day two isn't solved. Peer review is wildly important.

Just it's not doesn't matter how good you are. It's having someone who isn't you reviewing some of this stuff before it sees the of the process is sitting down, understanding what the root cause of the problem is, and then, you know, like working out what the well architect thing is to do before you type. And a lot of that I was thinking about that has changed massively since I started my career to now, because I mean, whenever, before I even worked for my current employer back, back, back in the day, I worked for people who didn't even use version control. You just uploaded the files to the file server and kept going. And from there to where we are today, you used to do code reviews in front of 20, 30

people in a room where you'd call everybody in. You'd go line by line through, you know, enterprise Java and people would be like, oh, I don't think you should use string builder there or very specific concerns. And then you've come to where we are today with pull requests and automated CICD pipelines. And I just think as much as I do believe in trunk-based development, whenever you're trying to learn and get from the team around you, pull requests are very underutilized for knowledge exchanges, given how averse we are to talking. That seems to be a sincere problem across the board, and also something you seem to be particularly passionate about. I am curious, between Teach Me AWS, your variety of different

roles in the sense of what you do in the community, what's the common thread that ties it all together? I find there's usually something in there that is hiding out as far as the actual narrative thread that ties things together. Is there one for you or are you just sort of all across the board? Yeah. I mean, the narrative thread for me was, believe it or not, I've been in multiple roles in the industry at this point. I mean, I've literally done nearly every role there is in terms of, I've done UI, UX, QA, UAT, development, architecture, product, like I'm forgetting 50, 60 roles of built machine learning models. I've done a lot. And the common thread I saw across it all was doesn't matter how much work I personally put in, because no matter how much I output, it's always going to

be less than what the team can do. And even if by some sheer miracle, I could personally deliver more than a team of six, that that team won't be able to maintain it or add a single feature to it tomorrow. So if you start focusing on the people around you and then the people around them and the people around them and trying to remove barriers, lift people up, educate and try and almost remove those stigmas around certain technologies and certain, because people, for whatever reason, we all get in our own groove and we don't want to look outside of what we're used to looking at. If you can get people to even 1.01 what they were before you started and you scale that to a hundred people, it's probably more than

you at your maximum output. And I've, I've seen that even from, I mean, a team perspective, a company perspective, but a country perspective in that I would just, like I said, I mean, I don't talk about it very much, but as someone who does come from Belfast that had a lot of problems in the past, a very divisive community, For me, it's really awesome to see people working together, not looking backwards, looking forwards, and actually setting a vision of we can do better, we can push forward, and we can build on each other's stuff. I think that that's one of those very valuable things that we keep forgetting the human too easily. It's one of those areas where I find as much as I care about this stuff and want to,

I still find myself taking shortcuts mentally and forgetting that there are people behind a lot of the things that I'm talking about sometimes. I think that that's one of the reasons I love community is it sort of forces you to do that. It's the reason I love conferences. It forces you to talk to a human being on the other side of the aisle. It's a valuable thing. And I think we need a lot more of that than we get. I just wish it weren't so annoying to put on physical conferences. Otherwise, I think we'd see more of them. Yeah. But the one amazing thing about it is seeing the people who have spoken at, or in some way been involved in something like CDK Day and where they were when I met them and

where they are now. I mean, half of them are heroes, community builders doing amazing things around the world. And I'm like, I knew you a couple of years ago. And so you do get like the way you're doing this podcast, that it must be amazing to get to see people's stories evolve over time. And I do think that makes up for the annoyance of running the thing eventually. Oh, absolutely. There are counter examples. I gave a talk at community day early on. I think I gave that one dressed as a full cultists robe because I was, I called the CDK a ridiculous cult once, and then I understood it and used it a lot. Now I'm a member of the cult, please join my cult with me. And I thought that was a great approach. Hard to pull that off on a conference stage, easier in a video, but it's a, but that's an example of being able to tell a story in an engaging way. That's fun. Taking advantage of

the medium that it's in. I love the experience. It's a lot easier for me to give a talk on a camera than it is for me to hop a talk on a camera than it is for me to hop a plane to Belfast. Yeah, for sure. And I remember whenever that talk came in, everyone was like, oh no, can we play this? And I was like, listen, I trust Corey. This will be funny. This is what it's all about. It was worth it. It was so good. I have a standing policy. I think people don't understand necessarily that I don't make people regret giving me a platform or inviting me to things. Like, yes, I will go and savage corporate keynotes. You're broadcast to the entire internet. But if you invite me to speak at your conference, I will not make you regret that by frapping all over the

conference or your major sponsors or all the rest. It's like, I'm not difficult to work with. And I sometimes get the sense that people are surprised by that. It worked out. Yeah, it worked out. I trusted you. I have faith. Well, thank you. If people want to learn more about all the things you're up to, where's the best place for them to go? Or in this case, places. If you want to know what I'm up to, you can follow me still on Twitter, or as people are calling it X these days, NiDeveloper. So NiDeveloper is my Twitter handle. If you want to know about the user group, there's also Belfast UG is the Twitter handle on there. For the community day that we're running, it is awsbelfast.co.uk. That one's simple. And for obviously the most

important one for Teach Me AWS, it is teachmeaws.com. That one's easy. Links to all of that will be in the show notes, though with that many, you have to click to expand the show notes in most of the podcast players. Thank you so much for taking the time to speak with me about this. I really appreciate it. Thanks for inviting me. Matt Coulter, Senior Portfolio Architect at Liberty Mutual and oh so many more things. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud.

If you enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment as well that I'll later read and dismiss as being not real serverless.