Simplicity at Scale: Cleaning House for Platform Teams with Brian Childress

Cory: 00:00:00

Welcome back to the Platform Engineering Podcast. I'm your host, Cory O'Daniel.

If you haven't got to hear the past couple of episodes, we had three episodes back to back with Kelsey Hightower guest hosting. Go check those out. Those over the past, I think, two months or so. And then last week we had a really great episode on Policy as Code and Kyvrno. I would definitely check it out. Not to scare Brian, but it is by far my most clipped episode I've ever recorded. It has so many great takes. I've got Brian with me here today, though he is now on the spot, he's going to have to have a ton of great takes today.

We've got Brian Childress, he's a technology leader, fractional CTO. He helps teams simplify platforms, improve developer experience, and build systems at scale. We're going to get into some of the problems he sees most often why simplicity matters more than people think. And also on how AI is shifting the way we build software.

Brian, welcome to the show, thanks so much for joining us.

Brian: 00:01:07

Cory, man, it's great to be here.

Cory: 00:01:08

Yeah. Where are you based out of?

Brian: 00:01:10

Richmond, Virginia.

Cory: 00:01:12

Richmond, Virginia. Okay. So for folks that aren't familiar with your background, you were actually an outdoor guide before, like getting into technology.

Brian: 00:01:21

Yeah. Yep.

Cory: 00:01:22

You did the reverse of what I think every software engineer I know wants to do. They're software engineers and they're like, "Oh, my gosh, I'm over this. When AI is here, I'm moving out into the woods and I'm going to be a nature guide." And you're like, "These woods ain't for me. I'm gonna go sit in the data center." What's going on, man?

Brian: 00:01:39

That's basically what happened, man.

So, yeah, early on, when I was looking at going to college and all of that, I followed the advice of, "Follow your passions and you'll never have to work a day in your life." And I was passionate about rock climbing and kayaking and all the fun adventure outdoor activities. And so I went in and got a degree focused in that area, went and guided for a few years. Absolutely loved the work, really enjoyed it.

But I found it was really missing something. One, it didn't pay amazing, so that was part of it. But I really wasn't getting the kind of the intellectual challenge that I was looking for. And so I went on a hunt to find something else and landed in technology.

It's funny, when I first started, I was like, "Man, I don't want to be the guy sitting behind a computer for 8, 10, 12 hours a day." And, you know, heck, now I spend 14 hours a day behind one and love what I do, so it's good.

Cory: 00:02:36

That's very cool. So when you first, like, did the transition, was it just like, "Hey, I'm gonna go, like, back to school. I'm gonna go get a degree in computer science"? Or was it just like, "Hey, I'm gonna go start learning the program on my own"? Like, how did you move over into this world?

Brian: 00:02:50

Kind of a little bit of both. The intermediate step was I went back to graduate school and focused on Geographic Information System, so GIS.

Cory: 00:02:58

Right, okay.

Brian: 00:02:59

Maps and, you know, big data sets and that kind of thing. And when I got into it, we, you know, as part of it... as, you know, data manipulation and all of that... started to learn Python.

And at the time, you know, 20 years ago, I thought Python was an outdated language that, you know, I was like, "No one's going to ever use this." I was wrong.

Cory: 00:03:19

Yeah, a tad.

Brian: 00:03:22

Yeah.

So I got into it, really found that I enjoyed, like, the building aspect of it, the creation of software, and just, you know, it snowballed from there. I continued to kind of work in my graduate work, but then I was also, like, learning all sorts of different languages and frameworks on the side.

Cory: 00:03:39

I feel like everybody I know that... when I look at, like, my friends that come from different backgrounds that work in software... I've got buddies, you know, they went to school for whatever, they're doing their job for, like, 10 years, and they went to a boot camp. And I feel like all of those people are just, like, fully in the JavaScript camp.

And then whenever I meet somebody who's like, "Hey, I'm into software now. And I came this way through Python." They always have like a very interesting, like, world that 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 I work in AI." It's just like they move over. And Python is... I feel like it's a gateway drug for people that have really interesting careers just kind of slowly becoming absorbed into the cloud.

That's cool. Yeah. Python was a very... I feel like over the past few years, Python was quite the surprise of a language to come in and start to dominate so many areas. I feel like I've always programmed in Edgy cool languages, like Elixir and Erlang. And then just seeing just the proliferation of JavaScript through the end of the two thousand tens and then just Python's everywhere now... was very, very surprising to me.

When you go in and work with teams, like how are you working on those things? Are you going into teams that are doing like Python AI stuff? Are you going in and kind of doing fractional work at all different types of organizations? Or are you focusing more on the AI side of the house?

Brian: 00:05:11

I mean, AI is definitely foundational for every project that I'm working on now. I tend to come into projects once they're already kind of up and running.

They have... call it an MVP. They have something working, they have paying customers on it, and they're starting to hit some scaling challenges. That's typically where I come in and really help to stabilize. And often it's just simplify what they have so that they can actually start to think about scale.

Cory: 00:05:39

Yeah. So like with all the teams starting to, I guess, experiment with like AI projects now, I feel like it's... I mean it's obviously everywhere now. How this ends up in the next couple of years we will see.

I'm not necessarily as excited as my face says that I am, but there's so many of these teams that they're building something new, they're building stuff in AI.

With all the orgs you've already worked with, kind of the experience you've seen, what do you think is some of the most common, I guess hurdles or problems for like earlier stage teams? These teams that have this MVP, they're starting to see revenue, and they want to start using AI. What is their biggest hurdle to having a successful use of it?

Is it more so using it internally for building? Or is it like actually getting to that point where it's a part of their product? Because I see a lot of teams doing it and I also see like these reports of like 90% of orgs are not seeing value on the other side. I'm really curious where people are getting stuck.

Brian: 00:06:38

Yeah.

So I think on the development side where I see most people getting stuck is we write in a very brief prompt and we let it spit out whatever it's going to spit out and we say, "Ah, this isn't any good." But a lot of teams I'm seeing really just aren't investing the time to understand the tools, to stick with one tool for more than a week, to really like hone and guide that tool. The same way... you know, many of us have compared it to a junior engineer joining our team. We've got to spend some time with that person, that thing, and really kind of guide it. Yeah, so really where I see a lot of teams struggle is we kind of just throw hope at the AI tool and hope that it's going to generate what we're looking for.

Cory: 00:07:20

Yeah.

Brian: 00:07:20

And then on the kind of product integration side, it's really a lot more simple than many people maybe think it can be or will be.

So a lot of, you know, chat interfaces and a lot of digestion of big repositories of information and knowledge bases and those sorts of things, that's where I'm seeing most companies really, really get some value. But again, we have to kind of slightly tweak the paradigm of how we think about the software engineering.

But for me, I found that it tends 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 of information that I'm doing some sort of query on if it's a RAG database or something like that. So the paradigms are really very similar. It's just a slightly different approach that we have to take.

Cory: 00:08:10

Yeah. I think, you know, just from seeing where people kind of like stumble a bit in, like, the development process... I like that analogy of, like, bringing on a junior engineer. I mean, there's companies that do a very good job of that, and there's companies that do a very bad job of that.

And I feel like those companies, the companies do a very good job of that. You see things where it's like, the READMEs are up to date, they've got best practices and like, linting guides and configurations all figured out. Like, your first day on the job, you Docker up something and like, it's running, and you get a PR into prod day one. That experience is very rare in a company.

The other experience, where it takes three days to set up your desktop. You're looking at old docs for how everything works. That's where many companies are.

And I feel like the companies that need it are this company over here - the companies that are already kind of like, "It's hard to onboard a junior." And then the companies that are like, "We're very good at onboarding juniors" are very good at using those same assets to drive context for using AI as a part of their workflow.

So I guess this predates just being in the AI space, but as a CTO and tech leader that's coming into orgs, how do you get a team to even onboard a junior engineer well? Such that they can onboard these AI agent engineers. What are some of the things you see people struggle with there?

Brian: 00:09:36

It's exactly that. It's how simple is it for me to get up and running? How quickly can I do it? How much time am I going to be stealing from our most senior engineer, who's the only person that really knows the system?

And so when I come into an organization, that's my number one goal - to get to a point where somebody can just, "Here's the link to the repo, download it, let it download half the Internet and then run Docker up, and you're running. You've got the entire stack right there on your machine." Because if I'm honest most platforms, most applications out there, they can do that. They don't need to be as complex as we make them. And so if we can get to that point, then it's just amazing.

And when I talk about scale, our ability to scale the number of developers is one of those areas that we really have to focus. And it comes down to - what does onboarding look like? How maintainable, how understandable is that code base? So that I can just, "Here's the README, here's a set of instructions, let me know when you get to that point."

Cory: 00:10:37

Yeah, I think that's one of the things that always surprises people, like when I show them how I develop and use AI - the amount of just docs that we feed into it, like before any prompt.

We do architecture decision records of like how we got to why things are the way they are. Like we do domain driven design, but like domain models that are like fully detailed. Like we give it so much context and we get a ton out of it.

But I think this is one of those places where you really start to see... you know, people say this all the time, "Like AI is really good... like looking at LLM output is great if you understand the domain, and if you don't understand the domain, it's going to be so hard for you to spot all the red herrings and hallucinations."

I feel like this is one of those places where 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 your engineering org, this is going to be so much harder for you.

Brian: 00:11:27

Yeah, 1 million percent.

Cory: 00:11:29

Absolutely.

Brian: 00:11:30

And I think another shift that I'm really seeing too is so many of us, from an engineering standpoint, really need to start thinking much more like an architect in that way. Like, what are the decisions? What are the reasons behind those decisions? Documenting it in a clear way that everyone on the team can understand it.

Again, that benefits everyone on the team and whatever AI agents we bring on board.

Cory: 00:11:53

Yeah, something I'd love to just kind of pick your brain... and if it's like so off-topic, please let me know... I see this happen with a lot of organizations that I've worked with in my day job, but also I have friends that are trying to kind of solve problems in this space right now and I see them kind of struggling with this... I'd love to know, just like, based off the orgs that you've worked with - and I know that you're probably more on like the AI side,but on like the DevOps side of the house, like when we kind of think about the work that folks are trying to start to automate and incorporate AI into like our DevOps workflows - one of the things that I think is very different about DevOps and even platform engineering to some degree than our traditionally developed services that we have, like for the app team that they're working on is like the app team's app is like a pretty cohesive domain...maybe, maybe not in the domain driven design sense... but like, this is the billing app, or this is the image app, or this is the checkout app.

And one of the things I think that becomes a bit difficult with generating like code for AI and generating things for just operations in general is that like, the stakeholders involved in production is just so much more massive and the context is huge. And so understanding how my app works, it's like, "Hey, I got some metrics, I got some source code, my app's running."

But understanding the DevOps side of the world, doing the AI and automation seems so much harder because it's like the CFO is concerned about costs, the CISO is concerned about security, legal team's concerned about compliance, the app team's concerned their app's not fast enough. Right?

And so like, for teams where their job just involves so many concerns and so many stakeholders, like, have you seen other places where they have like a similar problem and have gotten successful use of AI out of it? Because when I see these teams like trying to do this, like there's just so much to pull in. It's hard to kind of cobble it into a handful of MCP servers. It's just so much data that you're like, "Oh shit. I don't know if I want to be like feeding all my Datadog logs to this, you know, black box monster machine."

Brian: 00:13:59

Right.

Cory: 00:14:00

So like within these teams they have these just like diaspora of stakeholders and data. Like have you seen any really good strategies for kind of bringing that in to workflows? Or is that just... are we just not there yet? Or is that like agents of agents and agents of agents of agents and stuff like that?

Brian: 00:14:15

I really haven't seen it successfully kind of roll out.

You know, I'm seeing different integrations tying MCPs together to, you know, track progress for certain projects and you know, tying it all the way down to commit histories and just starting to bring a lot of that data that we would try and like parse our way through as like a tech lead or a CTO starting to bring that together. But really I haven't seen that big corpus of data.

And I think a lot of it is not only, you know, there's just so much, it's, you know, in so many different places, we might not even know about it, but also then the security aspect as well. Like in my ship, how much am I shipping off?

So I would imagine we're going to see quite a bit, you know, shift in that way in the industry over the next year or two. Yeah, I haven't really seen anything huge successful yet.

Cory: 00:15:03

Yeah, yeah, I mean I think it's exciting. Like seeing some of the folks that are in the next YC batch, like I see them on, you know, on Bookface, talking about like the problems they're working on, but it just seems like, when you think about production, like a production app, it's like it is just so hard to even define like what is prod. Like you have like the overlays of like, "Eh, maybe it's this network - it's partially staging, partially prod." Like there's just so many blurry lines. It feels so hard to really get a good context for. It's like, "Hey, is this thing going to make good operational decisions?"

It still feels like we're years out from that. And that's one of the things that I think also is kind of, I think creating a gap in adoption is it feels so far away for so many operations in here.

I feel like you don't see as many people using AI, like in our space, like writing Infrastructure as Code and doing things around operations because it just seems so hard and complex and therefore like we're falling behind a bit. You know what I mean?

Brian: 00:15:59

Yeah, yeah, definitely.

Host read ad: 00:16:04

Ops teams, you're probably used to doing all the heavy lifting when it comes to infrastructure as code wrangling root modules, CI/CD scripts and Terraform, just to keep things moving along. What if your developers could just diagram what they want and you still got all the control and visibility you need?

That's exactly what Massdriver does. Ops teams upload your trusted infrastructure as code modules to our registry.Your developers, they don't have to touch Terraform, build root modules, or even copy a single line of CI/CD scripts. They just diagram their cloud infrastructure. Massdriver pulls the modules and deploys exactly what's on their canvas. The result?

It's still managed as code, but with complete audit trails, rollbacks, preview environments and cost controls. You'll see exactly who's using what, where and what resources they're producing, all without the chaos. Stop doing twice the work.

Start making Infrastructure as Code simpler with Massdriver. Learn more at Massdriver.cloud.

Cory: 00:17:02

So opposite of operations is simplicity. And this is something that you're big on. So I want to come back to this a bit.

So in the pre-show you talked about simplicity and what I was curious is - when we think about platforms, like, what does a simple platform actually look like? Like you're joining a company, you know, you're coming in as an early platform engineer, they've already got a smattering of developers building some stuff. Like what does a good MVP look like?

As a fractional CTO coming in saying, "Okay, we've got these teams, they're starting to do all this stuff in the cloud, but there's no conformity, no governance, no nothing kind of sitting over it." What does a good baseline platform look like that sits in this realm of simplicity, but also empowers you to act and self-serve on your own?

Brian: 00:17:46

For me, I start at the local development story. What does it look like for me to again download the repository, run a command and I'm up and running? My goal is 30 minutes I can do that, maybe an hour. But I can do it. I don't have to do some weird connection, I don't need a bunch of, you know, random credentials.

If I can simplify it down to that level, I've got a handful of containers that are running locally, then it's nice and simple. That then just continues up as we move up in environments. And then from there, like, okay, cool, we have a staging environment. And for me, that's an environment that everyone can access. That's where developers feel like they can go in and test and see and do. And we can drop the database and we can read, seed it and, you know, do all of those things. And so that gives us a lot of control and visibility into how things are operating. And then we have production.

And production should look identical to staging. It's just separated, right? It's just different. It's more horsepower. But there shouldn't be anything that's really monumentally different from my local all the way through to production. And if I can do that, then it's just so simple for us to do things like troubleshooting, for us to think about different ways that we can scale.

And again, one of the big ways that we scale is our ability to add new developers to the platform. How can we bring people on and it not feel like it takes forever for anybody to be able to contribute to the production code base. If you can put a pull request in and get it merged into production in your first week, I think we're successful.

Cory: 00:19:26

Yeah, I think one of the things that is always, like, rough for building that first MVP is figuring out the scope, right? It's like, how much should it be? And I think a lot of people have this, like, well, I got to get that final thing out.

And getting the final thing out pisses off developers because they've waited a very long time for the final thing, right? And I think one of the key things is just getting out something that works. And like, that first KPI is - are people happy with it?

And like, that joining the job, I sit down and like, it's... you never know. I mean, I'll tell you the truth. I got hired at a job once. I quit an hour and a half later. Like, it was just like, I started setting stuff up, and I was just like... I'm an 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've been reading... I've been copying and pasting stuff that does not work for an hour and a half. And this is the old README." I was just out.

And it's just like, when working on a platform, like, what really matters is, is the user happy? Like that is our job. It is a product. I want my developers to be happy with it. I want it to be easy for them to use and adopt and to get there.

Like, you can tell when you sit down on a project, like day 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 README in a Docker file - that's a minimal platform. I'll tell you what, that's pretty simple. And progressing that into the cloud... we have a lot of options to ship that container and move it forward.

I feel like there's so many orgs that still kind of fight this simplicity. And again, you can be well-structured and simple. And I feel like one of the things when you embrace simpler systems... and we just did a huge migration at work recently, we went from 26 microservices back to a monolith. We fucking love it. We move fast. Not only do we move fast, AI when we're working with it moves very fast as well.

But like, what is it about going from that MVP where it's starting to make money to like post Series A or post Series B where teams just lose the thread on simplicity? They just... they go hard on making things hard.

I feel like we lose so much in that early stage, like from MVP through Series A, where it's like stuff just starts to kind of smatter out and we just make all sorts of crazy things. Like how do teams keep it simple while keeping it efficient?

Brian: 00:21:53

So I think the reason I see that happen so often in my experience is because developers crave problems to solve and they crave complexity.

And so if the problems that we're solving, like in the business, if those aren't complex, if those don't have, aren't clearly defined, then I'm going to find something. I'm going to create complex, I'm going to create problems that I need to solve. That's when microservices come into play.

That's when like advanced event based architectures and all sorts of crazy things start to come into play. Because I need that complexity, I need that challenge.

And so for me, what I like to do is put some guardrails around, like this is the architecture, you know, at a high level, these are the technologies we use. And then I really... because I know that's what engineers really want, that's the desire they have, especially engineers at certain phases of their career. Let me find that within the problems that we're solving. Like, here's a really, really unique, interesting thing that we need to solve. But it's already within our context. We're not creating new problems because those new problems then become the 26 microservices that you've got to now deal with.

Cory: 00:23:01

Yeah, yeah. That's interesting, right? Like the engineers are looking for something to solve 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 in because I had flashbacks from my 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 interesting solves to work on. But it's like everybody else working on like a Shopify clone, it's just like the problems are all solved and the software is super boring. It's like I just Rails generate this whole thing pretty much and then you're just like, "Well, business problems are... inventory is solved, shipping things is solved. What can I do that's interesting? Let's split this Rails monolith into a thousand rack Sinatra servers."

That is pretty spot on. You just laid out like, I think, about three or four years of my life in the late two thousands.

Brian: 00:23:53

We all did it, right? We all did it. Yeah, it's just some of us have been around long enough to realize the impact of it.

Cory: 00:24:00

You know what I think? I'm getting this thought right now. We'll see. Maybe this is my Dario from Anthropic moment - I don't think software engineering jobs are going to be lost. I think PMs are. Software engineers are going to be coming for those PM jobs because we're going to look for the interesting business problems to solve and then we can just wizard software out. PMs better watch out. We're coming for you.

Brian: 00:24:23

Uh oh.

Cory: 00:24:24

They thought it was the other way. They thought they were going to be able to do software development. No way, man. We're coming for those interesting problems. That one's not a threat, but it is.

Okay. Okay. So like simplicity and scaling though. Your point on like, you know, scaling starts from just being able to scale a team. So how does simplicity connect to scaling beyond just teams? How does it go from scaling my team to scaling more features?

Because I feel like a lot of teams hear that like, "Oh, if I'm scaling my team," but you hear more people, "slower delivery." How do you scale a team and maintain simplicity while also maintaining delivery cadence?

I feel like this is part of that golden triangle where you're starting to kind of push and pull in different directions. Like we have more people. One code base is hard, so we split up the code base. But now putting it all back together is hard.

Like how do you deal with that kind of split-join criteria and how teams work? And scaling those teams as you're trying to scale more features and more revenue opposed to that MVP when you're joining a team?

Brian: 00:25:28

Yeah. So it's interesting, Cory. So I think about scale happening in three ways.

The first is our ability to add users, right. And to your point, that's a solved problem. How can I add more users to the platform while maintaining or improving performance for every user? That's more horsepower and there's a ton of things.

The second is our ability to add developers. So that really comes into the documentation, the ecosystem that we build. You know, what does the development look like? What does our testing look like? What does our release strategy look like? Can I merge right in? Are we using feature flags? And that's similar for features, right?

The third way that we scale is our ability to add features. And so adding features doesn't just mean, "Hey, let me bolt on more features." Then we just end up with this gigantic thing. It's, "Can I add a feature, can I change it, can I remove a feature without it being a huge refactor where we have to spend a ton of time doing it?" And a lot of that just comes down to how modular is the code, how interconnected are things, you know, just really thinking ahead of those things.

And I think so much of our ability to scale and focus on simplicity comes down to the foundation that we lay.

What is the general architecture that we have? What are the pipelines that we have available to us? What are the test harnesses and all of those things? When we have all of that in place, then we can move much more quickly and confidently.

And really it's that confidence that I think then gives us that speed to know that if I'm going to change this thing and it broke something, I'm going to know about it before it gets to production and then ultimately to our customers.

Cory: 00:27:09

Yeah. So what's really interesting with that is... again, like coming back to like this gap in the success of AI, right? Like right there you have it like potentially like, like breaching again. Like if I'm a team that's able to actually use AI and use it effectively, and I've done so much of these good practices that I'm able to ship software faster, I'm able to add people to my team faster, build software faster.

And then you have this team over here that's still struggling with like the basics of simplicity to even get their house in order where they can ramp their team up. Those teams are still leaning into AI generated code and some of them are getting apps that work. And we know that AI is a litter bug, right? So it's almost like they are moving themselves forward very quickly to then go slow again. They're going to reach just a barrier at some point in time. We've generated so much code where it's not easy to change things because these things are litter bugs. And if I'm lacking these common principles about like how I should write software, how we write efficient software, how we write well organized and modular software, and then Claude's just dumping a 1,100 line function. Like, you don't know your shit out of luck yet, but you're going to be in like six to nine months.

The mess they're in, I feel like that's a great place for people like you to kind of come in.

Brian: 00:28:30

Yeah, that's the opportunity.

Cory: 00:28:31

There we go. That's a great opportunity. So cleaning house, like it really just comes down to like cleaning house at the end of the day. Like that is like one of the cornerstone things that we can do to make our teams onboard easier, use AI.

So when we're thinking about that, we do over-engineer in the modern world, right? Like when you're looking at like some of these typical, like modern over-engineered stacks... you're coming in and you're seeing... like, where are you seeing the unnecessary complexity lean in?

Like, are you just seeing teams who are like, "Oh, we want to try a thousand different programming languages"? Or is it like open source like-a-palooza? Where like, "Oh look, another open source tool is out that we can install and run. And what were we using that for? I don't know."

What kind of proliferation of over-engineering are you typically seeing in these stage companies?

Brian: 00:29:19

Yeah, it's exactly that. And you know, I thought it was clever a few years ago and came up with resume driven design.

Cory: 00:29:26

Oh yes.

Brian: 00:29:27

Yes, Resume driven development, right? Somebody else coined it, but that's what I see a lot - "I want to add DynamoDB and you know, all of these different architectures and platforms as a service and all these things just so that I can put it on my resume." So I see a lot of that.

I see, you know, again, "I want to try this out. I'm not going to have a chance to really try it out on my own in any meaningful way. So I'm going to bring it in and I'm going to tell you, dear Engineering Manager or CTO, we really need this piece of technology for scale." Right?

Cory: 00:30:01

Yeah.

Brian: 00:30:02

You don't need kubernetes out of the gate, you just don't. Right. You need a simple deployment pipeline and that's it.

And so I see everywhere from kind of the Kubernetes, the container runtimes... how that is orchestrated. I tend to see a lot of complexity there. Microservices, which are just a ton of lambda functions, see a ton of that. I see a lot of just using the wrong database. Everyone wants to reach for the NoSQL, the Mongo, the DynamoDBs out of the gate, but they haven't really thought about their data structure. And so then they end up with these gigantic databases that are inefficient for querying.

So I mean for me it's like so much is just a CRUD application.

Cory: 00:30:40

Yeah, yeah, that one breaks my heart. I was in database administration for years and seeing so many people reach for NoSQL... and there's places where NoSQL is valid, I love Postgres, you can stick almost anything in Postgres. It's got some NoSQL in there. It's a fun time... But I feel like the thing that's always maddening about like the overreach for NoSQL is a lot of times people reach for it not because they're looking for the speed or eventual consistency, they're looking for the non drama 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 a schema. It either lives in the database or it lives in your code, but there's a schema that will be had and it is much more beautiful when you can guarantee it at the storage level.

I'm just like, "Oh, you changed the code. So you have no guarantees about that field anymore. That's harrowing."

I was just like, dude, the region for NoSQL is just such an early optimization. That just pierced my. Pierced me right in the heart because I know it's true.

This might be a weird question, but there's something that I've been thinking about a lot recently, and talking to a couple of my buddies, and I kind of want to start bringing it into the show a bit... like I use AI every day and like if you follow me on LinkedIn... everybody follows me on LinkedIn... it sounds like I hate AI. I use the shit out of it. I barely write code. I still write all my tests. I'll tell you what, I write my tests first. I let Claude write all my code, I write the tests. It's the perfect TDD relationship. I do the refactoring because it writes garbage code. That's my little trick with simplicity.

But I use it all day and I use it for all sorts of stuff. But at the same time it's like where are we going with this thing?

What do you think 5 and 10 years looks like from now with AI as a developer and as a non developer?

Sorry if that one's wild and out there but I really want to see what engineers feel about this because I feel like we're this very interesting class of people where we're using it the most and getting the most value out of it. But we're also definitely on a speedrun to completely just damaging the number of people that can work in this field. I don't think we go away, I think you start to see a lot less need and I probably see salaries drop - as my personal opinion.

But I 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 think it is? Where do you see this in 5 to 10 years for engineers and non engineers?

Brian: 00:33:17

Man, that's a good question. I would agree. I think we're going to see more people.

The people that stay in the industry are the ones that are really passionate about technology, right? I think the people that got into the industry because it was guaranteed six-figure salary out of the gate, I think that crop of folks are going to tend to kind of weed out because they just aren't as passionate about it. I think it's going to require that passion.

I agree, we're not going away, the job role, the way we work is going to be different.

I really don't think there's a going to be a decrease in the desire for software.

Cory: 00:33:53

Certainly not.

Brian: 00:33:54

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's internal and you don't need to pay your per seat licensing anymore." I don't know that that's going to happen as much because turns out you still have to support that software that's running even though you generated it on the fly. I don't know that that's going to happen.

I think as software engineers, especially the ones of us that are really adopting it, really trying to put it into our workflow day in and day out, we're at the advantage compared to our peers that aren't. There are still a lot of folks in software engineering that just are resistant to it and probably will be until they're kind of phased out of the industry, I would imagine.

And then for our non-technical counterparts, I'm seeing their adoption even quicker. They're playing with the tools like the Lovables, like the Replits and being able to generate full applications. They're really experimenting and then realizing, "Oh, this is a lot harder than it looks like to do a good job with it."

But I think that we're going to see both sides continue to adopt it more and more. You know, it still feels like right now we're experimenting and trying to figure out where's a good spot for me to fit this into my life and my work. So it's going to be really interesting, and I think a very challenging next few years, honestly.

Cory: 00:35:19

Yeah, it's interesting because like I feel like my entire network of people that are like in the engineering space - they love it or they hate it. But even the people that are hate it are like, "Eh, I hate it." Like I hate it, but at the same time I see the value in it, right? And then there's people that just aren't successful with it.

I would honestly say like some of the things you've talked about at the beginning, like just focusing on simplicity... Just like the kind of things that make you onboard an engineer well are the things that are going to make you get good outputs from a context when you're working on 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 creating a lot of gap between like the people that know stuff and the people that don't. And it just seems like a pretty phenomenal gap is going to be there. And at the same time like I don't see it slowing down unless the bubble pops.

I don't see it slowing down. And if the bubble pops, I honestly think people are going to be struggling to grab fragments of this thing and like, bring it in-house. Like, I know, the open source LLMs aren't great with CodeGen, but, like, this is going to be very hard for a lot of people to go back from, if the bubble pops.

Sitting where we are today, it's so hard. I feel like it's so hard to build a business. It's so hard to think about your career. There's just so much that's going to be different nine months from now that it's so hard to plan for three months from now. And I feel like that's the first time we've had that problem in software engineering before.

And some of them are like, "Oh, we're going to sit down the next three months and plan out the next year of features that we're going to release." And now it's like, "Shit, like, we're building so much in this AI thing. Like, the bubble might pop sometime next year and then our software is gone." Or like, "I don't know how to write software anymore because AI does it for me." And then the bubble pops and like, "Shit, I don't know how to write software anymore." Like, those are potential, like real worlds that we have coming. And I know that, like, despite the fact that I hate it, that would fuck me up.

Brian: 00:37:22

I mean, dude, it's changed my hiring strategy on teams. Yeah. You know, completely shifted that around. Yeah. I mean, it's part of one of the qualifiers when I'm looking at new team members to join - not are you using it, but how are you using it and how are you exploring and how are you learning? It feels like early days in my career where I was just immersed in every, you know, every tutorial, every course, anything I could find that I could get my hands on, I was going through and doing. And it feels like I'm doing the same thing just with AI and some of these tools. It's pretty wild, man.

Cory: 00:37:55

Yeah.

So going back to resume driven development, just had a thought when you mentioned that earlier, because I feel like I see a lot of these resumes too, where it's just, it's a buzzword palooza. And I'll tell you what, like, the buzzwords are important. You do have to communicate that you understand the technology that the job description is, is describing that you need to know how to use.

But if you're listening and like, you're you're struggling to find a job right now, I'll tell you, there's three sexy keywords that every hiring manager loves. The word dollars, the word increased revenue, and cutting costs and having numbers around all three of those words.

And if you have that on your resume, your resume looks way better than the person next to it that just says Kubernetes, OTel, Jaeger or whatever. If it's Kubernetes costs saved, Kubernetes revenue increased - like, those are key words.

And I think that's one of the things that I feel like when people are working on their resumes. Like, dude, like, your whole point in getting that cool job where you get to solve cool problems is that business wants to make money. And that's the same thing the next business wants to do. They don't want to deploy Kubernetes. They want to make money. And your boss wants to make money because he's going to make more money if the whole company's making more money.

It's like 5 out of 100 resumes will even have something about, like, how you impacted the business. I feel like that's one of those places where... you know, kind of going back to people building crazy shit... like, not being focused on the business part of the business, as a software engineer, I think is one of those things that can cause you to just go off into the weeds looking for other things to solve.

There's interesting things happening in your business and if you understand the numbers, you're going to understand a lot more about the business as a whole. And there's interesting problems there to solve and capture those numbers and put them on your resume. It's going to make your job hunt so much easier.

Sorry, that was just... you said that earlier and I'm just like, "Yes, I've seen so much rdd."

Oh, man, awesome. Well, I really appreciate this - it's super fun. I really had a great time today. This is very fun. I appreciate you coming on the show. Where can people find you online? Where do you write?

Brian: 00:40:02

Best place to find me is on LinkedIn - Brian-Childress. You know, fairly prolific on there. Love to connect.

Cory: 00:40:08

Awesome. Well, thanks so much for coming on the show. I really appreciate the time and we'll talk to you soon.