Lane Wagner is the Founder of Boot.dev. He joins the show to talk about his blog post, "Are You a DevOps Engineer if You Aren't Writing Code?". They begin by outlining their personal definitions of what a DevOps and a DevOps Engineer mean to them.

 

What's going on everybody? Welcome to another episode of Adventures in DevOps. I will be your host today. I'm Will Button. Joining me in the studio is my co-host, Jonathan Hall.

 

Hey everyone, how's it going?

 

And our special guest today, Lane Wagner. Welcome, Lane.

 

Hey, thanks for having me.

 

Hey, excited to have you here. So tell us a little bit about your background and who you are, why you're famous, and that kind of stuff.

 

Maybe someday I'll be famous.

 

Thank you.

 

Probably not. Yeah, so I've been writing code for over 10 years. Most of my career has been spent in pretty focused on backend development. I've done a little bit of DevOps, especially towards the end of my career as I was moving into more leadership roles. I don't know why that went hand in hand with managing infrastructure, but it did.

 

Thank you.

 

I went full-time on BootDev, so I've since quit my full-time job, and I'm now the founder of boot.dev, which is a online learning platform for learning back-end development, and a little bit of DevOps, because as I'm sure we'll get into in this show, I think that those two roles are maybe even more similar than the famous full-stack engineer. So...

 

interesting

 

Yeah, for sure. Like there's, I think you could have a pretty strong argument that those two roles overlap in a couple of areas.

 

Yeah, yeah, I'm excited to get into it, but,

 

The first three letters,

 

but,

 

for example,

 

but yeah.

 

right?

 

I see.

 

Ha ha ha! Yes.

 

Yeah, so that takes us into today's topic. Are you even a DevOps engineer if you aren't writing code? And I love that topic. So this is based off of a blog article that you wrote over on boot.dev, right?

 

Yeah, exactly. So, um, just to like lay some groundwork, are you guys are, are you both familiar with like the Phoenix project and the DevOps handbook?

 

Oh yeah.

 

Yeah.

 

Awesome. Awesome. So like, my perception of this whole thing, and like I have to couch all of this in the premise that I've never worked officially as just a DevOps engineer, I shouldn't say just as explicitly a DevOps engineer.

 

Just a menial

 

But,

 

grunt worker.

 

Yeah, but my perception

 

Thank you.

 

is that, like, you know, the DevOps movement was kind of born out of, like, a couple different things. And most of the people that I've worked in, or with, in a DevOps specific role have come from an ITOps background, right? So, you know, rewind

 

Thank you.

 

the clock 15 years, read the Phoenix project to, like, get what that means. But basically managing infrastructure, usually on-premise. and kind of manually installing things on boxes.

 

great.

 

And now we live in this different world in the cloud where  I would argue almost always you want to be managing your infrastructure with code. And maybe code isn't the right way to describe YAML files, but at least it lives in source control.

 

Don't burst my bubble.

 

Ha ha ha ha!

 

No, I agree with you 100%. Like I'm a huge advocate of at this point, our infrastructure should be defined as code. And one of my personal pet peeves is a lot of the, there's a lot of tooling out there that parades itself around as DevOps tooling, but it's just a point and click GUI for deploying infrastructure, which, you know, is fine. Like its place, but one of the areas where I think it falls short is you go into the point click GUI, you set something up, and then a month from now you or one of your co-workers goes in and changes something that alters the behavior of that. It's really, really hard in the tools that I've played with to find out who changed what and how that affected your configuration. I think that's where the, I think that's the strong selling point for infrastructure as code. that get history and a pull request and some accountability there.

 

Yeah, a lot of platforms have like audit logs built in, but the nice thing about Git is that it's this kind of standardized way of auditing things,

 

Yeah,

 

right?

 

for sure. You know exactly where to go to see where the change is and some of the other tools. Like they have the audit logs, but where is that? What menu option is that under? Or how many other logs am I going to have to scroll through to find the logs that are actually relevant?

 

Yeah. Yeah. So like, to me, the interesting question, like in this kind of discussion about like, how much code do you need to like, how comfortable should you be writing

 

Thank you.

 

code as a DevOps professional? Right. And like, do you just need to be good at YAML configs? Do you just need to be good at Terraform? Do you need to be really good with bash? Right. Do you need to learn Python so you can script some things? That to me is like a really interesting question. And I definitely have some opinions. I'm definitely not sure because the landscape is changing so quickly like this year I'm using netlify to deploy my front end like two years ago. I was deploying from an s3 bucket, which was you know much more Troublesome, I

 

Ha ha ha

 

guess

 

Ha ha ha. So I'd be interested in laying out some definitions for the rest of this conversation, which is kind of how you start your article. Although before we go there, I have to say I'm disappointed. The second sentence of your article really was a big letdown. When it says you're not the arbiter of truth, I was really hoping you could finally settle this debate. Ha ha ha ha.

 

Don't worry, I'll update the article after the podcast.

 

Okay. But you say, for example, the pioneers of the DevOps movement had a specific meaning in mind that's mostly misunderstood. What, how do you see, I think we all agree. I mean, we all agree on that. I'll bet that if we get 10 DevOps people in the room, we're all gonna disagree

 

Ha

 

on

 

ha

 

what DevOps

 

ha ha!

 

is, but we'll agree that it's misunderstood.

 

Yeah.

 

So just so we can all be on the same page for this conversation, How do you define or describe DevOps?

 

Yeah, great question. Let me scroll down so I make sure I don't like misquote myself as I pull up this article.

 

It was supposed

 

Okay.

 

to be a test, now it's not a valid

 

Bye.

 

test. Ha ha ha.

 

Yeah, unfortunately, I write a lot of articles. Not all of them are good. Cool, so what I pulled out was basically a snippet from the DevOps handbook. Farther down in the article, I say, the most important point made in the DevOps handbook is that IT operations become more like development, where the product is the platform that developers use to run their services. Right, so I was interviewing at a large company back that I ended up turning down because I wanted to work on boot.dev. But I was really fascinated internally. I won't say what company this is, but the way they were running their DevOps team, because it was like a breath of fresh air, at least to me. Their DevOps team were developers, software engineers who knew how to write code. And their whole job was just building tooling that the rest of the company would use to deploy and manage and install of thing, rather than the other kind of the reverse of that, which I've seen a lot, which is where kind of the DevOps engineers don't do any building of tooling, and instead they just use the tooling for the developers. And I think that's a huge disservice, because the tooling actually isn't that hard to learn how to use. And if you're the one writing the code, and you're the one using the tooling that deploys it and monitors it, I feel like you're just at an inherent advantage, because you're You know what it should do. You know the expected behaviors. The only alternative in my mind is like, you have to have constant meetings with your DevOps people to explain to them what the code should be doing and explain to them what the expected, you have this kind of communication overlap. So I'll just read that again so that we can like be clear on at least my

 

Good.

 

definition of DevOps and it's that IT operations become more like development where the product is the platform that developers use to run their services. Ha ha ha.

 

I guess we'll get in the show now, right?

 

Well, it really sucks if we all agree. That's no fun.

 

Thank

 

We need to find something to argue about.

 

you.

 

Yeah.

 

Ha ha ha 

 

I mean, I could I can argue with that. I mean, not not. I can argue with some subtleties in that. Um, just for the sake of argument, I normally wouldn't argue with a guest, but you asked for it. So

 

Yeah.

 

The gloves are off.

 

Ha ha ha!

 

here we go. Um, so I, I like, I like, and I'm not actually going to argue against that point specifically, but more of a meta point. Um, I like the question in your title. Are you a DevOps engineer? code because to me it poses two false premises and one is that a DevOps engineer is a thing.

 

ha ha ha

 

Hahaha! Fair enough.

 

And the other is that kind of the writing code is even like in the same universe as DevOps. I mean, I'll have to defend that statement here in a second, but first, I see DevOps as more of an alignment of priorities and of goals between DevOps it's the merging of DevOps. And it's really hard to do that in a role or on a team. You know, you... sort of the same idea that a DevOps team, if you have a DevOps team, you're probably not doing DevOps because you've put your DevOps in a silo. And the whole point of DevOps is to take DevOps out of us, is to get rid of the silos, we can dev it ops. And I know that not everybody who has a quote unquote DevOps team is doing that, but there's a strong, it's more of a team name smell than an actual problem, if you know what I mean, right?

 

Yeah.

 

So that's kind of what I'm getting at with the DevOps engineer is into thing. Yes, there are people who have that title and get paid to do something called DevOps engineer. Is it truly DevOps? Sometimes, definitely. More often than not, they changed an operations engineer or sysadman or something, changed a title, and they're still doing the same old not DevOps stuff with a new name. So that's really the complaint there. And then as far as the writing code, like... I think that a UX designer can be doing quote dev ops in the organizational cultural sense, you know, they're part of a company that does dev ops, whether they write code or do ops or not. So that those are the two false premises I'm pulling out there. I'm really not trying to argue with you. I'm just making. I'm jumping off of that that box you gave me to stand on about argument. So that that's really all that is.

 

I think it's so much better if you do argue with me though.

 

Okay.

 

Thank you.

 

It's so much more interesting.

 

Ha ha ha!

 

So, um... Now I'm going to cheat and say that I have two definitions.

 

Ho-ho!

 

There's like DevOps, the philosophy, and like the way we do things. And then I feel like we're kind of just stuck with the reality that there are going to be people called DevOps engineers for like a while. Maybe we'll get away from that, right? And like, for the point on philosophy, I just agree with you. Like DevOps is this thing, it's this way we do things, it's this methodology, right? You could say it's kind of like the same bucket of things as like agile development. It's like this type of

 

Definitely.

 

development.

 

Yeah. Yeah. It has

 

Maybe

 

all

 

it's

 

the same

 

a part

 

confusions

 

of it. Maybe

 

around

 

it's not.

 

it.

 

Yeah, yeah, exactly. Scrum sucks. Right. I don't know. Maybe there's like a subset of DevOps that we can find that that sucks. But the job title portion. My take is that if you're going to have the title DevOps engineer, Right, which already like right out of the gate. If you're a DevOps engineer and your organization is not doing the like philosophy of DevOps, then like it's already an oxymoron.

 

Mm-hmm

 

You just have a manager who like needs a pat on the back from his executive that they're doing the modern thing,

 

Right,

 

right? Which

 

right.

 

is to have DevOps engineers and not to have IT ops people.

 

Yeah.

 

But if you are going to have that team, and I think there are, there is a place for that team in large orgs. It like, to be honest, if you have less than like 50 engineers. and you have a DevOps team, you might be doing it wrong, in my opinion. You might just need to train up your people on how to like deploy their code. But I do think as you get larger, it can make sense to have teams that are dedicated to increasing the efficiency of the other teams, right? Building them, tooling, standardizing the deployment scripts, that

 

Agreed.

 

sort of thing.

 

I just wouldn't call it a DevOps team.

 

Fair enough, what would you call it?

 

platform team, operations team. I mean, so I mean, if you take, if you look at all the all the definition, all the job descriptions for DevOps engineer, and take off the title and look at those things, what would you call it? An operations engineer.

 

Yes.

 

So, you know, we've just re-labeled the operations team. Now, that's not to say that we haven't made good changes sometimes. You know, as you alluded to at the beginning, the sort of traditional operations wasn't making self-service services. They were sort of just running the tools for developers. And so that's wrong. Or I shouldn't say wrong like in the moral sense, but it's less effective.

 

unethical.

 

It

 

Thank

 

might

 

you.

 

be in some cases. Ha ha ha. So, you know, maybe these quote DevOps teams are building self-service tools, whatever. But I would call that a platform team. I mean, we have a perfectly good name for that. And we had a guest on a couple of weeks ago talked about that. So that's, you know, I don't want to spend too much time about what we call things. You know, arose by any other name is still arose, but, but

 

Yeah.

 

yeah.

 

No, I mean, I'm perfectly fine to just be like, yeah, that's fine. I don't have a hard stance about not calling it a DevOps team, but I'm also completely fine with Cloud Engineer platform team. Honestly, in my opinion, the more descriptive you can be, the better. One of my biggest

 

That's...

 

pet peeves working on back-end services is how, I don't know if you guys have almost certainly experienced this, everyone names their services like crazy bullshit names.

 

What?

 

Uh...

 

No.

 

Simpsons characters, Star Wars references. Is that what you're going for?

 

Yeah

 

Yeah.

 

Galaxor like just

 

Right?

 

wild and so when you onboard someone new like the first few months are just figuring out what all of these Random names mean that are totally Specific to this company. Um, I'm all about descriptive names.

 

Thank you.

 

I like services that are named after what they do

 

And

 

Absolutely.

 

I think that's the pragmatic problem with the word DevOps. It's not that it doesn't match some original philosophy handed down by the DevOps gods. It's that if I go into a meetup and somebody says, I'm a DevOps engineer, I have no idea what they do. I

 

Yeah.

 

don't know if they configure Jenkins all day or if they're actually writing code, maybe they're writing Kubernetes CRDs or maybe they're doing something really, really advanced or maybe they're just a Jenkins script kitty. So that's the real problem with the title.

 

Yeah, that, yeah, I couldn't agree more. I don't think worrying about definitions matters other than to avoid confusion.

 

Right.

 

Cool.

 

So now that we've settled that, we all agree 100% on what DevOps means.

 

Thank you.

 

Where does coding come into that picture and do you have to, should you be writing code if you're a DevOps engineer?

 

Yeah, so this is the big question. There's been obviously a ton in the news this year in terms of AI is coming for your job. And I think for a while, I think ops people have been experiencing this for a while, but not without AI, where it's like platforms are coming for your job, where now I click a button to deploy something instead of having to hand it off to an ops team. And so I'm actually super interested to hear your guys' take on where all of this is going. dumb takes like all we need are front-end engineers now right where we we take HTML CSS we hook it up to a back-end powered by GPT-4 and like we're off to the races um

 

There'll

 

I

 

just

 

think

 

be

 

there are

 

one

 

a couple

 

global master database and we just all have an API key to access it.

 

And it's on the blockchain.

 

Right?

 

Yeah, it has infinite scalable compute and we just have to pay open AI 20 bucks a month.

 

Yeah.

 

So yeah, like I don't know where this is going, but my gut tells me that like we keep moving in the direction of abstracting the hard parts, right? So like for example, this year I'm using, what's it called? Is it copilot? No, it's not copilot. GitHub thing. Crap. I'm using Kubernetes on Google Cloud Platform, and they have a one-click install button. I can't remember what it's called now, because I clicked the button once and forgot about it. Yeah,

 

I should have. Hahaha. hashtag DevOps.

 

exactly. But it's moving in this direction of abstraction. So Kubernetes is the ultimate abstraction machine, where we move all the hardware behind some interface. It's APIs all the way down. So in my mind, the only way to stay on top of your game as an ops or DevOps person is to keep on top of these tools, and most of them require that if you're doing a useful thing with them that you're configuring them through code some way.

 

Mm-hmm.

 

Because clicking the buttons is just getting too damn easy.

 

Okay, say that again, for an understanding of exactly. Clicking

 

Yeah,

 

the button's

 

so like,

 

just too easy.

 

yeah, like here's a trivial example that's been around for a while. Like setting up DNS. You don't need to really know anything anymore to set up DNS. Like you don't need to know what's going on behind the scenes. There's like a UI and let's just assume Netlify that gives you like three little instructions, go here, copy this, paste it here, put it there. Like now we're good to go. You don't really need the networking background for that portion of it. But you do need the networking background if you're doing like complex stuff within Kubernetes, although now you're probably using code to do it.

 

Okay. Yeah, I'm thinking back to when I used to run my own DNS servers. And I was worried about where am I going to run my redundant server in case the first one goes down. And these days I just use a web interface.

 

Yeah.

 

Yeah.

 

Like the question I get asked by students all the time, which is like a very fair question. And I think sometimes can be, can like feel annoying to those of us who've been in the industry for a while, but like it's a realistic question. It's like, what are the things that I need to be best at? Like I'm trying to get

 

Google

 

my first job. What are the most important skills?

 

needs to

 

Yeah.

 

know how to use Google or chat GPT these days.

 

as long as you can see through the hallucinations.

 

Right, exactly, exactly. So I think going back to sort of the broader question, how is AI going to affect our jobs? My stance on this is my entire job is to automate my job away. That's the only thing I ever do all day. And that's the only thing any self-respecting software developer or engineer is doing. So we should be glad when it's easy to do that. And when you consider how much crap code there is out there and how many security vulnerabilities there are written by unexperienced or uncaring even in some cases, engineers, we don't have an abundance of software engineering skills relative to the demand. And I'm not

 

Agreed.

 

talking about butts and seats. I'm not talking about the job market per se. I'm talking about the skills market. Right, you know,

 

Yep.

 

people cannot get the skills they need for the money they can afford right now. That's just not possible, except in rare cases. You know, some of the big companies might be able to. But in general, companies want more IT skills and programming skills than exist in the world. So if we can make these people more effective with AI or any other tool, I don't care what it is, why not? I'm not afraid of my job and I'm looking at the industry, I'm not afraid that even the unskilled engineers out there are gonna lose their jobs. more effective with less skills and that's great. At

 

There's,

 

least for a very long time.

 

yeah, so I completely agree. There's two things I wanna respond to there. And we'll see if by the time I get through the first one, I can remember the second one cause I have short-term memory loss on podcasts. But the first one is, so what you just described is like one of the primary reasons I ended up developing Boot.dev. I see two problems in the job market, especially on the developer side. We have way too many, like quote-unquote entry-level developers, but like people that have not yet found their first job, that have been sold like a bill of goods on like you can learn to code in three months and you're going to get your first job. So like very low skill cap.

 

Mm-hmm.

 

There's a huge supply of those people. And anytime someone opens up like a new entry-level JavaScript or Python or whatever job, it's flooded with

 

Thank

 

like

 

you.

 

a thousand remote candidates,

 

Mm-hmm.

 

right? And on the flip side, like you said, we have a market, but also I would argue that we have a shortage in the entry level market of people who are just simply prepared for an entry level job. So like my thing is it's not going to take three months, it's going to take longer and you need to go way deeper on this stuff than what you've been told by the latest, I don't know, marketing ad from some boot camp.

 

Right.

 

So that's like thing number one. And I did, I forgot thing number two.

 

Thank

 

So

 

you.

 

here we are.

 

Yeah!

 

Let me see if I can remember. Or maybe you can't remember.

 

Hmm.

 

What had you said right before I'd gone into my tirade about the job market?

 

said, my job is to automate my own job away.

 

That's the one.

 

Okay.

 

That's the one. OK, automating your job away. So this is super interesting to me, because generally speaking, especially in an ideal world, I completely agree. And I've always been lucky to consider myself in a position where I can automate my job away without worrying about my job. I feel like broadly speaking, there's like a couple different situations you can be in where this works. So if you're kind of in charge of your own team, lead or in a fairly senior position, I feel like you can probably automate your job away without many consequences. You probably will even get a pat on the back for it. Like if you have a manager who doesn't really know what you're doing all day anyways, like a non-technical manager, then again,

 

Thank you.

 

I think you can automate your responsibility's way and sit back and enjoy. But there's this other situation that I can imagine that I've never been see danger in it. So like if you automate your job away, where you take yourself from having to like manually do stuff, you know, 40 hours a week down to let's say four hours a week, and your manager knows it because they're technical, and they now see that you don't have anything to do,

 

Mm-hmm

 

I feel like that that could be a concern.

 

Definitely.

 

Have either of you experienced this?

 

Yes, very recently. And not per se about automation, but I was recently let go from a job. In part, I believe this wasn't actually stated to me, but I believe part of it was that I had taken a holiday. And during my absence, nothing burned down.

 

Yeah.

 

So it,

 

Yeah.

 

it felt like, why are we paying this guy if when he's gone, nobody misses him. So, you know, and, you know, I can understand the thought process, but it's, it's wrong for reasons

 

Short-sighted

 

that we can talk about.

 

for

 

It's

 

sure.

 

short-sighted. Yeah.

 

Yeah

 

Yeah. So yes, that will always happen. I mean, I don't think, short of literally educating every human being who's ever in a management position about, you know, long-term effects and so on. And even then, some are going to make the choice to go for the short-term financial gain over the long-term sustainability of the team or whatever. always gonna be an issue. You know, we have the same issue on Wall Street too, right? You know, corporates doing layoffs to help the bottom line in the short term, knowing full well that all the evidence says that it's gonna hurt the bottom line in the long run. You know, we'll worry about that when we get to it. You know, that sort of mentality. So you know, that happens all the time, it will always happen. So yeah, you know, in that sense, automating your own job away can be detrimental. And there are people who aren't willing to make that, you know, who want to work for those companies whatever reason, because it's comfortable or they like their colleagues or whatever. And so they're going to just, you know, not automate the jobs away.

 

It is a good gold star. And I would argue like you could play your cards right where like you automate the ops, the, let's just say like the deployment infrastructure, the telemetry, whatever, you automate all that stuff. And now you're feeling like you don't have a lot to do. If you feel that your job's in danger, I would argue the best thing to do is just to start job searching. And in every interview point out how efficient you made your last,

 

Right.

 

your last place of employment,

 

Right.

 

right?

 

For sure, that's one of the things I've always advocated, is like if you do work yourself out of a job, that's the most fantastic reference you can have when going to look for another job.

 

I've said the same to recruiters before, like, I see you only worked at these last, you know, three jobs a year or two years. What's up with that? Why don't you stay longer? I said, well, when I started a new job, my goal is to work myself out of a job. And that's usually how long it takes, a year to two years and I'm done. Ha ha ha.

 

Ha ha ha! It's like, so you know how like software is kind of a capital intensive market

 

Thank you.

 

in terms of like, it takes all of this upfront capital to develop a product, develop a software service. And then you kind of deploy it. And yeah, there's like ongoing maintenance and you like push features and stuff. But you kind of like start to reap the rewards of the fact that software doesn't have an ongoing cost of service, right? So you got this like upfront capital and then you reap the rewards. assumption, like if you ever talk to any like first time software founder They all have this assumption that like you build the product and then you launch it and then you just make money after that

 

Mm-hmm.

 

Right,

 

Thank you.

 

and I think that's kind of the the assumption about these capital-based markets But in reality, I think we all know like you launch the product and then there's like fires every day and product needs a new thing And so you actually keep growing the software team and there's more work overtime instead of less

 

Mm.

 

What's interesting to me like, is that the same thing that happens with IT ops? Or is it actually a different beast? It does, does the automation that we put in place as DevOps and ops engineers have more staying power than the features that are deployed by developers?

 

I think there's a couple things at play here. first, let's say you do exactly as you said, you build your software product and you launch and let's say you, you onboard 100,000 customers and then zero more, like you never nobody churns

 

Ha ha.

 

and you never add new customers, right? At that point, your additional ongoing effort to add features and do bug fixes becomes very minimal, you know, it's going to drop off very quickly. The reason

 

Mm-hmm.

 

that we have this ongoing maintenance is because we're onboarding new people, we're growing in short, hopefully, you know, I mean, sometimes it's If you're churning, your goal is to stop the churn first and then grow. So, you know, the

 

Yeah.

 

reason that these things are changing is because new people are using our product and they have new requirements or new assumptions or whatever, you know, we're explaining it to new market. I think with that in mind, in IT operations, we're going to have something similar. You know, if your customer base stays static, you're going to reach a plateau and you're going to be done, you know, and that's it. If... And it's a... It's at a different level of abstraction, so you might actually hit that sooner or later in operations versus software development, depending on what's going on. In other words, or to make that more concrete. If you're, let's say you're building a WordPress site, just to make something simple, right? And you're adding new features or changing features 20 times a week, but it's all WordPress. Your ITOps team is going to hit a plateau in a couple of weeks, and they're done. are automated 100%. We have no downtime upgrades, blah, blah, blah, whatever. Databases are backed up. We can fix the database at the push of a button. Because that IT landscape isn't changing, even if the customer base is changing all the time, the only thing that IT ops has to worry about then is maybe scaling. When they go from 100,000 to a million users, they need to add more nodes or whatever. But that's the only thing they have to change. If your customers are changing though, in the sense that, you know, we start with a started as B2C, now we're B2B, and we have a completely different type of customer concerns. We need new databases, we need event driven architecture, so that sort of stuff. That's when your IT operations is going to change too, because the requirements, the infrastructure requirements are changing along with the user requirements.

 

That makes a lot of sense to me. And I'm also imagining just this absolute minefield for middle management, like trying to explain that idea of like, we onboarded 10,000 people last week and we didn't need a single more ops person.

 

Yeah.

 

It's like, well, we didn't change the feature set and all the loads on the client, right?

 

Yeah.

 

It's so dependent, which like, another opinion I have, I'm very against, um, not saying non-technical managers, because I think it just solves a lot of these problems right out the gate.

 

Yeah. I've been

 

I

 

reading

 

think that's

 

a book.

 

a hole.

 

I've- Oh, go ahead, it will. You go first.

 

I was going to say that I think that that's a whole, a whole nother can of worms right there is the number of layers of management in the company because at some point, you know, you have, you have work that's being done for the sake of, of creating work.

 

If you- so I'm gonna do a plug early or a pick or whatever. Uh, if you haven't read the article, The Gervais Principle, named

 

So

 

after

 

it's

 

Ricky Gervais,

 

a, yeah.

 

go definitely read that.

 

I've

 

Thank you.

 

read

 

It's

 

it three

 

a-

 

or four times, yeah.

 

oh man, that's some good stuff.

 

That book changed my outlook in ways that nothing else ever has.

 

Ha ha ha ha ha ha!

 

I don't agree with everything in it, but it was very UI opening.

 

Yeah, yeah.

 

So

 

Or just go watch The Office, that's easier,

 

yeah,

 

whatever.

 

it doesn't really give you, you might just laugh through that and not get the subtle subtext that that article pulls out.

 

Yeah,

 

So

 

that's true.

 

I've been reading a book that I've mentioned on the show a couple times, at least, about wordly mapping. And for those who aren't familiar, I'll just try to paint a brief picture. It's a really long book, but I'll try to paint a picture in about 30 seconds. It's an XY, it's a graph with an XY and Y axis. you have a product's maturity, broadly speaking. So on the far left side, at zero, you have a product that's in its genesis or it's, you know, a concept. Quantum computing is probably in that area right now, right? You know, it's still very highly experimental. We don't know what it really can do. We have some ideas, but you know, it's very early stages. At the far right end of the spectrum, you have something that's utility. So like your electric meter, electricity, fuel for There's no competitive advantage from one supplier to another. You just pay the price, whatever

 

It's a commodity

 

happens to be.

 

pricing,

 

Yeah,

 

yeah.

 

exactly. And then there's a whole spectrum in the middle. And then from what I'm less interested in this for this particular point of making, but from top to bottom, the y-axis is as you go up the y-axis, you get closer to the user of your product. So, but I'm mostly interested in that x-axis right now, from experimental to commodity. And software development, by its very nature is always on the left side of that, near the experimental emerging sort of technology stuff. And that's for the very simple reason that if we already had software that did what we wanted, we wouldn't be writing software, we'd be typing the copy command. So every time we make software, the only exception really is if you're reverse engineering something because you lost the source code or because you're hacking a competitor's product or something like that. Those are the only times we're actually rewriting software that already exists, right? We are literally creating something new every single time. And this is why software prediction is so difficult, in why we have all these debates on social media about story points and velocity versus no estimates, all that nonsense. IT operations...

 

Even if the...

 

Go ahead.

 

No, go ahead, go ahead, go ahead.

 

Yeah. IT operations... doesn't have that same sort of certainty about it. The certainty that is uncertain. IT operations can happen anywhere from emerging to commodity.

 

Thank you.

 

If you're running AWS Lambda, you're far on the commodity side of things, right? Almost, it's not completely commoditized because you're still stuck to AWS. For it to become completely

 

Mm-hmm.

 

commoditized, it has to be possible for you to take your Lambda function and run on Google or Azure without changing your code. So we're not there yet, we may never be there. But we're closer to that end than we are to the emerging things, right? 15 years ago, before Kubernetes, if you wanted to autoscale, you were very much in that experimental emerging phase. Not anymore. So it depends on what you're doing with operations. You may be somewhere from that far left side of the spectrum, emerging technology, experimental stuff. We don't know if it's going to work, but we're going to try it, to at least a product. AWS Lambda is a product, for sure, which is the next stage before you get to commoditization. So if you choose to build your IT ops, on something that is more product or utility like, you can get to that point where you don't need as many ops people much more quickly. Whereas if you choose to build it yourself, if you say, I don't want Kubernetes, I'm gonna build my own auto scaler and my own load balancer and my own whatever, virtual networking stuff. If you wanna do it all yourself, you can, but you're gonna spend years on the left side of that graph building experimental stuff, trying to find things, learn new things. This is why if you do something out of the box Goku, which is just sort of super simple. As long as you follow their rules, it's easy. Then you can get out of that much faster.

 

So the interesting thing to me about this discussion is I feel like you can pretty easily picture how the most efficient thing for society, and the thing that you'd probably want society to encourage, is to get to the point where we can commoditize it. So it's super easy because then we don't have to worry about it anymore. It displaces jobs. We're

 

Yeah.

 

familiar with this whole thing with truck driving and whatever. It displaces jobs. But pretty objectively, it frees up human life. labor to do other things,

 

Yeah,

 

right?

 

who still wants to be there manually grinding ball bearings for their automobiles, right? We'd rather

 

Right.

 

a machine do that for us.

 

But one interesting thing that will, that like I would argue the only thing that could really thwart that from eventually happening where we do commoditize it, we do automate it all, is big players in the space intentionally thwarting the process for like in their own self-interest, right? So for example, you might as GCP want to keep your deployment process proprietary and specific to GCP so that people can't move. Right, if we do agree on a standard,

 

Thank you.

 

now I can very simply move to the cheapest provider, for example, and then when their costs go up, I move to the other provider, a nightmare for providers, right?

 

Right.

 

Which is like, I mean, you'd have to get into free market theory to really dig into this, but I don't know where we go, but I feel like that's the only thing that could really stop eventual commodification of like deployments and things like that.

 

Sure, and part of the larger point of the book about Worldly Baps is that exact point actually, that there are different forces at play in the market. And one of those is the desire to build a differentiator that is hard to replicate. You know, we talk about that in business and in other terms too, but you're absolutely right. But not everything ever makes it to the commodity stage, and maybe Lambda never will, who knows. Certainly Docker has made VMs reach that point or very near very nearly that point, you know, you can easily run your Docker image on AWS or on Google or Azure on your on your laptop or whatever. So you know, at least at that level, that commodity has essentially been been reached.

 

I guess a good example actually is this week I was buying paint to

 

Hmm.

 

touch up my cabinets. And all I had for my builder was the information that the paint that I had was called Magnetite. So I walked into the Sherwin-Williams around the corner and I said, I need Magnetite. And they said, what? I'm like, Magnetite, you know, the paint color. He's like, yeah, but is it Sherwin-Williams? Is it this other brand or this other brand or this other brand? I'm like, I don't know. They just told me Magnetite.

 

Hmm.

 

I tweeted about it because I was mad.

 

Thank you.

 

And

 

Yeah.

 

our own AJ O'Neill responded and said, it's a tag. by the brands, right? Like

 

Yeah.

 

they're able to lock you into their descriptions of paint colors. And now when you want to go buy a replacement paint, you can't get the color from somebody else. You have to buy from the same brand.

 

Yep. By the way, I'm pretty sure you can take a paint sample and those places will scan up the computer and tell you, you know, they'll get the exact

 

I had to

 

color

 

take my

 

you

 

cabinet

 

need.

 

off and take it in.

 

I don't

 

It

 

know

 

was

 

how

 

Yeah.

 

really

 

accurate

 

annoying.

 

that is, but I know they do that. Ha ha ha ha ha ha. Okay.

 

It worked well, but I did have to take a cabinet door off.

 

Yeah.

 

There's your next big entrepreneurship idea for anyone listening. It's like, let's get that image recognition

 

Paint

 

working

 

ups.

 

better. Yeah. I don't want to have to take a cabinet door off to get the information about

 

Yeah.

 

my paint

 

At least

 

to

 

it wasn't

 

my...

 

your front door.

 

Right, yeah.

 

That's true.

 

It was some

 

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

portable.

 

Ha ha ha.

 

out there peeling siding off of your house.

 

Just take

 

Yes.

 

a picture with your mobile phone. That's good enough, right?

 

Right? That's what

 

Yeah.

 

I asked him. He was like, no, it won't work. I was like, it has so many megapixels.

 

That's right, that's all that matters.

 

Yeah.

 

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

the guy at the iPhone store said.

 

Thank you.

 

So how much code do you need to learn to write as

 

Yeah,

 

a DevOps

 

we

 

professional?

 

still have to answer the question.

 

That's like the big question here. Should

 

So I'm

 

you

 

on edge.

 

be learning application side of the stack? Yeah,

 

Yeah,

 

go ahead.

 

actually, I want to talk about that part because that's one of the places where learning how to write code has actually helped me more, I think, in my career, is in working with software development teams because I always treat my job as like, the software development teams are my customers, and my job is to help my customers build their products as easy as possible. And so the ability to read and write code, I think, has been helpful from helping them architect applications, you know, because they're all doing logging, they're all doing monitoring, they're all connecting to databases, and being able to look at and contribute to their code has given me the ability to help them build better more resilient applications. You know, so whether it's implementing some middleware for logging so that all the applications are handling logging the same way, or a database connection, or one that comes up over and over again is the health check for your Docker container. No, it's not okay to just return HTTP 200 without actually checking to see if the container is healthy. And so that's

 

Hmm.

 

one of the places where knowing how to write code helps because you can look at that endpoint in their application and say, dudes, y'all are not checking anything. regardless of what's on fire around it. And so I think that's one of the subtle areas where as a DevOps engineer, writing code really helps you be better at your profession.

 

That's actually, I think the best way I've ever heard it put. I love that analogy. So I worked at a marketing analytics company and the product people, right? The people who are in charge of like what features were shipping had to be really good marketers. Like they had

 

Thank you.

 

to understand what these people are using our tool for. And so it makes sense that if you're kind of looking yourself as a DevOps person as like, how am I enabling these engineers to ship better code? I understand what code is and what it does and how it works.

 

Yeah, I think a similar

 

I-

 

analogy is, um, as, uh, building, building airplanes, like

 

Which we all do all the time.

 

Yeah, exactly. That's why I bring it up, because it's just a

 

We're

 

relevant

 

taking

 

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

it

 

analogy.

 

down a level to just building.

 

Right, so like if you're going to build an airplane, you kind of need to know a little bit about, about, you know, how airplanes work and what they do.

 

What do airplanes do?

 

Actually, they're really nothing. They actually just sit right where they are. And while you're inside, the CIA reframes the background. So when you walk off the plane, you think you're in a different location, but

 

I

 

that's

 

knew

 

a different

 

it.

 

podcast.

 

I

 

Ha ha

 

knew it.

 

ha

 

Yeah.

 

They

 

ha.

 

were actually a social experiment to see how slowly we could load 60 people into a fuselage.

 

I'm just kidding.

 

So I think I have the opposite way from Will. I started as developer and worked my way to the back end, even pass the back end to the servers and the installations and the server racks and so on and eventually virtualization Kubernetes. And so these days, I definitely have my feet in both camps, dev and ops, so to speak. And I definitely think that it helps a ton. It helps, my dev experience helps me with operations. My ops experience

 

Thank

 

helps

 

you.

 

me with dev. You know, I have a much better sense when I'm writing code to handle exceptions or to do logging or to do metrics or alerting, whatever. To, you know, even just handling a shutdown process. You know, I have my ops experience that it helps inform that. And I know, oh yeah, I need to consider, there might be two copies of this process running at the same time, never intend that because the one comes up before the other one comes down. And there could be race conditions if they're both talking to the database at the same time or whatever. These sorts of things that back in the old days, we never worried about because you stopped the process and started it again. And on the upside, okay, I need to consume these logs and produce something with them in such a way that a developer can meaningfully read them. Just having the logs on a disk isn't good enough. They need to be accessible and they need to be able to correlate them to something. So, you know. Both, it goes both directions. So I think I might be willing to say that if you want to be a good... Ops engineer, you should know Dev. And if you want to be a good Dev, you should know Ops. Not to say that everybody needs both, but it really helps a lot. Nobody's ever gonna wish they hadn't learned it if they do.

 

Yeah, and I think that's one of the most, like I always get frustrated when I talk to students or new learners or even people who are professionally employed say what do I need to know? Because to me that's like pretty good heuristic for someone who's not like going to be the most successful engineer

 

Right.

 

in my contact list, right? It's the people who want to know and aren't afraid to go figure it out that are gonna really succeed in this industry.

 

Yeah, I agree.

 

Yeah, you have to be comfortable with being in unknown territory.

 

I had somebody ask me once, they said, hey, Jonathan, I'm studying to learn send mail for certification. I know you know Linux really well and admin stuff. What advice can you give me to learn send mail? My advice was don't learn send mail. Install PostFix, it's so much easier to learn.

 

Ha

 

And they

 

ha

 

literally,

 

ha!

 

like their face dropped, they were dejected and they walked away because I gave them bad advice. Because they were going for particular certification, they weren't in it for the knowledge or for the ability to manage a mail server. ability to get a certification that was specifically ready to send mail. And I, sorry, I can't help you with that.

 

As someone who professionally now sells certifications, I think certifications are bullshit.

 

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

Thank you.

 

And that you don't... It's the least interesting part of any... Like knowledge you can gain.

 

Yeah.

 

Ha ha.

 

Yeah. So why do you sell certifications in? I think I can guess the answer, but let's hear it.

 

Yeah, so there are certifications. Technically, you can go find them and download them. But it's just because people ask,

 

Yeah.

 

like, oh, I need a certificate at the end of this learning platform. Like, all right.

 

to get reimbursed or whatever from their employer, probably. Or, because they

 

Sometimes

 

want to.

 

I'm sure other people because they want to but then I go through this rigmarole like during the courses It's a very long. I take the approach of like It's eventually I want to have like the equivalent of a full CS degree of material that you could take

 

Mm-hmm.

 

online and You know in there. I'm talking about the fact that like these certificates like don't matter You know like less than half the developers I've worked with have had degrees

 

Thank you.

 

It's about gaining these skills. It's about building the projects putting them to practice improving that you have the skills. So even though at the end you do get a certificate, I don't think most people actually end up caring by the end. They just care at the beginning when they signed up.

 

Thank you.

 

Yeah, so the certificate is like the lure in, but then the ultimate goal is learning the skills.

 

Well, the interesting thing about marketing, I'm not a marketer, but I've been forced to sort of figure it out, is that it's really hard to change people's perceptions about something when they are on your landing page.

 

Thank you.

 

So if I tried to give them the pitch of, this certificate doesn't matter and change their mind right then, their chance of trying the courses and checking it out goes down. Whereas

 

Mm-hmm.

 

if I just go, yep, check mark, you get the certificate. If that's what you were worried about, it's here. even less about allure and it's more just like, I'm gonna check this box that some subset of my customers feel they have, even though I believe it shouldn't be a checkbox.

 

Mm-hmm.

 

Yeah, that makes sense. There's a website where you can get degrees from Harvard and Yale and Brown University. You just enter in your name and click, and it generates

 

PDF.

 

the diploma. Yeah, for you.

 

That's awesome.

 

If you

 

Nice.

 

want to see an example, go to my LinkedIn profile. Ha ha ha.

 

Yeah. Ha ha ha.

 

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha Thank you.

 

nice.

 

Well, cool. Is there anything left to discuss on this topic?

 

I think we hit the awesome stuff that I was at least most interested in talking about.

 

Yeah.

 

You guys have been delightful.

 

Cool, well then since it's starting to wind down, let's wrap this up before we get to the awkward boring phases which our editor so gracefully cuts out to make us

 

Yeah.

 

sound like we're just on top of things all the time. So thank you again for doing that.

 

Oh good, we have an editor, I wasn't even sure.

 

Yeah.

 

Oh yeah, yeah, yeah, I should have pointed that out ahead of time. We do have an editor, so if there was anything that you want to cut out, we can do that. And then like the awkward pauses and silences, they'll cut those out too.

 

Cool.

 

But meanwhile, let's move on to picks. Jonathan, pick it on you first. Do you have a pick for us?

 

I do. So my wife and I just finished watching a series that I've watched a few times. And since we mentioned the Javais principle, I'm gonna pick one of his. We just finished rewatching Extras, which is one of my favorite series by him. If you haven't seen it, you definitely should watch it. If you like the office, if you like the American office, you might try the British office. It's a little more crass, a little harder to watch for certain people. more like that.

 

right

 

The

 

on.

 

premise is that he and the main character Maggie, the two of them, they're just their friends and they're movie extras, but they're trying to break in. He in particular is trying to break into the acting scene. In every episode has a different real-life celebrity playing themselves, but a parody version of themselves. So you have an episode with Kate Winslet playing, you know, giving telephone sex advice to the extras, There's an episode with Ben Stiller directing a war movie and being a complete dick to everybody.

 

Thank you.

 

And my favorite episode is one of Patrick Stewart, where he, I mean, because I'm a Trekkie, but Patrick Stewart's on there and he is trying to pitch his movie where he plays the protagonist, who's a James Bond style character who has the power of, where he can control things with his mind. And he's just constantly, every turn, making women's clothes fall off. Ha ha ha ha

 

Yeah.

 

ha ha.

 

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

So that's my pick for the week. It's short, it's two seasons of six episodes each, so they're like a half hour. So you can actually watch it in an afternoon, you can watch the whole thing if you really wanted to, or over the course of a couple of weeks. X-Rus with Ricky Gervais, that's my pick.

 

Yeah, it sounds like the rest of my day has just been scheduled.

 

Ha ha ha ha!

 

I was gonna be so productive today,

 

Right?

 

no longer.

 

Thank you.

 

Just move that to-do list onto tomorrow.

 

Thank you.

 

All right, Lane, what about you? Have you got a pick for us?

 

Yes, so a guy I interact with on Twitter,

 

Thank

 

I

 

you.

 

probably am not privileged enough to call him a friend, but he's a YouTuber and he just published the most hilarious tech YouTube video I think I've ever seen. It's called Exposing Astro Between Two Nerds and it's a play on between two ferns, if you're ever familiar

 

Yeah.

 

with

 

Oh

 

that

 

wow.

 

little, what is it, Zagalphanakis?

 

Mm-hmm.

 

short, but definitely go check out his YouTube video, exposing Astro between two nerds, really good. It's

 

right on.

 

like five minutes long, yeah.

 

Alright, cool. So my pick is just really, really out there. It's a book that I'm currently reading on the halfway through it. It's called The Immortality Key, The Secret History of the Religion with No Name. The author is Brian Mirrorescu. Not sure how that should pronounce his name, but The Immortality Key. So this book is just talking about the origins and history of religion and tying it all the way back to the fact that They believe the Greeks, who are kind of like the founding fathers of Western civilization, that their religious practices was primarily based on hallucinogens. So like their whole spiritual belief came from doing magic mushrooms or LSD or whatever version of that they had. And then they're doing different archaeological studies in this book and talking about those about how that served as the seeds for Christianity and these other religions. So the whole premise of the book is that they're saying the foundation of religions as we know them comes from an LSD trip, which has just been pretty cool because of the actual evidence that they have tying this stuff together. So it's a really cool read.

 

interesting.

 

If you're into that kind of stuff, I'm a huge fan of ancient

 

You're a

 

history

 

huge fan of LSD.

 

and Well, not that we'll admit to you on the podcast, but I am a huge

 

Okay.

 

fan of ancient history and ancient religions and like the correlations between all of those different things and the areas where they overlap. And the fact that they tied all of this together has been pretty fascinating read.

 

Well.

 

That sounds awesome. Have you seen the YouTube channel, Religion for Breakfast?

 

No.

 

It's a religious history YouTube channel. You might wanna check it out, really, really good stuff.

 

Right

 

Not,

 

on.

 

like, the important distinction is it's not theology for breakfast, right?

 

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

It's religion for breakfast. It's the academic study of religion. Ha ha ha. It's the academic study of religion.

 

I'll definitely check that out.

 

I recently read, I think I picked this actually a few months ago, but since we're on the topic, I'll add another pick. Michael Pollan's book, actually there's two of them on a similar topic. This is your mind on plants and how to change your mind are about the sort of the history of certain psychedelics and other chemicals that are at least

 

වවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවවව

 

in the United States illegal at the moment. So although they do talk about cat, he talks about caffeine as well, which is not illegal, but has some interesting side effects. or effects on your physiology. So that's a, if you're interested, if you're a big fan of things like religion or LSD, you should also check out those books. Ha ha.

 

And hopefully you're listening to the podcast through a tour network or something that's not tracking us back to your

 

Thank you.

 

IP addresses. You're typing all this stuff into Google. Ha ha ha.

 

No, because it's a logical or. You can say, I am a fan of religion or LSD, and there's

 

Yeah,

 

no

 

Yeah.

 

way to prove that

 

right.

 

you did the illegal one.

 

Exactly.

 

And you've got a career in politics, like your ability

 

Ha ha ha!

 

to just like to just you've done it this whole episode where you've said stuff and then you've you've backed it up and then you've adequately distant yourself from anything that could be pinpointed to you. I've just been in awe of this whole podcast. I'm like, this guy's going to be our next president.

 

Lord help us.

 

Ha ha ha!

 

Ha ha ha ha!

 

We'll automate that job away

 

Could

 

too.

 

be worse.

 

Right.

 

It has been worse. I won't say when was worse, but it has been worse.

 

Ha

 

Right.

 

ha ha ha.

 

Don't want to alienate any of our listeners.

 

That's a great thing is you can say that and everyone instantly like, yeah,

 

Everyone

 

he's

 

agrees,

 

right

 

yeah.

 

without saying

 

Nobody can

 

anything.

 

disagree with that. That's

 

Cool,

 

the logical

 

well that seems

 

order

 

like

 

there

 

a

 

again.

 

good part. That seems like a good point to end our podcast. So thank you everyone for listening. Lane, thanks for joining us. It's been a pleasure having you on and hope to see y'all again.

 

Thank you. Yeah, that was great.