December 17, 2025 • 40 mins
Why do so many “modern” platforms feel slow, fragile, and painful to work on?
Platform engineer and fractional CTO Brian Childress joins Cory to discuss how over-engineering, resume‑driven development, and scattered tooling quietly block teams from shipping value. They explore why simplicity is a competitive advantage for platform teams, especially as AI becomes part of everyday development.
You’ll learn:
- How to design a simple platform MVP that developers actually like using
- What a good local‑to‑prod story looks like (and why it’s the real scaling superpower)
- Practical ways to onboard humans and AI tools so both can contribute faster
- Where teams introduce unnecessary complexity with Kubernetes, microservices, and NoSQL
- How to think about scaling in three dimensions: users, developers, and features
- Why good architecture, docs, and decision records make AI more useful, not less
- How to spot and avoid resume‑driven development before it explodes your platform
Whether you’re cleaning up a messy stack or trying to keep a young platform from drifting into chaos, this conversation gives you concrete patterns for keeping things simple while still scaling teams, systems, and features.
Guest: Brian Childress, Platform engineer and fractional CTO
Brian Childress is an accomplished Software Engineer, Architect and Fractional CTO. For over a decade Brian has developed applications in healthcare, finance, and consumer products. Brian has spoken internationally on topics such as application security and developer tooling. Brian spends his free time researching and teaching the latest in application and API security design and best practices.
Links to interesting things from this episode:
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:13):
Welcome back to the PlatformEngineering Podcast. I'm your host,
Cory O'Daniel. If you haven'tgot to hear the past couple of episodes,
we had three episodes back toback with Kelsey Hightower guest
hosting. Go check those out.Those over the past, I think, two
months or so. And then lastweek we had a really great episode
on Policy as Code and Kyvrno.I would definitely check it out.
Not to scare Brian, but it isby far my most clipped episode I've
(00:37):
ever recorded. It has so manygreat takes. I've got Brian with
me here today, though he isnow on the spot, he's going to have
to have a ton of great takestoday. We've got Brian Childress,
he's a technology leader,fractional CTO. He helps teams simplify
platforms, improve developerexperience, and build goingto getintosomeoftheproblems
heseesmostoftenwhysimplicitymattersmorethanpeoplethink.Andalsoonhow.How AIis
(01:02):
shiftingthe waywebuild also onhow AI is shifting ,Thankssomuchforjoiningus,
t.
Cory, man, it's behere.
Yeah. Where are you based out of?
Richmond, Virginia.
Richmond, Virginia. Okay. Sofor folks that aren't familiar with
your background, you wereactually an outdoor guide before,
like getting into technology.
Yeah. Yep.
(01:22):
You did the reverse of what Ithink every software engineer I know
wants to do. They're softwareengineers and they're like, "Oh,
my gosh, I'm over this. WhenAI is here, I'm moving out into the
woods and I'm going to be anature guide." And you're like, "These
woods ain't for me. I'm gonnago sit in the data center." What's
going on, man?
That's basically whathappened, man. So, yeah, early on,
(01:43):
when I was looking at going tocollege and all of that, I followed
the advice of, "Follow yourpassions and you'll never have to
work a day in your life." AndI was passionate about rock climbing
and kayaking and all the funadventure outdoor activities. And
so I went in and got a degreefocused in that area, went and guided
for a few years. Absolutelyloved the work, really enjoyed it.
(02:06):
But I found it was reallymissing something. One, it didn't
pay amazing, so that was partof it. But I really wasn't getting
the kind of the intellectualchallenge that I was looking for.
And so I went on a hunt tofind something else and landed in
technology. It's funny, when Ifirst started, I was like, "Man,
(02:26):
I don't want to be the guysitting behind a computer for 8,
10, 12 hours a day." And, youknow, heck, now I spend 14 hours
a day behind one and love whatI do, so it's good.
That's very cool. So when youfirst, like, did the transition,
was it just like, "Hey, I'mgonna go, like, back to school. I'm
gonna go get a degree incomputer science"? Or was it just
like, "Hey, I'm gonna go startlearning the program on my own"?
(02:48):
Like, how did you move overinto this world?
Kind of a little bit of both.The intermediate step was I went
back to graduate school andfocused on Geographic Information
System, so GIS.
Right, okay.
Maps and, you know, big datasets and that kind of thing. And
when I got into it, we, youknow, as part of it... as, you know,
data manipulation and all ofthat... started to learn Python.
(03:10):
And at the time, you know, 20years ago, I thought Python was an
outdated language that, youknow, I was like, "No one's going
to ever use this." I was wrong.
Yeah, a tad.
Yeah. So I got into it, reallyfound that I enjoyed, like, the building
aspect of it, the creation ofsoftware, and just, you know, it
snowballed from there. Icontinued to kind of work in my graduate
(03:33):
work, but then I was also,like, learning all sorts of different
languages and frameworks onthe side.
I feel like everybody I knowthat... when I look at, like, my
friends that come fromdifferent backgrounds that work in
software... I've got buddies,you know, they went to school for
whatever, they're doing theirjob for, like, 10 years, and they
went to a boot camp. And Ifeel like all of those people are
(03:55):
just, like, fully in theJavaScript camp. And then whenever
I meet somebody who's like,"Hey, I'm into software now. And
I came this way throughPython." They always have like a
very interesting, like, worldthat they came from. That like Python
was introduced that, like,caused that. Like, I have friends
that work in, you know,research, like, doing cancer research,
and they're like, "And now Iwork in AI." It's just like they
(04:17):
move over. And Python is... Ifeel like it's a gateway drug for
people that have reallyinteresting careers just kind of
slowly becoming absorbed intothe cloud. That's cool. Yeah. Python
was a very... I feel like overthe past few years, Python was quite
the surprise of a language tocome in and start to dominate so
(04:39):
many areas. I feel like I'vealways programmed in Edgy cool languages,
like Elixir and Erlang. Andthen just seeing just the proliferation
of JavaScript through the endof the two thousand tens and then
just Python's everywherenow... was very, very surprising
to me. When you go in and workwith teams, like how are you working
(05:00):
on those things? Are you goinginto teams that are doing like Python
AI stuff? Are you going in andkind of doing fractional work at
all different types oforganizations? Or are you focusing
more on the AI side of the house?
I mean, AI is definitelyfoundational for every project that
I'm working on now. I tend tocome into projects once they're already
kind of up and running. Theyhave... call it an MVP. They have
(05:24):
something working, they havepaying customers on it, and they're
starting to hit some scalingchallenges. That's typically where
I come in and really help tostabilize. And often it's just simplify
what they have so that theycan actually start to think about
scale.
Yeah. So like with all theteams starting to, I guess, experiment
with like AI projects now, Ifeel like it's... I mean it's obviously
(05:47):
everywhere now. How this endsup in the next couple of years we
will see. I'm not necessarilyas excited as my face says that I
am, but there's so many ofthese teams that they're building
something new, they'rebuilding stuff in AI. With all the
orgs you've already workedwith, kind of the experience you've
seen, what do you think issome of the most common, I guess
(06:08):
hurdles or problems for likeearlier stage teams? These teams
that have this MVP, they'restarting to see revenuea,andndtheywant
to start using AI. What istheir biggest hurdle to having a
successful use of it? Is itmore so using it internally for building?
Or is it like actually gettingto that point where it's a part of
their product? Because I see alot of teams doing it and I also
(06:29):
see like these reports of like90% of orgs are not seeing value
on the other side. I'm reallycurious where people are getting
stuck.
Yeah. So I think on thedevelopment side where I see most
people getting stuck is wewrite in a very brief prompt and
we let it spit out whateverit's going to spit out and we say,
"Ah, this isn't any good." Buta lot of teams I'm seeing really
(06:52):
just aren't investing the timeto understand the tools, to stick
with one tool for more than aweek, to really like hone and guide
that tool. The same way... youknow, many of us have compared it
to a junior engineer joiningour team. We've got to spend some
time with that person, thatthing, and really kind of guide it.
Yeah, so really where I see alot of teams struggle is we kind
(07:14):
of just throw hope at the AItool and hope that it's going to
generate what we're looking for.
Yeah.
And then on the kind ofproduct integration side, it's really
a lot more simple than manypeople maybe think it can be or will
be. So a lot of, you know,chat interfaces and a lot of digestion
of big repositories ofinformation and knowledge bases and
(07:38):
those sorts of things, that'swhere I'm seeing most companies really,
really get some value. Butagain, we have to kind of slightly
tweak the paradigm of how wethink about the software engineering.
But for me, I found that ittends to follow a very similar pattern.
It's an API that I'm calling,if I'm calling out to one of the
big LLMs. It's a repository ofinformation that I'm doing some sort
(08:01):
of query on if it's a RAGdatabase or something like that.
So the paradigms are reallyvery similar. It's just a slightly
different approach that wehave to take.
Yeah. I think, you know, justfrom seeing where people kind of
like stumble a bit in, like,the development process... like
that analogy of, like,bringing on a junior engineer.
mean, there's companies thatdo a very good job of that, and there's
(08:23):
companies that do a very badjob of that. And I feel like those
companies, the companies do avery good job of that. You see things
where it's like, the READMEsare up to date, they've got best
practices and like, lintingguides and configurations all figured
out. Like, your first day onthe job, you Docker up something
and like, it's running, andyou get a PR into prod day one. That
(08:46):
experience is very rare in acompany. The other experience, where
it takes three days to set upyour desktop. You're looking at old
docs for how everything works.That's where many companies are.
AndI feel like the companiesthat need it are this company over
here - the companies that arealready kind of like, "It's hard
to onboard a junior." And tthecompaniesthat arelike, we're "We're
very good at onboardingjuniors" are usingthosesameassetstodrivecontextforusingAIasapartof
theirworkflow.SoIguessthispredatesjustbeing in
theAIspace,butasaCTOandtechleaderthat's comingintoOrg,howdoyou
get ateamtoeven that's cominginto orgs, Well,suchthattheycanonboardtheseAIagent
junior engineer well? Suchthat youseepeoplestrugglewiththere?
(09:36):
It's exactly that. It's howsimple is it for me to get up and
running? How quickly can I doit? How much time am I going to be
stealing from our most seniorengineer, who's the only person that
really knows the system? Andso when I come into an organization,
that's my number one goal - toget to a point where somebody can
just, "Here's the link to therepo, download it, let it download
(09:58):
half the Internet and then runDocker up, and you're running. You've
got the entire stack rightthere on your machine." Because if
I'm honest most platforms,most applications out there, they
can do that. They don't needto be as complex as we make them.
And so if we can get to thatpoint, then it's just amazing. And
when I talk about scale, ourability to scale the number of developers
(10:22):
is one of those areas that wereally have to focus. And it comes
down to - what does onboardinglook like? How maintainable, how
understandable is that codebase? So that I can just, "Here's
the readREADMEme,here'sasetofinstructions,letme know when
you get to that point."
Yeah, I think that's one ofthe things that always surprises
people, like when I show themhow I develop and use AI - the amount
(10:46):
of just docs that we feed intoit, like before any prompt. We do
architecture decision recordsof like how we got to why things
are the way they are. Like wedo domain driven design, but like
domain models that are likefully detailed. Like we give it so
much context and we get a tonout of it. But I think this is one
of those places where youreally start to see... you know,
(11:06):
people say this all the time,"Like AI is really good... like looking
at LLM output i great if youunderstand the domain, and if you
don't understand the domain,it's going to be so hard for you
to spot all the red herringsand hallucinations." I feel like
this is one of those placeswhere you really see the gap of like
what you can get out of it.It's like if you don't have a clean
house to start with on yourengineering org, this is going to
be so much harder for you.
(11:27):
Yeah, 1 million percent.
Absolutely.
And I think another shift thatI'm really seeing too is so many
of us, from an engineeringstandpoint, really need to start
thinking much more like anarchitect in that way. Like, what
are the decisions? What arethe reasons behind those decisions?
Documenting it in a clear waythat everyone on the team can understand
it. Again, that benefitseveryone on the team and whatever
(11:50):
AI agents we bring on board.
Yeah, something I'd love tojust kind of pick your brain... and
if it's like soofftooff-topicpic,please letmeknow...I
seethishappenwitha lot oforganizations tha I've worked with
in my day job, but also I havefriends that are trying to kin of
solve problems in this spaceright now and I see them kind of
struggling with this... I'dlove to know, just like, based off
the orgs that you've workedwith - and I know that you're probably
(12:11):
more on like the AI side,buton like the DevOps side of the house,
like when we kind of thinkabout the work that folks are trying
to start to automate andincorporate AI into like our DevOps
workflows - one of the thingsthat I think is very different about
DevOps and even platformengineering to some degree than our
(12:31):
traditionally developedservices that we have, like for the
app team that they're workingon is like the app team's app is
like a pretty cohesivedomain...maybe, maybe not in the
domain driven design sense...but like, this is the billing app,
or this is the image app, orthis is the checkout app. And one
of the things I think thatbecomes a bit difficult with generating
like code for AI andgenerating things for just operations
(12:55):
in general is that like, thestakeholders involved in production
is just so much more massiveand the context is huge. An so understanding
how my app works, it's like,"Hey, I got some metrics, I got some
source code, my app'srunning." But understanding the DevOps
side of the world, doing theAI and automation seems so much harder
(13:17):
because it's like theaboutcompliance, theappteam's concernedtheirapp'snotfastenough.Right?Andsolike,forteamswheretheirjobisjustlike,justinvolves
somanyconcernsandsomanystakeholders,like,have you
seenotherplaceswheretheyhavelikea just involves so many concernAIoutofit?BecausewhenIseetheseteamsliketryingtodothislikethere'sjustsomuchto
(13:47):
like a similar problem andhave gotten successful use of AI
out of it? Because when I seethese teams like trying to do this,
like there's just so much topull in. It's hard to kind of .I"O"D
Right.
So like within these teamsthey have these just like diaspora
of stakeholders and data. Likehave you seen any really good strategies
for kind of bringing that into workflows? Or is that just...
(14:10):
are we just not there yet? Oris that like agents of agents and
agents of agents of agents andstuff like that?
I really haven't seen itsuccessfully kind of roll out. You
know, I'm seeing differentintegrations tying MCPs together
to, you know, track progressfor certain projects and you know,
tying it all the way down tocommit histories and just starting
to bring a lot of that datathat we would try and like parse
(14:33):
our way through as like a techlead or a CTO starting to bring that
together. But really I haven'tseen that big corpus of data. And
I think a lot of it is notonly, you know, there's just so much,
it's, you know, in so manydifferent places, we might not even
know about it, but also thenthe security aspect as well. Like
in my ship, how much am Ishipping off? So I would imagine
(14:53):
we're going to see quite abit, you know, shift in that way
in the industry over the nextyear or two. Yeah, I haven't really
seen anything huge successful yet.
Yeah, yeah, I mean I thinkit's exciting. Like seeing some of
the folks that are in the nextYC batch, like I see them on, you
know, on Bookface, talkingabout like the problems they're working
on, but it just seems like,when you think about production,
(15:16):
like a production app, it'slike it is just so hard to even define
like what is prod. Like youhave like the overlays of like, "Eh,
maybe it's this network - it'spartially staging, partially prod."
Like there's just so manyblurry lines. It feels so hard to
really get a good context for.It's like, "Hey, is this thing going
to make good operationaldecisions?" It still feels like we're
years out from that. Andthat's one of the things that I think
(15:38):
also is kind of, I thinkcreating a gap in adoption is it
feels so far away for so manyoperations in here. I feel like you
don't see as many people usingAI, like in our space, like writing
Infrastructure as Code anddoing things around operations because
it just seems so hard andcomplex and therefore like we're
falling behind a bit. You knowwhat I mean?
(15:59):
Yeah, yeah, definitely.
Ops teams, you're probablyused to doing all the heavy lifting
when it comes toinfrastructure as code wrangling
root modules, CI/CD scriptsand Terraform, just to keep things
moving along. What if yourdevelopers could just diagram what
they want and you still gotall the control and visibility you
need? That'sexactly whatMassdriver does. Ops teams upload
your trusted infrastructure ascode modules to our registry.Your
(16:20):
developers, they don't have totouch Terraform, build root modules,
or even copy a single line ofCI/CD scripts. They just diagram
(16:42):
their cloud infrastructure.Massdriver pulls the modules and
deploys exactly what's ontheir canvas. The result? It'sstill
managed as code, but withcomplete audit trails, rollbacks,
preview environments and costcontrols. You'll see exactly who's
using what, where and whatresources they're producing, all
without the chaos. Stop doingtwice the work. Startmaking Infrastructure
as Code simpler withMassdriver. Learn more at Massdriver.cloud.
So opposite of operations issimplicity. And this is something
(17:04):
that you're big on. So I wantto come back to this a bit. So in
the pre-show you talked aboutsimplicity and what I was curious
is - when we think aboutplatforms, like, what does a simple
platform actually look like?Like you're joining a company, you
know, you're coming in as anearly platform engineer, they've
already got a smattering ofdevelopers building some stuff. Like
(17:25):
what does a good MVP looklike? As a fractional CTO coming
in saying, "Okay, we've gotthese teams, they're starting to
do all this stuff in thecloud, but there's no conformity,
no governance, no nothing kindof sitting over it." What does a
good baselin platform looklike that sits in this realm of simplicity,
but also empowers you to actand self-serve on your own?
(17:46):
For me, I start at the localdevelopment story. What does it look
like for me to again downloadthe repository, run a command and
I'm up and running? My goal is30 minutes I can do that, maybe an
hour. But I can do it. I don'thave to do some weird connection,
I don't need a bunch of, youknow, random credentials. If I can
simplify it down to thatlevel, I've got a handful of containers
(18:09):
that are running locally, thenit's nice and simple. That then just
continues up as we move up inenvironments. And then from there,
like, okay, cool, we have astaging environment. And for me,
that's an environment thateveryone can access. That's where
developers feel like they cango in and test and see and do. And
(18:29):
we can drop the database andwe can read, seed it and, you know,
do all of those things. And sothat gives us a lot of control and
visibility into how things areoperating. And then we have production.
And production should lookidentical to staging. It's just separated,
right? It's just different.It's more horsepower. But there shouldn't
(18:50):
be anything that's reallymonumentally different from my local
all the way through toproduction. And if I can do that,
then it's just so simple forus to do things like troubleshooting,
for us to think aboutdifferent ways that we can scale.
And again, one of the big waysthat we scale is our ability to add
new developers to theplatform. How can we bring people
(19:11):
on and it not feel like ittakes forever for anybody to be able
to contribute to theproduction code base. If you can
put a pull request in and getit merged into production in your
first week, I think we're successful.
Yeah, I think one of thethings that is always, like, rough
for building that first MVP isfiguring out the scope, right? It's
(19:36):
like, how much should it be?And I think a lot of people have
this, like, well, I got to getthat final thing out. And getting
the final thing out pisses offdevelopers because they've waited
a very long time for the finalthing, right? And I think one of
the key things is just gettingout something that works. And like,
that first KPI is - are peoplehappy with it? And like, that joining
(19:56):
the job, I sit down and like,it's... you never know. I mean, I'll
tell you the truth. I gothired at a job once. I quit an hour
and a half later. Like, it wasjust like, I started setting stuff
up, and I was just like... I'man hour and a half into a README,
and somebody's like, "Oh,that's the old version." And I was
like, "I'm out, guys. Like, I'v been reading... I've been copying
(20:17):
and pasting stuff that doesnot work for an hour and a half.
And this is the old README." Iwas just out. And it's just like,
when working on a platform,like, what really matters is, is
the user happy? Like that is ou job. It is a product. I want
my developers to be happy withit. I want it to be easy for them
to use and adopt and to getthere. Like, you can tell when you
(20:40):
sit down on a project, likeday one, you're like, "Okay, this
is going to be easy to set up.I'm going to be happy." And like,
if that happy path is a READMEin a Docker file - that's a minimal
platform. I'll tell you what,that's pretty simple. And progressing
that into the cloud... we havea lot of options to ship that container
and move it forward. I feellike there's so many orgs that still
kind of fight this simplicity.And again, you can be well-structured
(21:05):
and simple. And simple.AndIone of the things whe you embrace
simpler systems... and we justdid a huge migration at work recently,
we went from 26 microservicesback to a monolith. We fucking love
it. We move fast. Not only dowe move fast, AI when we're working
with it moves very fast aswell. But like, what is it about
(21:27):
going from that MVP where it'sstarting to make money to like post
Series A or post Series Bwhere teams just lose the thread
on simplicity? They just...they go hard on making things hard.
I feel like we lose so much inthat early stage, like from MVP through
Series A, where it's likestuff just starts to kind of smatter
out and we just make all sortsof crazy things. Like how do teams
(21:50):
keep it simple while keepingit efficient?
So I think the reason I seethat happen so often in my experience
is because developers craveproblems to solve and they crave
complexity. And so if theproblems that we're solving, like
in the business, if thosearen't complex, if those don't have,
(22:11):
aren't clearly defined, thenI'm going to find something. I'm
going to create complex, I'mgoing to create problems that I need
to solve. That's whenmicroservices come into play. That's
when like advanced event basedarchitectures and all sorts of crazy
things start to come intoplay. Because I need that complexity,
I need that challenge. And sofor me, what I like to do is put
some guardrails around, likethis is the architecture, you know,
(22:33):
at a high level, these are thetechnologies we use. And then I really...
because I know that's whatengineers really want, that's the
desire they have, especiallyengineers at certain phases of their
career. Let me find thatwithin the problems that we're solving.
Like, here's a really, reallyunique, interesting thing that we
need to solve. But it'salready within our context. We're
(22:54):
not creating new problemsbecause those new problems then become
the 26 microservices thatyou've got to now deal with.
Yeah, yeah. That'sinteresting, right? Like the engineers
are looking for something tosolve and that is what we do all
day, right? And it's funny,like, as you were saying that I could
feel like a laugh creeping inbecause I had flashbacks from my
(23:15):
years working in E-commerce.Which, like, I don't know... anybody
who's out there in E-commerce,I'm sure, like, if you're at Shopify,
you guys got some interestingsolves to work on. But it's like
everybody else working on likea Shopify clone, it's just like the
problems are all solved andthe software is super boring. It's
like I just Rails generatethis whole thing pretty much and
then you're just like, "Well,business problems are... inventory
(23:38):
is solved, shipping things issolved. What can I do that's interesting?
Let's split this Railsmonolith into a thousand rack Sinatra
servers." That is pretty spoton. You just laid out like, I think,
about three or four years ofmy life in the late two thousands.
We all did it, right? We alldid it. Yeah, it's just some of us
have been around long enoughto realize the impact of it.
(24:00):
You know what I think? I'mgetting this thought right now. We'll
see. Maybe this is my Dariofrom Anthropic moment - I don't think
software engineering jobs aregoing to be lost. I think PMs are. Software
engineers are going to becoming for those PM jobs because
we're going to look for theinteresting business problems to
solve and then we can justwizard software out. PMs better watch
(24:22):
out. We're coming for you.
Uh oh.
They thought it was the otherway. They thought they were going
to be able to do softwaredevelopment. No way, man. We're coming
for those interestingproblems. That one's not a threat,
but it is. Okay. Okay. So likesimplicity and scaling though. Your
point on like, you know,scaling starts from just being able
to scale a team. So how doessimplicity connect to scaling beyond
(24:44):
just teams? How does it gofrom scaling my team to scaling more
features? Because I feel likea lot of teams hear that like, "Oh,
if I'm scaling my team," butyou hear more people, "slower delivery."
How do you scale a team andmaintain simplicity while also maintaining
delivery cadence? I feel likethis is part of that golden triangle
(25:07):
where you're starting to kindof push and pull in different directions.
Like we have more people. Onecode base is hard, so we split up
the code base. But now puttingit all back together is hard. Like
how do you deal with that kindof split-join criteria and how teams
work? And scaling those teamsas you're trying to scale more features
and more revenue opposed tothat MVP when you're joining a team?
(25:28):
Yeah. So it's interesting,Cory. So I think about scale happening
in three ways. The first isour ability to add users, right.
And to your point, that's asolved problem. How can I add more
users to the platform whilemaintaining or improving performance
for every user? That's morehorsepower and there' a ton of things.
The second is our ability toadd developers. So that really comes
(25:50):
into the documentation, theecosystem that we build. You know,
what does the development looklike? What does our testing look
like? What does our releasestrategy look like? Can I merge right
in? Are we using featureflags? And that's similar for features,
right? The third way that wescale is our ability to add features.
And so adding features doesn'tjust mean, "Hey, let me bolt on more
(26:12):
features." Then we just end upwith this gigantic thing. It's, "Can
I add a feature, can I changeit, can I remove a feature without
it being a huge refactor wherewe have to spend a ton of time doing
it?" And a lot of that justcomes down to how modular is the
code, how interconnected arethings, you know, just really thinking
ahead of those things. And Ithink so much of our ability to scale
(26:36):
and focus on simplicity comesdown to the foundation that we lay.
What is the generalarchitecture that we have? What are
the pipelines that we haveavailable to us? What are the test
harnesses and all of thosethings? When we have all of that
in place, then we can movemuch more quickly and confidently.
(26:57):
And really it's thatconfidence that I think then gives
us that speed to know that ifI'm going to change this thing and
it broke something, I'm goingto know about it before it gets to
production and then ultimatelyto our customers.
Yeah. So what's reallyinteresting with that is... again,
like coming back to like thisgap in the success of AI, right?
Like right there you have itlike potentially like, like breaching
(27:19):
again. Like if I'm a teamthat's able to actually use AI and
use it effectively, and I'vedone so much of these good practices
that I'm able to ship softwarefaster, I'm able to add people to
my team faster, build softwarefaster. And then you have this team
over here that's stillstruggling with like the basics of
simplicity to even get theirhouse in order where they can ramp
(27:40):
their team up. Those teams arestill leaning into AI generated code
and some of them are gettingapps that work. And we know that
AI is a litter bug, right? Soit's almost like they are moving
themselves forward veryquickly to then go slow again. They're
going to reach just a barrierat some point in time. We've generated
so much code where it's noteasy to change things because these
(28:02):
things are litter bugs. And ifI'm lacking these common principles
about like how I should writesoftware, how we write efficient
software, how we write wellorganized and modular software, and
then Claude's just dumping a1,100 line function. Like, you don't
know your shit out of luckyet, but you're going to be in like
six to nine months. The messthey're in, I feel like that's a
(28:25):
great place for people likeyou to kind of come in.
Yeah, that's the opportunity.
There we go. That's a greatopportunity. So cleaning house, like
it really just comes down tolike cleaning house at the end of
the day. Like that is like oneof the cornerstone things that we
can do to make our teamsonboard easier, us AI. So when we're
thinking about that, we doover-engineer in the modern world,
(28:50):
right? Like when you'relooking at like some of these typical,
like modern over-engineeredstacks... you're coming in and you're
seeing... like, where are youseeing th unnecessary complexity
lean in? Like, are you justseeing teams who are like, "Oh, we
want to try a thousanddifferent programming languages"?
Or is it like open sourcelike-a-palooza? Where like, "Oh look,
another open source tool isout that we can install and run.
(29:12):
And what were we using thatfor? I don't know." What kind of
proliferation ofover-engineering are you typically
seeing in these stage companies?
Yeah, it's exactly that. Andyou know, I thought it was clever
a few years ago and came upwith resume driven design.
Oh yes.
Yes, Resume drivendevelopment, right? Somebody else
coined it, but that's what Isee a lot - "I want to add DynamoDB
(29:36):
and allofthesedifferentarchitecturesandplatformsasaserviceandallthesethingsjustsothatIcanputitonmyresume. SoIsee
alotofthat.Isee, resume." So Isee a lot of that. I see, you know,
again, "I toreallytry thisout. I'm inanymeaningfulway. SoI'mgoingtobringitinandI'm
going totellyou,dearEngineering Managerorcto,we
(29:58):
reallyneedthispiece oftechnologyforscale.Right?CTO"
Yeah.
You don't need kubernetes outof the gate, you just don't. Right.
You need a simple deploymentpipeline and that's it. And so I
see everywhere from kind ofthe Kubernetes, the container runtimes...
how that is orchestrated. Itend to see a lot of complexity there.
Microservices, which are justa ton of lambda functions, see a
(30:20):
ton of that. I see a lot ofjust using the wrong database. Everyone
wants to reach for the NoSQL,the Mongo, the DynamoDBs out of the
gate, but they haven't reallythought about their data structure.
And so then they end up withthese gigantic databases that are
inefficient for querying. So Imean for me it's like so much is
just a CRUD application.
(30:40):
Yeah, yeah, that one breaks myheart. I was in database administration
for years and seeing so manypeople reach for NoSQL... and there's
places where NoSQL is valid, Ilove Postgres, you can stick almost
anything inpoPostgresstgres.It'sgotsomeNoSQLinthere.It'sa fun
time... But I feel like thething that's always maddening about
like the overreach for NoSQLis a lot of times people reach for
(31:03):
it not because they're lookingfor the speed or eventual consistency,
they're looking for the nondrama of dealing with a database
migration. And it's just like,"Dude, you just made your life so
much fucking harder."Everything... there's a table, there's
a schema, your data has aschema. It either lives in the database
or it lives in your code, butthere's a schema that will be had
(31:26):
and it is much more beautifulwhen you can guarantee it at the
storage level. I'm just like,"Oh, you changed the code. So you
have no guarantees about thatfield anymore. That's harrowing."
I was just like, dude, theregion for NoSQL is just such an
(31:48):
early optimization. That justpierced my. Pierced me right in the
heart because I know it'strue. This might be a weird question,
but there's something thatI've been thinking about a lot recently,
and talking to a couple of mybuddies, and I kind of want to start
bringing it into the show abit... like I use AI every day and
like if you follow me onLinkedIn... everybody follows me
on LinkedIn... it sounds likeI hate AI. I use the shit out of
(32:10):
it. I barely write code. Istill write all my tests. I'll tell
you what, I write my testsfirst. I let Claude write all my
code, I write the tests. It'sthe perfect TDD relationship. I do
the refactoring because itwrites garbage code. That's my little
trick with simplicity. But Iuse it all day and I use it for all
sorts of stuff. But at thesame time it's like where are we
going with this thing? What doyou think 5 and 10 years looks like
(32:35):
from now with AI as adeveloper and as a non developer?
Sorry if that one's wild andout there but I really want to see
what engineers feel about thisbecause I feel like we're this very
interesting class of peoplewhere we're using it the most and
getting the most value out ofit. But we're also definitely on
a speedrun to completely justdamaging the number of people that
(32:58):
can work in this field. Idon't think we go away, I think you
start to see a lot less needand I probably see salaries drop
- as my personal opinion. ButI would love to know what is your
read on where this is going?Do you think it is going to be the
technology shift that we thinkit is? Where do you see this in 5
to 10 years for engineers andnon engineers?
Man, that's a good question. Iwould agree. I think we're going
(33:21):
to see more people. The peoplethat stay in the industry are the
ones that are reallypassionate about technology, right?
I think the people that gotinto the industry because it was
guaranteedsisix-figurexfiguresalaryout ofthe
gate,Ithinkthatcropoffolks aregoing to tend to kind of weed out
because they just aren't aspassionate about it. I think it's
going to require that passion.I agree, we're not going away, the
(33:44):
job role, the way we work isgoing to be different. I really don't
think there's a going to be adecrease in the desire for software.
Certainly not.
What it looks like,I think,may change. I don't know that like
some people are talking about,"Oh well, just spin up your own version
of whatever CRM and it'sinternal and you don't need to pay
(34:05):
your per seat licensinganymore." I don't know that that's
going to happen as muchbecause turns out you still have
to support that softwarethat's running even though you generated
it on the fly. I don't knowthat that's going to happen. I think
as software engineers,especially the ones of us that are
really adopting it, reallytrying to put it into our workflow
(34:27):
day in and day out, we're atthe advantage compared to our peers
that aren't. There are still alot of folks in software engineering
that just are resistant to itand probably will be until they're
kind of phased out of theindustry, I would imagine. And then
for our non-technicalcounterparts, I'm seeing their adoption
even quicker. They're playingwith the tools like the Lovables,
(34:48):
like the Replits and beingable to generate full applications.
They're really experimentingand then realizing, "Oh, this is
a lot harder than it lookslike to do a good job with it." But
I think that we're going tosee both sides continue to adopt
it more and more. You know, itstill feels like right now we're
experimenting and trying tofigure out where's a good spot for
(35:10):
me to fit this into my lifeand my work. So it's going to be
really interesting, and Ithink a very challenging next few
years, honestly.
Yeah, it's interesting becauselike I feel like my entire network
of people that are like in theengineering space - they love it
or they hate it. But even thepeople that are hate it are like,
(35:31):
"Eh, I hate it." Like I hateit, but at the same time I see the
value in it, right? And thenthere's people that just aren't successful
with it. I would honestly saylike some of the things you've talked
about at the beginning, likejust focusing on simplicity... Just
like the kind of things thatmake you onboard an engineer well
are the things that are goingto make you get good outputs from
(35:52):
a context when you're workingon any given feature that you're
working on. I don't know, man,it's just... it seems like we're
speed running, we're creatinga lot of gap between like the people
that know stuff and the peoplethat don't. And it just seems like
a pretty phenomenal gap isgoing to be there. And at the same
time like I don't see itslowing down unless the bubble pops.
(36:15):
I don't see it slowing down.And if the bubble pops, I honestly
think people are going to bestruggling to grab fragments of this
thing and like, bring itin-house. Like, I know, the open
source LLMs aren't great withCodeGen, but, like, this is going
to be very hard for a lot ofpeople to go back from, if the bubble
pops. Sitting where we aretoday, it's so hard. I feel like
(36:37):
it's so hard to build abusiness. It's so hard to think about
your career. There's just somuch that's going to be different
nine months from now that it'sso hard to plan for three months
from now. And I feel likethat's the first time we've had that
problem in softwareengineering before. And some of them
are like, "Oh, we're going tosit down the next three months and
(36:57):
plan out the next year offeatures that we're going to release."
And now it's like, "Shit,like, we're building so much in this
AI thing. Like, the bubblemight pop sometime next year and
then our software is gone." Orlike, "I don't know how to write
software anymore because AIdoes it for me." And then the bubble
pops and like, "Shit, I don'tknow how to write software anymore."
Like, those are potential,like real worlds that we have coming.
And I know that, like, despitethe fact that I hate it, that would
(37:20):
fuck me up.
I mean, dude, it's changed myhiring strategy on teams. Yeah. You
know, completely shifted thataround. Yeah. I mean, it's part of
one of the qualifiers when I'mlooking at new team members to join
- not are you using it, buthow are you using it and how are
you exploring and how are youlearning? It feels like early days
(37:40):
in my career where I was justimmersed in every, you know, every
tutorial, every course,anything I could find that I could
get my hands on, I was goingthrough and doing. And it feels like
I'm doing the same thing justwith AI and some of these tools.
It's pretty wild, man.
Yeah. So going back to resumedriven development, just had a thought
when you mentioned thatearlier, because I feel like I see
(38:00):
a lot of these resumes too,where it's just, it's a buzzword
palooza. And I'll tell youwhat, like, the buzzwords are important.
You do have to communicatethat you understand the technology
that the job description is,is describing that you need to know
how to use. But if you'relistening and like, you're you're
struggling to find a job rightnow, I'll tell you, there's three
(38:21):
sexy keywords that everyhiring manager loves. The word dollars,
the word increased revenue,and cutting costs and having numbers
around all three of thosewords. And if you have that on your
resume, your resume looks waybetter than the person next to it
that just says Kubernetes,OTel, Jaeger or whatever. If it's
Kubernetes costs saved,Kubernetes revenue increased - like,
(38:47):
those are key words. And Ithink that's one of the things that
I feel like when people areworking on their resumes. Like, dude,
like, your whole point ingetting that cool job where you get
to solve cool problems is thatbusiness wants to make money. And
that's the same thing the nextbusiness wants to do. They don't
want to deploykKubernetesubernetes. to make money.
And yourbosbosswantstomakemoneybecausehe'sgoingtomakemoremoneyif thewhole
company's makingmoremoney.more money. It's like 5 havesomethingabout,like,howyouimpactedthebusiness.
(39:16):
Ifeel likethat'soneofthosebusiness. I youknow,kindofgoingback
those places where... youknow, kind beingfocusedon,like,the
business crazy shit... like,not being focused on the business
part of the business, asjustgooffintotheweedslooking forotherthingstosolve.
There'sinterestingthingshappeninginyourbusiness andifyouunderstandthenumbers,you're
goingto understandalotmoreabout,like,thebusinessasawhole.Andthere'sinteresting problems
(39:40):
theretosolve andcapturethoselot more about the business goingtomake
yourjobhuntsomucheasier.Sorry,thatwas to solve
and capture those numbers andput them on your resume. It's going
to make your job hunt so mucheasier. Sorry, that was just... you
time today.Thisis and I'm justlike, "Yes, I've seen so much rdd."
(40:00):
Oh, man, awesome. Well, Ireale this-it's
Best place to find me is onLinkedIn - Brian-Childress. You know,
fairly prolific on there. Loveto connect.
Awesome. Well, thanks so muchfor coming on the show. I really
appreciate the time and we'lltalk to you soon.
Welcome back to the PlatformEngineering Podcast. I'm your host,
Cory O'Daniel. If you haven'tgot to hear the past couple of episodes,
we had three episodes back toback with Kelsey Hightower guest
hosting. Go check those out.Those over the past, I think, two
months or so. And then lastweek we had a really great episode
on Policy as Code and Kyvrno.I would definitely check it out.
Not to scare Brian, but it isby far my most clipped episode I've
(00:37):
ever recorded. It has so manygreat takes. I've got Brian with
me here today, though he isnow on the spot, he's going to have
to have a ton of great takestoday. We've got Brian Childress,
he's a technology leader,fractional CTO. He helps teams simplify
platforms, improve developerexperience, and build goingto getintosomeoftheproblems
heseesmostoftenwhysimplicitymattersmorethanpeoplethink.Andalsoonhow.How AIis
(01:02):
shiftingthe waywebuild also onhow AI is shifting ,Thankssomuchforjoiningus,
t.
Cory, man, it's behere.
Yeah. Where are you based out of?
Richmond, Virginia.
Richmond, Virginia. Okay. Sofor folks that aren't familiar with
your background, you wereactually an outdoor guide before,
like getting into technology.
Yeah. Yep.
(01:22):
You did the reverse of what Ithink every software engineer I know
wants to do. They're softwareengineers and they're like, "Oh,
my gosh, I'm over this. WhenAI is here, I'm moving out into the
woods and I'm going to be anature guide." And you're like, "These
woods ain't for me. I'm gonnago sit in the data center." What's
going on, man?
That's basically whathappened, man. So, yeah, early on,
(01:43):
when I was looking at going tocollege and all of that, I followed
the advice of, "Follow yourpassions and you'll never have to
work a day in your life." AndI was passionate about rock climbing
and kayaking and all the funadventure outdoor activities. And
so I went in and got a degreefocused in that area, went and guided
for a few years. Absolutelyloved the work, really enjoyed it.
(02:06):
But I found it was reallymissing something. One, it didn't
pay amazing, so that was partof it. But I really wasn't getting
the kind of the intellectualchallenge that I was looking for.
And so I went on a hunt tofind something else and landed in
technology. It's funny, when Ifirst started, I was like, "Man,
(02:26):
I don't want to be the guysitting behind a computer for 8,
10, 12 hours a day." And, youknow, heck, now I spend 14 hours
a day behind one and love whatI do, so it's good.
That's very cool. So when youfirst, like, did the transition,
was it just like, "Hey, I'mgonna go, like, back to school. I'm
gonna go get a degree incomputer science"? Or was it just
like, "Hey, I'm gonna go startlearning the program on my own"?
(02:48):
Like, how did you move overinto this world?
Kind of a little bit of both.The intermediate step was I went
back to graduate school andfocused on Geographic Information
System, so GIS.
Right, okay.
Maps and, you know, big datasets and that kind of thing. And
when I got into it, we, youknow, as part of it... as, you know,
data manipulation and all ofthat... started to learn Python.
(03:10):
And at the time, you know, 20years ago, I thought Python was an
outdated language that, youknow, I was like, "No one's going
to ever use this." I was wrong.
Yeah, a tad.
Yeah. So I got into it, reallyfound that I enjoyed, like, the building
aspect of it, the creation ofsoftware, and just, you know, it
snowballed from there. Icontinued to kind of work in my graduate
(03:33):
work, but then I was also,like, learning all sorts of different
languages and frameworks onthe side.
I feel like everybody I knowthat... when I look at, like, my
friends that come fromdifferent backgrounds that work in
software... I've got buddies,you know, they went to school for
whatever, they're doing theirjob for, like, 10 years, and they
went to a boot camp. And Ifeel like all of those people are
(03:55):
just, like, fully in theJavaScript camp. And then whenever
I meet somebody who's like,"Hey, I'm into software now. And
I came this way throughPython." They always have like a
very interesting, like, worldthat they came from. That like Python
was introduced that, like,caused that. Like, I have friends
that work in, you know,research, like, doing cancer research,
and they're like, "And now Iwork in AI." It's just like they
(04:17):
move over. And Python is... Ifeel like it's a gateway drug for
people that have reallyinteresting careers just kind of
slowly becoming absorbed intothe cloud. That's cool. Yeah. Python
was a very... I feel like overthe past few years, Python was quite
the surprise of a language tocome in and start to dominate so
(04:39):
many areas. I feel like I'vealways programmed in Edgy cool languages,
like Elixir and Erlang. Andthen just seeing just the proliferation
of JavaScript through the endof the two thousand tens and then
just Python's everywherenow... was very, very surprising
to me. When you go in and workwith teams, like how are you working
(05:00):
on those things? Are you goinginto teams that are doing like Python
AI stuff? Are you going in andkind of doing fractional work at
all different types oforganizations? Or are you focusing
more on the AI side of the house?
I mean, AI is definitelyfoundational for every project that
I'm working on now. I tend tocome into projects once they're already
kind of up and running. Theyhave... call it an MVP. They have
(05:24):
something working, they havepaying customers on it, and they're
starting to hit some scalingchallenges. That's typically where
I come in and really help tostabilize. And often it's just simplify
what they have so that theycan actually start to think about
scale.
Yeah. So like with all theteams starting to, I guess, experiment
with like AI projects now, Ifeel like it's... I mean it's obviously
(05:47):
everywhere now. How this endsup in the next couple of years we
will see. I'm not necessarilyas excited as my face says that I
am, but there's so many ofthese teams that they're building
something new, they'rebuilding stuff in AI. With all the
orgs you've already workedwith, kind of the experience you've
seen, what do you think issome of the most common, I guess
(06:08):
hurdles or problems for likeearlier stage teams? These teams
that have this MVP, they'restarting to see revenuea,andndtheywant
to start using AI. What istheir biggest hurdle to having a
successful use of it? Is itmore so using it internally for building?
Or is it like actually gettingto that point where it's a part of
their product? Because I see alot of teams doing it and I also
(06:29):
see like these reports of like90% of orgs are not seeing value
on the other side. I'm reallycurious where people are getting
stuck.
Yeah. So I think on thedevelopment side where I see most
people getting stuck is wewrite in a very brief prompt and
we let it spit out whateverit's going to spit out and we say,
"Ah, this isn't any good." Buta lot of teams I'm seeing really
(06:52):
just aren't investing the timeto understand the tools, to stick
with one tool for more than aweek, to really like hone and guide
that tool. The same way... youknow, many of us have compared it
to a junior engineer joiningour team. We've got to spend some
time with that person, thatthing, and really kind of guide it.
Yeah, so really where I see alot of teams struggle is we kind
(07:14):
of just throw hope at the AItool and hope that it's going to
generate what we're looking for.
Yeah.
And then on the kind ofproduct integration side, it's really
a lot more simple than manypeople maybe think it can be or will
be. So a lot of, you know,chat interfaces and a lot of digestion
of big repositories ofinformation and knowledge bases and
(07:38):
those sorts of things, that'swhere I'm seeing most companies really,
really get some value. Butagain, we have to kind of slightly
tweak the paradigm of how wethink about the software engineering.
But for me, I found that ittends to follow a very similar pattern.
It's an API that I'm calling,if I'm calling out to one of the
big LLMs. It's a repository ofinformation that I'm doing some sort
(08:01):
of query on if it's a RAGdatabase or something like that.
So the paradigms are reallyvery similar. It's just a slightly
different approach that wehave to take.
Yeah. I think, you know, justfrom seeing where people kind of
like stumble a bit in, like,the development process... like
that analogy of, like,bringing on a junior engineer.
mean, there's companies thatdo a very good job of that, and there's
(08:23):
companies that do a very badjob of that. And I feel like those
companies, the companies do avery good job of that. You see things
where it's like, the READMEsare up to date, they've got best
practices and like, lintingguides and configurations all figured
out. Like, your first day onthe job, you Docker up something
and like, it's running, andyou get a PR into prod day one. That
(08:46):
experience is very rare in acompany. The other experience, where
it takes three days to set upyour desktop. You're looking at old
docs for how everything works.That's where many companies are.
AndI feel like the companiesthat need it are this company over
here - the companies that arealready kind of like, "It's hard
to onboard a junior." And tthecompaniesthat arelike, we're "We're
very good at onboardingjuniors" are usingthosesameassetstodrivecontextforusingAIasapartof
theirworkflow.SoIguessthispredatesjustbeing in
theAIspace,butasaCTOandtechleaderthat's comingintoOrg,howdoyou
get ateamtoeven that's cominginto orgs, Well,suchthattheycanonboardtheseAIagent
junior engineer well? Suchthat youseepeoplestrugglewiththere?
(09:36):
It's exactly that. It's howsimple is it for me to get up and
running? How quickly can I doit? How much time am I going to be
stealing from our most seniorengineer, who's the only person that
really knows the system? Andso when I come into an organization,
that's my number one goal - toget to a point where somebody can
just, "Here's the link to therepo, download it, let it download
(09:58):
half the Internet and then runDocker up, and you're running. You've
got the entire stack rightthere on your machine." Because if
I'm honest most platforms,most applications out there, they
can do that. They don't needto be as complex as we make them.
And so if we can get to thatpoint, then it's just amazing. And
when I talk about scale, ourability to scale the number of developers
(10:22):
is one of those areas that wereally have to focus. And it comes
down to - what does onboardinglook like? How maintainable, how
understandable is that codebase? So that I can just, "Here's
the readREADMEme,here'sasetofinstructions,letme know when
you get to that point."
Yeah, I think that's one ofthe things that always surprises
people, like when I show themhow I develop and use AI - the amount
(10:46):
of just docs that we feed intoit, like before any prompt. We do
architecture decision recordsof like how we got to why things
are the way they are. Like wedo domain driven design, but like
domain models that are likefully detailed. Like we give it so
much context and we get a tonout of it. But I think this is one
of those places where youreally start to see... you know,
(11:06):
people say this all the time,"Like AI is really good... like looking
at LLM output i great if youunderstand the domain, and if you
don't understand the domain,it's going to be so hard for you
to spot all the red herringsand hallucinations." I feel like
this is one of those placeswhere you really see the gap of like
what you can get out of it.It's like if you don't have a clean
house to start with on yourengineering org, this is going to
be so much harder for you.
(11:27):
Yeah, 1 million percent.
Absolutely.
And I think another shift thatI'm really seeing too is so many
of us, from an engineeringstandpoint, really need to start
thinking much more like anarchitect in that way. Like, what
are the decisions? What arethe reasons behind those decisions?
Documenting it in a clear waythat everyone on the team can understand
it. Again, that benefitseveryone on the team and whatever
(11:50):
AI agents we bring on board.
Yeah, something I'd love tojust kind of pick your brain... and
if it's like soofftooff-topicpic,please letmeknow...I
seethishappenwitha lot oforganizations tha I've worked with
in my day job, but also I havefriends that are trying to kin of
solve problems in this spaceright now and I see them kind of
struggling with this... I'dlove to know, just like, based off
the orgs that you've workedwith - and I know that you're probably
(12:11):
more on like the AI side,buton like the DevOps side of the house,
like when we kind of thinkabout the work that folks are trying
to start to automate andincorporate AI into like our DevOps
workflows - one of the thingsthat I think is very different about
DevOps and even platformengineering to some degree than our
(12:31):
traditionally developedservices that we have, like for the
app team that they're workingon is like the app team's app is
like a pretty cohesivedomain...maybe, maybe not in the
domain driven design sense...but like, this is the billing app,
or this is the image app, orthis is the checkout app. And one
of the things I think thatbecomes a bit difficult with generating
like code for AI andgenerating things for just operations
(12:55):
in general is that like, thestakeholders involved in production
is just so much more massiveand the context is huge. An so understanding
how my app works, it's like,"Hey, I got some metrics, I got some
source code, my app'srunning." But understanding the DevOps
side of the world, doing theAI and automation seems so much harder
(13:17):
because it's like theaboutcompliance, theappteam's concernedtheirapp'snotfastenough.Right?Andsolike,forteamswheretheirjobisjustlike,justinvolves
somanyconcernsandsomanystakeholders,like,have you
seenotherplaceswheretheyhavelikea just involves so many concernAIoutofit?BecausewhenIseetheseteamsliketryingtodothislikethere'sjustsomuchto
(13:47):
like a similar problem andhave gotten successful use of AI
out of it? Because when I seethese teams like trying to do this,
like there's just so much topull in. It's hard to kind of .I"O"D
Right.
So like within these teamsthey have these just like diaspora
of stakeholders and data. Likehave you seen any really good strategies
for kind of bringing that into workflows? Or is that just...
(14:10):
are we just not there yet? Oris that like agents of agents and
agents of agents of agents andstuff like that?
I really haven't seen itsuccessfully kind of roll out. You
know, I'm seeing differentintegrations tying MCPs together
to, you know, track progressfor certain projects and you know,
tying it all the way down tocommit histories and just starting
to bring a lot of that datathat we would try and like parse
(14:33):
our way through as like a techlead or a CTO starting to bring that
together. But really I haven'tseen that big corpus of data. And
I think a lot of it is notonly, you know, there's just so much,
it's, you know, in so manydifferent places, we might not even
know about it, but also thenthe security aspect as well. Like
in my ship, how much am Ishipping off? So I would imagine
(14:53):
we're going to see quite abit, you know, shift in that way
in the industry over the nextyear or two. Yeah, I haven't really
seen anything huge successful yet.
Yeah, yeah, I mean I thinkit's exciting. Like seeing some of
the folks that are in the nextYC batch, like I see them on, you
know, on Bookface, talkingabout like the problems they're working
on, but it just seems like,when you think about production,
(15:16):
like a production app, it'slike it is just so hard to even define
like what is prod. Like youhave like the overlays of like, "Eh,
maybe it's this network - it'spartially staging, partially prod."
Like there's just so manyblurry lines. It feels so hard to
really get a good context for.It's like, "Hey, is this thing going
to make good operationaldecisions?" It still feels like we're
years out from that. Andthat's one of the things that I think
(15:38):
also is kind of, I thinkcreating a gap in adoption is it
feels so far away for so manyoperations in here. I feel like you
don't see as many people usingAI, like in our space, like writing
Infrastructure as Code anddoing things around operations because
it just seems so hard andcomplex and therefore like we're
falling behind a bit. You knowwhat I mean?
(15:59):
Yeah, yeah, definitely.
Ops teams, you're probablyused to doing all the heavy lifting
when it comes toinfrastructure as code wrangling
root modules, CI/CD scriptsand Terraform, just to keep things
moving along. What if yourdevelopers could just diagram what
they want and you still gotall the control and visibility you
need? That'sexactly whatMassdriver does. Ops teams upload
your trusted infrastructure ascode modules to our registry.Your
(16:20):
developers, they don't have totouch Terraform, build root modules,
or even copy a single line ofCI/CD scripts. They just diagram
(16:42):
their cloud infrastructure.Massdriver pulls the modules and
deploys exactly what's ontheir canvas. The result? It'sstill
managed as code, but withcomplete audit trails, rollbacks,
preview environments and costcontrols. You'll see exactly who's
using what, where and whatresources they're producing, all
without the chaos. Stop doingtwice the work. Startmaking Infrastructure
as Code simpler withMassdriver. Learn more at Massdriver.cloud.
So opposite of operations issimplicity. And this is something
(17:04):
that you're big on. So I wantto come back to this a bit. So in
the pre-show you talked aboutsimplicity and what I was curious
is - when we think aboutplatforms, like, what does a simple
platform actually look like?Like you're joining a company, you
know, you're coming in as anearly platform engineer, they've
already got a smattering ofdevelopers building some stuff. Like
(17:25):
what does a good MVP looklike? As a fractional CTO coming
in saying, "Okay, we've gotthese teams, they're starting to
do all this stuff in thecloud, but there's no conformity,
no governance, no nothing kindof sitting over it." What does a
good baselin platform looklike that sits in this realm of simplicity,
but also empowers you to actand self-serve on your own?
(17:46):
For me, I start at the localdevelopment story. What does it look
like for me to again downloadthe repository, run a command and
I'm up and running? My goal is30 minutes I can do that, maybe an
hour. But I can do it. I don'thave to do some weird connection,
I don't need a bunch of, youknow, random credentials. If I can
simplify it down to thatlevel, I've got a handful of containers
(18:09):
that are running locally, thenit's nice and simple. That then just
continues up as we move up inenvironments. And then from there,
like, okay, cool, we have astaging environment. And for me,
that's an environment thateveryone can access. That's where
developers feel like they cango in and test and see and do. And
(18:29):
we can drop the database andwe can read, seed it and, you know,
do all of those things. And sothat gives us a lot of control and
visibility into how things areoperating. And then we have production.
And production should lookidentical to staging. It's just separated,
right? It's just different.It's more horsepower. But there shouldn't
(18:50):
be anything that's reallymonumentally different from my local
all the way through toproduction. And if I can do that,
then it's just so simple forus to do things like troubleshooting,
for us to think aboutdifferent ways that we can scale.
And again, one of the big waysthat we scale is our ability to add
new developers to theplatform. How can we bring people
(19:11):
on and it not feel like ittakes forever for anybody to be able
to contribute to theproduction code base. If you can
put a pull request in and getit merged into production in your
first week, I think we're successful.
Yeah, I think one of thethings that is always, like, rough
for building that first MVP isfiguring out the scope, right? It's
(19:36):
like, how much should it be?And I think a lot of people have
this, like, well, I got to getthat final thing out. And getting
the final thing out pisses offdevelopers because they've waited
a very long time for the finalthing, right? And I think one of
the key things is just gettingout something that works. And like,
that first KPI is - are peoplehappy with it? And like, that joining
(19:56):
the job, I sit down and like,it's... you never know. I mean, I'll
tell you the truth. I gothired at a job once. I quit an hour
and a half later. Like, it wasjust like, I started setting stuff
up, and I was just like... I'man hour and a half into a README,
and somebody's like, "Oh,that's the old version." And I was
like, "I'm out, guys. Like, I'v been reading... I've been copying
(20:17):
and pasting stuff that doesnot work for an hour and a half.
And this is the old README." Iwas just out. And it's just like,
when working on a platform,like, what really matters is, is
the user happy? Like that is ou job. It is a product. I want
my developers to be happy withit. I want it to be easy for them
to use and adopt and to getthere. Like, you can tell when you
(20:40):
sit down on a project, likeday one, you're like, "Okay, this
is going to be easy to set up.I'm going to be happy." And like,
if that happy path is a READMEin a Docker file - that's a minimal
platform. I'll tell you what,that's pretty simple. And progressing
that into the cloud... we havea lot of options to ship that container
and move it forward. I feellike there's so many orgs that still
kind of fight this simplicity.And again, you can be well-structured
(21:05):
and simple. And simple.AndIone of the things whe you embrace
simpler systems... and we justdid a huge migration at work recently,
we went from 26 microservicesback to a monolith. We fucking love
it. We move fast. Not only dowe move fast, AI when we're working
with it moves very fast aswell. But like, what is it about
(21:27):
going from that MVP where it'sstarting to make money to like post
Series A or post Series Bwhere teams just lose the thread
on simplicity? They just...they go hard on making things hard.
I feel like we lose so much inthat early stage, like from MVP through
Series A, where it's likestuff just starts to kind of smatter
out and we just make all sortsof crazy things. Like how do teams
(21:50):
keep it simple while keepingit efficient?
So I think the reason I seethat happen so often in my experience
is because developers craveproblems to solve and they crave
complexity. And so if theproblems that we're solving, like
in the business, if thosearen't complex, if those don't have,
(22:11):
aren't clearly defined, thenI'm going to find something. I'm
going to create complex, I'mgoing to create problems that I need
to solve. That's whenmicroservices come into play. That's
when like advanced event basedarchitectures and all sorts of crazy
things start to come intoplay. Because I need that complexity,
I need that challenge. And sofor me, what I like to do is put
some guardrails around, likethis is the architecture, you know,
(22:33):
at a high level, these are thetechnologies we use. And then I really...
because I know that's whatengineers really want, that's the
desire they have, especiallyengineers at certain phases of their
career. Let me find thatwithin the problems that we're solving.
Like, here's a really, reallyunique, interesting thing that we
need to solve. But it'salready within our context. We're
(22:54):
not creating new problemsbecause those new problems then become
the 26 microservices thatyou've got to now deal with.
Yeah, yeah. That'sinteresting, right? Like the engineers
are looking for something tosolve and that is what we do all
day, right? And it's funny,like, as you were saying that I could
feel like a laugh creeping inbecause I had flashbacks from my
(23:15):
years working in E-commerce.Which, like, I don't know... anybody
who's out there in E-commerce,I'm sure, like, if you're at Shopify,
you guys got some interestingsolves to work on. But it's like
everybody else working on likea Shopify clone, it's just like the
problems are all solved andthe software is super boring. It's
like I just Rails generatethis whole thing pretty much and
then you're just like, "Well,business problems are... inventory
(23:38):
is solved, shipping things issolved. What can I do that's interesting?
Let's split this Railsmonolith into a thousand rack Sinatra
servers." That is pretty spoton. You just laid out like, I think,
about three or four years ofmy life in the late two thousands.
We all did it, right? We alldid it. Yeah, it's just some of us
have been around long enoughto realize the impact of it.
(24:00):
You know what I think? I'mgetting this thought right now. We'll
see. Maybe this is my Dariofrom Anthropic moment - I don't think
software engineering jobs aregoing to be lost. I think PMs are. Software
engineers are going to becoming for those PM jobs because
we're going to look for theinteresting business problems to
solve and then we can justwizard software out. PMs better watch
(24:22):
out. We're coming for you.
Uh oh.
They thought it was the otherway. They thought they were going
to be able to do softwaredevelopment. No way, man. We're coming
for those interestingproblems. That one's not a threat,
but it is. Okay. Okay. So likesimplicity and scaling though. Your
point on like, you know,scaling starts from just being able
to scale a team. So how doessimplicity connect to scaling beyond
(24:44):
just teams? How does it gofrom scaling my team to scaling more
features? Because I feel likea lot of teams hear that like, "Oh,
if I'm scaling my team," butyou hear more people, "slower delivery."
How do you scale a team andmaintain simplicity while also maintaining
delivery cadence? I feel likethis is part of that golden triangle
(25:07):
where you're starting to kindof push and pull in different directions.
Like we have more people. Onecode base is hard, so we split up
the code base. But now puttingit all back together is hard. Like
how do you deal with that kindof split-join criteria and how teams
work? And scaling those teamsas you're trying to scale more features
and more revenue opposed tothat MVP when you're joining a team?
(25:28):
Yeah. So it's interesting,Cory. So I think about scale happening
in three ways. The first isour ability to add users, right.
And to your point, that's asolved problem. How can I add more
users to the platform whilemaintaining or improving performance
for every user? That's morehorsepower and there' a ton of things.
The second is our ability toadd developers. So that really comes
(25:50):
into the documentation, theecosystem that we build. You know,
what does the development looklike? What does our testing look
like? What does our releasestrategy look like? Can I merge right
in? Are we using featureflags? And that's similar for features,
right? The third way that wescale is our ability to add features.
And so adding features doesn'tjust mean, "Hey, let me bolt on more
(26:12):
features." Then we just end upwith this gigantic thing. It's, "Can
I add a feature, can I changeit, can I remove a feature without
it being a huge refactor wherewe have to spend a ton of time doing
it?" And a lot of that justcomes down to how modular is the
code, how interconnected arethings, you know, just really thinking
ahead of those things. And Ithink so much of our ability to scale
(26:36):
and focus on simplicity comesdown to the foundation that we lay.
What is the generalarchitecture that we have? What are
the pipelines that we haveavailable to us? What are the test
harnesses and all of thosethings? When we have all of that
in place, then we can movemuch more quickly and confidently.
(26:57):
And really it's thatconfidence that I think then gives
us that speed to know that ifI'm going to change this thing and
it broke something, I'm goingto know about it before it gets to
production and then ultimatelyto our customers.
Yeah. So what's reallyinteresting with that is... again,
like coming back to like thisgap in the success of AI, right?
Like right there you have itlike potentially like, like breaching
(27:19):
again. Like if I'm a teamthat's able to actually use AI and
use it effectively, and I'vedone so much of these good practices
that I'm able to ship softwarefaster, I'm able to add people to
my team faster, build softwarefaster. And then you have this team
over here that's stillstruggling with like the basics of
simplicity to even get theirhouse in order where they can ramp
(27:40):
their team up. Those teams arestill leaning into AI generated code
and some of them are gettingapps that work. And we know that
AI is a litter bug, right? Soit's almost like they are moving
themselves forward veryquickly to then go slow again. They're
going to reach just a barrierat some point in time. We've generated
so much code where it's noteasy to change things because these
(28:02):
things are litter bugs. And ifI'm lacking these common principles
about like how I should writesoftware, how we write efficient
software, how we write wellorganized and modular software, and
then Claude's just dumping a1,100 line function. Like, you don't
know your shit out of luckyet, but you're going to be in like
six to nine months. The messthey're in, I feel like that's a
(28:25):
great place for people likeyou to kind of come in.
Yeah, that's the opportunity.
There we go. That's a greatopportunity. So cleaning house, like
it really just comes down tolike cleaning house at the end of
the day. Like that is like oneof the cornerstone things that we
can do to make our teamsonboard easier, us AI. So when we're
thinking about that, we doover-engineer in the modern world,
(28:50):
right? Like when you'relooking at like some of these typical,
like modern over-engineeredstacks... you're coming in and you're
seeing... like, where are youseeing th unnecessary complexity
lean in? Like, are you justseeing teams who are like, "Oh, we
want to try a thousanddifferent programming languages"?
Or is it like open sourcelike-a-palooza? Where like, "Oh look,
another open source tool isout that we can install and run.
(29:12):
And what were we using thatfor? I don't know." What kind of
proliferation ofover-engineering are you typically
seeing in these stage companies?
Yeah, it's exactly that. Andyou know, I thought it was clever
a few years ago and came upwith resume driven design.
Oh yes.
Yes, Resume drivendevelopment, right? Somebody else
coined it, but that's what Isee a lot - "I want to add DynamoDB
(29:36):
and allofthesedifferentarchitecturesandplatformsasaserviceandallthesethingsjustsothatIcanputitonmyresume. SoIsee
alotofthat.Isee, resume." So Isee a lot of that. I see, you know,
again, "I toreallytry thisout. I'm inanymeaningfulway. SoI'mgoingtobringitinandI'm
going totellyou,dearEngineering Managerorcto,we
(29:58):
reallyneedthispiece oftechnologyforscale.Right?CTO"
Yeah.
You don't need kubernetes outof the gate, you just don't. Right.
You need a simple deploymentpipeline and that's it. And so I
see everywhere from kind ofthe Kubernetes, the container runtimes...
how that is orchestrated. Itend to see a lot of complexity there.
Microservices, which are justa ton of lambda functions, see a
(30:20):
ton of that. I see a lot ofjust using the wrong database. Everyone
wants to reach for the NoSQL,the Mongo, the DynamoDBs out of the
gate, but they haven't reallythought about their data structure.
And so then they end up withthese gigantic databases that are
inefficient for querying. So Imean for me it's like so much is
just a CRUD application.
(30:40):
Yeah, yeah, that one breaks myheart. I was in database administration
for years and seeing so manypeople reach for NoSQL... and there's
places where NoSQL is valid, Ilove Postgres, you can stick almost
anything inpoPostgresstgres.It'sgotsomeNoSQLinthere.It'sa fun
time... But I feel like thething that's always maddening about
like the overreach for NoSQLis a lot of times people reach for
(31:03):
it not because they're lookingfor the speed or eventual consistency,
they're looking for the nondrama of dealing with a database
migration. And it's just like,"Dude, you just made your life so
much fucking harder."Everything... there's a table, there's
a schema, your data has aschema. It either lives in the database
or it lives in your code, butthere's a schema that will be had
(31:26):
and it is much more beautifulwhen you can guarantee it at the
storage level. I'm just like,"Oh, you changed the code. So you
have no guarantees about thatfield anymore. That's harrowing."
I was just like, dude, theregion for NoSQL is just such an
(31:48):
early optimization. That justpierced my. Pierced me right in the
heart because I know it'strue. This might be a weird question,
but there's something thatI've been thinking about a lot recently,
and talking to a couple of mybuddies, and I kind of want to start
bringing it into the show abit... like I use AI every day and
like if you follow me onLinkedIn... everybody follows me
on LinkedIn... it sounds likeI hate AI. I use the shit out of
(32:10):
it. I barely write code. Istill write all my tests. I'll tell
you what, I write my testsfirst. I let Claude write all my
code, I write the tests. It'sthe perfect TDD relationship. I do
the refactoring because itwrites garbage code. That's my little
trick with simplicity. But Iuse it all day and I use it for all
sorts of stuff. But at thesame time it's like where are we
going with this thing? What doyou think 5 and 10 years looks like
(32:35):
from now with AI as adeveloper and as a non developer?
Sorry if that one's wild andout there but I really want to see
what engineers feel about thisbecause I feel like we're this very
interesting class of peoplewhere we're using it the most and
getting the most value out ofit. But we're also definitely on
a speedrun to completely justdamaging the number of people that
(32:58):
can work in this field. Idon't think we go away, I think you
start to see a lot less needand I probably see salaries drop
- as my personal opinion. ButI would love to know what is your
read on where this is going?Do you think it is going to be the
technology shift that we thinkit is? Where do you see this in 5
to 10 years for engineers andnon engineers?
Man, that's a good question. Iwould agree. I think we're going
(33:21):
to see more people. The peoplethat stay in the industry are the
ones that are reallypassionate about technology, right?
I think the people that gotinto the industry because it was
guaranteedsisix-figurexfiguresalaryout ofthe
gate,Ithinkthatcropoffolks aregoing to tend to kind of weed out
because they just aren't aspassionate about it. I think it's
going to require that passion.I agree, we're not going away, the
(33:44):
job role, the way we work isgoing to be different. I really don't
think there's a going to be adecrease in the desire for software.
Certainly not.
What it looks like,I think,may change. I don't know that like
some people are talking about,"Oh well, just spin up your own version
of whatever CRM and it'sinternal and you don't need to pay
(34:05):
your per seat licensinganymore." I don't know that that's
going to happen as muchbecause turns out you still have
to support that softwarethat's running even though you generated
it on the fly. I don't knowthat that's going to happen. I think
as software engineers,especially the ones of us that are
really adopting it, reallytrying to put it into our workflow
(34:27):
day in and day out, we're atthe advantage compared to our peers
that aren't. There are still alot of folks in software engineering
that just are resistant to itand probably will be until they're
kind of phased out of theindustry, I would imagine. And then
for our non-technicalcounterparts, I'm seeing their adoption
even quicker. They're playingwith the tools like the Lovables,
(34:48):
like the Replits and beingable to generate full applications.
They're really experimentingand then realizing, "Oh, this is
a lot harder than it lookslike to do a good job with it." But
I think that we're going tosee both sides continue to adopt
it more and more. You know, itstill feels like right now we're
experimenting and trying tofigure out where's a good spot for
(35:10):
me to fit this into my lifeand my work. So it's going to be
really interesting, and Ithink a very challenging next few
years, honestly.
Yeah, it's interesting becauselike I feel like my entire network
of people that are like in theengineering space - they love it
or they hate it. But even thepeople that are hate it are like,
(35:31):
"Eh, I hate it." Like I hateit, but at the same time I see the
value in it, right? And thenthere's people that just aren't successful
with it. I would honestly saylike some of the things you've talked
about at the beginning, likejust focusing on simplicity... Just
like the kind of things thatmake you onboard an engineer well
are the things that are goingto make you get good outputs from
(35:52):
a context when you're workingon any given feature that you're
working on. I don't know, man,it's just... it seems like we're
speed running, we're creatinga lot of gap between like the people
that know stuff and the peoplethat don't. And it just seems like
a pretty phenomenal gap isgoing to be there. And at the same
time like I don't see itslowing down unless the bubble pops.
(36:15):
I don't see it slowing down.And if the bubble pops, I honestly
think people are going to bestruggling to grab fragments of this
thing and like, bring itin-house. Like, I know, the open
source LLMs aren't great withCodeGen, but, like, this is going
to be very hard for a lot ofpeople to go back from, if the bubble
pops. Sitting where we aretoday, it's so hard. I feel like
(36:37):
it's so hard to build abusiness. It's so hard to think about
your career. There's just somuch that's going to be different
nine months from now that it'sso hard to plan for three months
from now. And I feel likethat's the first time we've had that
problem in softwareengineering before. And some of them
are like, "Oh, we're going tosit down the next three months and
(36:57):
plan out the next year offeatures that we're going to release."
And now it's like, "Shit,like, we're building so much in this
AI thing. Like, the bubblemight pop sometime next year and
then our software is gone." Orlike, "I don't know how to write
software anymore because AIdoes it for me." And then the bubble
pops and like, "Shit, I don'tknow how to write software anymore."
Like, those are potential,like real worlds that we have coming.
And I know that, like, despitethe fact that I hate it, that would
(37:20):
fuck me up.
I mean, dude, it's changed myhiring strategy on teams. Yeah. You
know, completely shifted thataround. Yeah. I mean, it's part of
one of the qualifiers when I'mlooking at new team members to join
- not are you using it, buthow are you using it and how are
you exploring and how are youlearning? It feels like early days
(37:40):
in my career where I was justimmersed in every, you know, every
tutorial, every course,anything I could find that I could
get my hands on, I was goingthrough and doing. And it feels like
I'm doing the same thing justwith AI and some of these tools.
It's pretty wild, man.
Yeah. So going back to resumedriven development, just had a thought
when you mentioned thatearlier, because I feel like I see
(38:00):
a lot of these resumes too,where it's just, it's a buzzword
palooza. And I'll tell youwhat, like, the buzzwords are important.
You do have to communicatethat you understand the technology
that the job description is,is describing that you need to know
how to use. But if you'relistening and like, you're you're
struggling to find a job rightnow, I'll tell you, there's three
(38:21):
sexy keywords that everyhiring manager loves. The word dollars,
the word increased revenue,and cutting costs and having numbers
around all three of thosewords. And if you have that on your
resume, your resume looks waybetter than the person next to it
that just says Kubernetes,OTel, Jaeger or whatever. If it's
Kubernetes costs saved,Kubernetes revenue increased - like,
(38:47):
those are key words. And Ithink that's one of the things that
I feel like when people areworking on their resumes. Like, dude,
like, your whole point ingetting that cool job where you get
to solve cool problems is thatbusiness wants to make money. And
that's the same thing the nextbusiness wants to do. They don't
want to deploykKubernetesubernetes. to make money.
And yourbosbosswantstomakemoneybecausehe'sgoingtomakemoremoneyif thewhole
company's makingmoremoney.more money. It's like 5 havesomethingabout,like,howyouimpactedthebusiness.
(39:16):
Ifeel likethat'soneofthosebusiness. I youknow,kindofgoingback
those places where... youknow, kind beingfocusedon,like,the
business crazy shit... like,not being focused on the business
part of the business, asjustgooffintotheweedslooking forotherthingstosolve.
There'sinterestingthingshappeninginyourbusiness andifyouunderstandthenumbers,you're
goingto understandalotmoreabout,like,thebusinessasawhole.Andthere'sinteresting problems
(39:40):
theretosolve andcapturethoselot more about the business goingtomake
yourjobhuntsomucheasier.Sorry,thatwas to solve
and capture those numbers andput them on your resume. It's going
to make your job hunt so mucheasier. Sorry, that was just... you
time today.Thisis and I'm justlike, "Yes, I've seen so much rdd."
(40:00):
Oh, man, awesome. Well, Ireale this-it's
Best place to find me is onLinkedIn - Brian-Childress. You know,
fairly prolific on there. Loveto connect.
Awesome. Well, thanks so muchfor coming on the show. I really
appreciate the time and we'lltalk to you soon.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Breakfast Club
The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy, Jess Hilarious, And Charlamagne Tha God!