Helping Each Other and Growing Together with Matt Coulter

• (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 together

• Personal Twitter: https://twitter.com/nideveloper 
• Belfast User Group Twitter: https://x.com/BelfAWSt_UG 
• Teach Me AWS website: https://teachmeaws.com/ 

Transcript

Matt: This is born out of our frustrations with it's so hard to do anything for the first time on AWS.

Corey: 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?

Matt: 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.

Corey: 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 You are a serverless hero, to my understanding.

You're a hero of some sort. Is it DevTools hero? I can't, I can't keep it straight anymore.

Matt: I live somewhere in between DevTools and serverless, so both groups claim me, so it's all right.

Corey: You're also a conference organizer for the CD, 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. Uh, 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?

Matt: 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, 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, you know, 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 went, 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.

We've 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.

Corey: 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, at 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.

Matt: 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.

Corey: So someone has a terrible time, uh, as far as the time zone goes, as far as when the call is going to be.

Matt: 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 in 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 and the sense of stuff already exists. People are already used to on a Monday at 2pm, I go here. So if you're now sent, please come here instead of going in your original route.

It's very different to just say click this link and join us whenever you're listening in the car on the way home, for instance.

Corey: Browser tabs are a lot cheaper than tickets to an event.

Matt: Yeah, and it's, 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, it, 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, 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.

Corey: You have to worry about things like venue space and even getting coffee is a logistical challenge. It's, I've often said that it's 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, 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 then a smattering of other places that I can't find on a map because we haven't been at war with those places lately.

That's how we as Americans learn geography. How sizable is the, is the community out there?

Matt: Yeah. So it's, 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 center. And they're, 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 kind 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.

Corey: Do you find that there's a particular sway that the community goes in when you, when you talk in Belfast versus globally? And, 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 about 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?

Matt: 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, that's really what the story is of this city.

Corey: 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.

Matt: It's funny because whenever 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.

Corey: Yeah.

Matt: Whenever, 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, 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 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.

Corey: 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, uh, 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.

Matt: 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, is huge. My, my thing is serverless was scales to zero, but also it was meant to be the undifferentiated heavy lifting gets put on the cloud provider. So I love 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.

Corey: 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.

Matt: Yeah, exactly. Like, 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 they've added things like container images to 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 the 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, 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, shoot a scale to zero, it should be cheap, and it should be minimum amount of lines of code to get people in the door.

Corey: 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, 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.

Matt: 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.

Corey: 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, 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.

Matt: For sure. It's the most difficult skill in AWS to be able to know the costs. So your job, I have so much respect for it because, uh, it's, it's an art form.

Corey: Yeah, it is not what I ever expected to find myself doing, but there was a need. I figured, 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.

Matt: Crazy, they were just waiting for you.

Corey: Exactly. You also have something else coming out in the somewhat near future, if we're allowed to talk about it.

Matt: Yes, we can, we can definitely talk about it here first.

Corey: By all means, tell the story. I dare not tell your story for you.

Matt: 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 TeachMeAWS. 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.

Corey: 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.

Matt: No, and full disclosure in the interest of the podcast, I'm not even AWS certified at this point.

Corey: At this moment, neither am I.

Matt: 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.

Corey: There's a, Definite strong sense of how to frame this. Uh, at least for me, that, I guess, aversion towards certifications. I've seen it 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 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.

Matt: It's interesting because like you said, 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.

Corey: I've found that as I look at the way that I learn things, I, the curriculum, 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 do you, how are you approaching this from the teach me AWS side? Is it videos? Is it blog posts? Is it something else?

Matt: Yeah. So it's, it's a little bit different in the sense of, um, 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 manual.

Corey: Haynes manual or Chilton guide, depends on what religion you have, but yeah.

Matt: 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 EventBridge scheduler and scheduling an event on EventBridge, not the same thing.

Um, 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, it's sort of combining jumping quickly, learn things with maybe a bit of, uh, you could follow the, 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. Uh, Tool 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 a problem.

Corey: Not being prescriptive around tooling is a big part of it. I always liked uh, 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 uh, 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, Toward this. I like your approach better than most that I see this sounds like something I would actually use.

Matt: The other thing we want to do is So the funny thing is, I am a TypeScript developer at heart, and Christie'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 got 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.

Corey: 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.

Uh, I want to cache to Kubernetes demanding YAML knowledge, but that's neither here nor there. But, but Terraforms, uh, HashiCorp's, uh, custom DSL, Chef had the same problem once upon a time. It's, I like being able to not have to pick up an entire new syntax and understanding of the universe. to use a tool.

Matt: The one gap that I still see out there that um, 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 uh, he was telling me that from his perspective, when you said the syntax, he 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, uh, like fighter jet cockpit for, um, 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 experience is 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.

Corey: 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 want, then you end 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.

Matt: It's hard because, um, I've, 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 CloudFormation, 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.

Corey: Oh yeah, especially since I found that a great way to, 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 codebase works. Because it turns out I'm bad at documenting even for myself.

Matt: Sometimes you think the whole thing was working and then, like today, I find out that, uh, 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 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, it's definitely like a day two is a big deal and I'm surprised more people aren't focused on it.

Corey: 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, it's the idea, it's the difference between a mad science experiment, or as I think of it, a shitposting 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 GitFlow with this, and, and go down that process, because no one cares, that is, that is not interesting to most people, and even the constraints are artificial when I impose it on something like that, so it's, it's not a, even a realistic example.

of what it is that I'd be talking about.

Matt: I know we haven't mentioned the buzzword of GNAI, but even the, 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, you know, like, so day one's getting a bit sketchier. at the same time as day two isn't solved.

Corey: 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 light of day is massively helpful just because we're all too close to the problems we are currently solving ourselves.

Matt: It's, it's incredible with a lot of this stuff that whenever, whenever I go to, you know, build something, the typing is the shortest part of the process. The longest part 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 architected 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.

Corey: That seems to be a sincere problem across the board, and also something you seem to be particularly passionate about.

Like, I am curious, between TeachMeAWS, your variety of different roles in the sense of what you do in the community, what What's the common thread that ties it all together? I find there's usually something in there that is, that is hiding out as far as like the actual narrative thread that ties things together.

Is there one for you or are you just sort of all across the board?

Matt: Yeah, I mean, the, 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, uh, I've done UI, UX, QA. UAT, development, architecture, product, like, I'm forgetting 50 60 roles of built machine learning models.

I've, 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, educate, and train, 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 100 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 the vision of we can do better, we can push forward, and we can build on each other's stuff.

Corey: I think that that's one of those very valuable things that, like, we keep forgetting the human too easily. Even, it's one of those areas where I find, as much as I, 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, you know, 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.

Matt: Yeah, but the one amazing thing about it is seeing the people who have spoken up, 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. 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.

Corey: Oh, absolutely. There are counterexamples. I gave a talk at community day early on. I think I gave that one dressed in a full cultist's 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 plane to Belfast.

Matt: 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. And it was worth it. It was so good.

Corey: Oh, 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 that 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 crapping 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.

Matt: Yeah, it worked out. I trusted you. I had faith.

Corey: 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?

Matt: 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 BelfastUG is the Twitter handle on there. For the community day that we're running, It is awsbelfast.

co. uk. That one's simple. Um, and for obviously the most important one for TeachMeAWS, it is teachmeaws. com. That one's easy.

Corey: 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.

Matt: Thanks for inviting me.

Corey: 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 5 star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a 5 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.