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.