Programming Throwdown - 140: Developer Burnout and Infrastructure as Code with Ronak Rahman

Episode Date: August 9, 2022

00:00:57 Introductions00:01:51 How Ronak got started in programming00:06:03 The first encounter with burnout00:11:49 Double-edged benefits00:17:23 Spoon theory00:19:07 Why relationship clarity matters00:25:11 A cold room story00:30:59 Context switching’s relevance00:35:45 QTorque’s solution to monitor cloud automation costs00:39:19 Setting up lifetimes00:42:17 Bom lists00:49:19 How Quali helps with the challenges00:54:40 What to do to actualize your true self00:58:00 FarewellsResources mentioned in this episode: Ronak Rahman:    Twitter: https://twitter.com/ofronak Quali:          Website: https://www.quali.com/          Linkedin: https://www.linkedin.com/company/qualisystems/          QTorque Free Tier: https://www.qtorque.io/pricing/          Join QTorque: https://portal.qtorque.io/joinIf you’ve enjoyed this episode, you can listen to more on Programming Throwdown’s website: https://www.programmingthrowdown.com/ Reach out to us via email: [e-mail] You can also follow Programming Throwdown on Facebook | Apple Podcasts | Spotify | Player.FM  Join the discussion on our DiscordHelp support Programming Throwdown through our Patreon ★ Support this podcast on Patreon ★

Welcome everybody. Another exciting episode today. We're very excited with our guest here, Ronak, talking about two topics. Now, I watch some reality TV. I know I'm shameful. I'm not supposed to say that. And I watch that Top Chef and they always fuss, don't try to do two dishes because you're going to screw one of them up. Hopefully, that won't be us today. We're going to do two topics that are going to be pretty interesting and exciting. The first one, super, super relevant to everyone, developer burnout, but then also infrastructure as code, how they relate, what it is. I think this is going to be a pretty awesome jam-packed episode.

Welcome to the show, Ronak. Hey, guys. Thank you for having me. I'm excited to be here talking about topics that are interesting to me. And also, thank you, Patrick, for the cooking reference. I love cooking shows. Okay, well, okay, we can get sidetracked there. The forming chocolate sculptures one. I forgot what it was called, but that was my favorite.

The like French, okay. Yes, yes, it was the French and the amazing things they can do with the chocolate. Absolutely amazing. Oh, dear. Okay, yeah, we're definitely going to get sidetracked. And I'm going to be hungry. It's almost lunchtime here. The French and the amazing things they can do with the chocolate. Absolutely amazing. Oh, dear. Okay, we're definitely going to get sidetracked. And I'm going to be hungry. It's almost lunchtime here.

So, I'm distracted now. Ronak is Developer Relations Manager at Quali. And we traditionally start out the show, Ronak, by just sort of talking about how people got into tech and their kind of story, how they ended up where they are. So, why don't you talk maybe, like, do you remember what your first computer was or your first experience? Where did you build that passion? First of all, I want to say again, thank you for having me. I mean, think about the extreme privilege that I'm enjoying. I'm talking about something I care about. And you guys are asking me these questions. And you want to listen. I think this is all the human experience is about like wanting to be heard and listen. Yeah, I totally remember what got me

into technology. And I'm hoping somebody on listening to this podcast will remember it. But my old man was a an engineer. And they were learning this cool thing called Fortran back in his days in the 70s and I mean it was like it was cutting edge right and to train the engineers they had them and I think I found this on eBay still they're like green and white manuals it's like a really skinny you know flexible manual and it's striped green and white in the front. And it's learning Fortran. And it basically looked like a math book on the inside. And I was seven years old where I pulled these down off the, I'm not kidding.

I pulled them off the, because I was so bored. I was like looking for more to read. And I read it and it looked just like math problems. So I started doing it and started writing out the exercises and whatever and my dad came home from from work and he was like what who wrote in my manuals and by the way this is right how did you do this yeah you know he didn't at first and do this and uh and and him being and so him being an ind dad, not very impressed easily. You know, the typical joke there is they give 99.9% approval.

So you're always chasing that 0.1%. But he gave full approval then. And that sparked it. I was done. I was like, oh, I'm going to do this. I'm going to program. I'm going to create the next awesome. Yeah. So that's how I got started. That's a great story. Wow. I mean, I think there's a story there about

parenting and about like the balance between letting, giving approval, but also, also sometimes like asking more of your kids and like trying to make sure that they know that they got to push themselves. I, that's something I, as being a parent, I won't get on that outside topic either. But I mean, that's a that's a struggle. So I mean, that's awesome that it worked out that time. That's really cool. Yeah, that and also, I guess, I, you know, since you brought up parenting and whatnot, I should put a plug in for, you know, sometimes things work, you know, like with parenting, and apparently it worked out in this case, but also don't be afraid to seek the mental help, help that you may or may not need due to the parenting style. So you know, work on yourself. And that's great, because like, we're talking about developer burnout, another

stress related issue. So I think that'll tie really nicely in with what we're talking about and solving those, those potentially deep wounds from our so okay all right i mean wanting to talk about developer burn i mean everyone has that i mean this is something you know we were talking a little bit before the show i just very you're very passionate about you think a lot about i think that's awesome important to talk about maybe how you kind of that first experience you know obviously growing up kind of where did you get what was your kind of programming journey your tech journey however that kind of that first experience, you know, obviously growing up, kind of where did you get? What was your kind of programming journey, your tech journey, however that kind of went from there?

And then, you know, kind of first starting to encounter this dreaded burnout. I love it. And I have a really good story on how that started. And I have to be careful not to mention any business names. Okay, so yeah yeah here we go all right uh so let's see if if our listeners can decode what i'm saying uh my first is not blueberry it started at blueberry it's um there is a uh a big software creator in the pac Northwest. And I was a young developer working there. And the rumor has it that burnout is a model built in to that corporate culture. But I was young and hungry. And I thought this was the best thing that ever happened to me job wise. And I was eager to do it. So I had no problem pulling in the the 12-hour work

days and um and it was amazing right first time uh you know out of college and these these big buildings working on problems that were uh important anyways uh I was leaving uh one night after you know just two months of doing this and I made friends with the security guard who actually decided to chew the fat with me and walk to the parking lot with me, the parking structure. And I asked the security guard, hey, what's up with that Prius in the corner? And I think anybody from this time period will know this story. And there was just this Prius gathering dust, had all flat tires, totally covered in dust. And the security guard told me, well, that's actually a person who's been working here for a year now, hasn't left.

And he got a call from his now ex-girlfriend saying to come and pick his stuff up because he no longer lives there. And his stuff in the Pacific Northwest was just sitting outside soaking in the rain. And he discovered that he no longer has a life there. And he just brought his car back and parked it there and just stayed working. Wait, we got to double click on this. So where does this person sleep? I mean, how does this work functionally?

Okay, let me tell you, all the things that end up contributing to developer burnout actually seem really cool at the beginning. And I'll give an example. My kid, my 14-year-old loves his smartphone. We just gave it to him. But all of us adults know that smartphone is like the work of the devil, right? And you try to hide it away from you as much as possible. So I thought it was cool as a young software developer that there is kitchens filled with large industrial refrigerators full of all the food you can want. You know, I just opened my backpack and just put them all in because super poor. And they had massage chairs and quiet rooms. And we all did have our important office.

I think you're getting, Jason, the answer to this question is that developer slept in his office. And by the way, that was totally okay. Yeah. Wow, that is wild. Yeah, I feel it's worth giving some context there that I mean, people have heard the stories about other companies. And yeah, you like you mentioned,

free food, free meals. They're also often I mean, maybe you don't know this. I was explaining to someone in my family, this is a thing that I made a joke about staying in the office. I didn't, but I made a joke, I could just live there. And they're like, what? And I'm like, yeah, there are showers, because people bike in. And so there are showers. You could shower. You could have stuff. You have an office or a quiet room where you could easily nap at night when no one's there. And there are stories, both probably real and not so real, of people just living in the office and it not being the worst thing. Like people kind of go, Oh yeah, I could see doing that. It makes a sense. And especially when you couple it with how expensive it is in a lot of these places to live. Now you say you can actually justify it, right?

It's not that the person is broken. It's that they're smart and they're smart because they've, they've killed their commute. They don't have to do it anymore. They don't have to pay for a home. And you can actually begin to put this person on a pedestal. And the same happens with now the thing is people getting those big vans, the conversion vans, and parking them in the parking lot. Oh, I don't live in the office. I travel around in my van. But it's there when you leave, and it's there when you get back. I want to just kind of key in on, you know, what,

what Patrick was saying, though, that shook me, you know, the actual, it was a rumor seeing that car and people, but the actual, you know, parking lot, the security guard, the attendant telling me that story and confirming it. And, you know, I don't know if it's true, because I never met the gentleman, but it was a compelling enough, it was real enough, I could see the burnout in my group. And it actually scared me. And that was, you know, about 20 years ago, and I sort of took it as a cautionary, like a scared straight type of tale. I was, I did not want to be like that. I didn't want to work so hard on something that, you know, I didn't care whether all my stuff was sitting outside, getting right. I mean, it, I didn't want to be

like that. And that's what started me on this path thinking, you know, I, in fact, I was lucky, I had an experience early on in my career, instead of, you know, like the lobster slowly boiling in the water and not realizing that they're in harm, I had a quick shock. And I started looking for signs of this. And you can see it in the interview, when the interview, if they ever call their team a family, I think, come on, us being in IT, we know what family means. We're going to get a call for every computer problem that the family has. Yeah. So I kind of look out for those keywords and I've been trying to avoid it. So first step in the Maslow's hierarchy is survival. But next I'm, I'm privileged enough and I work for people good enough. How do I help others? Yeah. I mean, I think there's some, I mean, we could kind of take it

from both sides. I think you're already mentioning sort of recognizing the signs. And I actually really liked that you, in some ways, made it an analogy to a cell phone, where I think the belief that it's a strictly positive or negative thing, I don't want to say it's a naive belief, but the black and white part of it is not, I know where you were going. But I mean, I think this, the companies, I don't know that they intend to make it a trap, but they don't not intend to do it either. Oh, see, there we got the double negative going. No, you're awesome. I love that, actually. Yeah. And so I think like, you know, there's a story about you know video game developers and they're they're working hard to push out you know before the deadline and there's there's you know people

install bunk beds because you know hey we're just going to crash here at least we have a place to sleep management realizes the problem what's the solution the solution is take away the bunk beds and it's like wait a minute right and so i, I don't want to demonize the companies completely yet. Well, and that's not productive, too. We are, I'm not here to, like, deep dive into or create like a, you know, a sort of political social justice moment here, but there's things that we can do, like, you know, understanding both ends of the equation. And let's try to understand that corporate position. All right. We're, we are here to make money. And in the, you know, our salary isn't a, isn't a charity, you know, type of thing. It's, it's a trade off our time for them to get a product. Now, I think both sides have a room to understand the other, sometimes in blindly chasing

profits and features. And, you know, the next thing, we sometimes don't know about, like the long term costs. And I'm here to talk about, and we're going to get into IAC here in a sec. I'm here to talk about how it is in corporations' interest to sort of, I want to say nip this in the bud, but to address developer burnout. Because at the end of the day, and I want to speak the language to our corporate system, is that we need to address this so that we can be more profitable and that we have a better long-term outlook. Turning over one skilled employee, forget about the morale. It just doesn't make business sense.

It costs so much to onboard and make it. You know, in my field, a lot of times, especially like, say, things like consultant or implementation engineer or public facing technologists, it can take up to a year to make them productive. You know, that's very expensive. I can, we can do things to address developer burnout. And I kind of wanted to talk about some of that. I don't want to veer too far. But I have hope that we can use technology to fulfill some of that. I don't want to veer too far, but I have hope that we can use technology to fulfill some of that promise on both sides. Yeah, that's a good call out. I think one of the things related to burnout that shocked me was how

different disciplines have different ways that they get burned out. So for example, if you're in sales, you're on the phone a lot. And so if your manager calls you to give you some immediate feedback, that's actually a great thing. I mean, most people love to get feedback. They don't get enough of it. And when they get a call from their manager just impromptu, hey, you know, I was in that call with you five minutes ago, and I think you did a great job. That is just net positive, right? But engineers really value their sort of flow time, their sort of individual kind of focus time. And so that's an example where, you know, a manager who isn't in tune with developers, you know, might just randomly pick up the phone and call a developer and say, hey, you did a great job. And they don't realize that now it's going to take 30 minutes to get back that context to get back into that code. And so there's a lot of pitfalls like that

when you're managing developers that people aren't aware of. I love that, actually. I love what Jason just said, because, well, and let's talk about even lots of people like being managed differently, you know, sales versus development, and even how we get feedback. You know, yes, I'm more, as you guys can probably tell, I'm more of a people person, you know, but not a lot of my colleagues are. And picking up that phone call from manager might be, in addition to, as mentioned, the contact switching, which is, by the way, just incredibly annoying to contact switch. But it might also increase my social anxiety. I don't want to have this conversation with. But that's not to say developers don't like feedback. And so we have

in development, most software gets created through what's known as a CICD pipeline, continuous integration, continuous deployment, or as I like to call it, everything. The idea is software should be built like five minutes ago. They just want you to think it, have it coded, and then appear out in the world as continuous deployment. That's where we're getting to. And to do that, a developer needs feedback, constant feedback, but they want it in channels they can subscribe to. Maybe I have a Slack integration, or I have an email that the build delivers, and I get that feedback. I can choose when to get that feedback, you know, and it's not human, so it's predictable.

You know, it's a predictable piece of feedback versus a lot of times I may be a more introverted person and that social interaction through a phone call, that saps me out. There's something called spoon theory too and some people only have a certain amount of spoons they can give to social interaction and we should be mindful of that too especially in the developer community folks are going into this not because they want to you know be people facing a lot of times you know know? Yeah, I think recognizing and various companies try to give

various trainings on like, recognizing that there are different different folks. But in practice, it's something that I think you just always have to work at that empathy, putting yourself in other people's shoes and realizing the way you view the world isn't necessarily universally subscribed to. And I mean, even today, you know, I don't want to get into the like politics in the workplace. And we've seen a lot of people pushing for either more or less. And I mean, I think there's a lot of stuff that happens at work. And add that to your personal life, like we saw during COVID, where now like, not only is there people being worried, people are being different kinds of worried, people are having different ways they want to talk about how they want to deal with being

worried and about the problem, right? And it's just all this stuff swirls and you end up with this, you know, hey, I have someone on video in my house and my house used to be the place where it wasn't work, right? And some people have this work is work and, you know, not work is not work. Other people have a more blurry line. And I think that, you know, sometimes through, you know, intentional or unintentional processes, those lines blur. And you were kind of mentioning, you know, some things to deal with it. But for me, what I'll say is, I think,

having in your mind, like, what is work and what is work to you, and having it be defined is one of those critical things where it's okay, if you want to work at some place, because you believe it's changing the world. And it's the only thing that matters. But be very clear to yourself that that's your relationship. If it's just a paycheck, be clear to yourself that it's just a paycheck, right? Like in your own mind, at least, be clear your relationship to this job. Because if you don't, you end up with this murky, like, what is the right thing to tell your boss when they call you on the weekend? Or if you know, you get a text message at 3am and get fussed at, you didn't respond to it. And so, you know, you got to have talking about being clear on that i mean basically we're talking about uh boundary setting and and and there's two parts like we we started this um

podcast out on not villainizing any one group i mean i think um i think at the end of the day you're going to realize it's like i mean we're not so far apart the developers and the management we're not far but we actually have the same goal. Believe it or not, developers, they absolutely, 100%, they're going into the work and they want, no developer says like, oh, I want to accomplish less today. No, it's very important that they accomplish the thing that they accomplish. And it's just that it becomes, so developer burnout, I feel is a just a fancy term for any type of burnout. And that burnout is you have burnout when you're in a situation and you're unable to manage the stress in that situation. And then that accumulates over time, and then you have something burnout. Sorry, if I'm explaining this to and everybody has the same idea but i just want to start off as that baseline and i wanted to talk about something i'm hopeful about so so far we've been talking about bad and and whatnot but we have

things have improved right i mean um you know the uh the pandemic has been terrible, but it has given us opportunities, you know, for instance, to increase our remote productivity, right? Zoom and all the connectivity there. And I wanted to talk about, if it's okay, something that's helpful that I see as for the first time, you know, we're now at the place in our CICD pipeline is the pipeline that software gets built in. And, you know, I've been at a couple of DevOps conferences where, you know, some folks say the CICD pipeline is the meeting place for all interested to get, it's like the meeting place where we have to communicate with each other. Developers are now forced. It's like where the rubber meets the road where I finished a feature, management says, okay, where's that feature? It's going to happen through that CI CD pipeline. That's where we're

sort of saying it's okay to communicate versus picking up the phone. And within that pipeline, an activity that happens is when you develop software, it has to be deployed somewhere. And that deployment place is called, it's infrastructure. And in more general, it's called an environment. That is like, I think the, you know, Star Trek, the final frontier of automation or not final, but it's the next frontier of automation within that pipeline. And why do we care about that automation?

It's because it's less tedious crap that I have to do. And leading the way for the first time, we have the popularization, and we couldn't do this before, but we have something called infrastructure as code. People like Terraform, folks like the Helm chart, for instance, we're taking the tedium of standing up a server. And you can see where this trend has gone. At first, I remember when I was a young IT engineer that we would rack and stack servers and we would have a cold room with raised floors, right? I was

working at a large gas firm at a large oil company in Houston, Texas, not hard to imagine. And we had cold rooms on every floor, you know, of the building. And I walked into a cold room with a team, we're supposed to do some wiring and rack up a new test environment. This is how hard it was. It would take weeks to get an environment, which is just a group of servers in together and wired and put in the right subnet and whatever. All of that was manual.

And we go to, you know how you lift the raised floor tiles under it. It's with suction cups, right? Have you seen those suction cups? Well, you gotta probably explain to people what cold rooms are. Like, I mean, I know what it is. I've been in them, but there are probably so many people out here

like, what are you talking about? Refrigerator? You're so right. So a cold room is before you had your cloud and your Amazon, everybody would have, I feel like a grandfather explaining this to like back in my days. I totally am. Back in the old days, what you do is instead of cloud, you would have a

server room, which is all the cloud is, right? It's like a giant server room and people are taking bits of those technology. But back in the day, everybody had their own lab room where all of these servers were being underutilized and set up into environments that you could connect to before somebody had the good idea of, oh, let's put these in a common location and serve them out as a cloud. So you'd have your own personal cold room, which is just servers and racking and cooling all in one place for you to access compute power we didn't call it then we said hey we need a server in in the lab uh so you in and you raise the floor because a lot of times you put these in old buildings and uh it's to allow

cooling and all the wiring to go under and it literally is cold they blow like extra air conditioning in it because the servers get hot and they don't want them to overheat yeah yeah go in with a jacket type of thing right and i uh took suction cups and i attempted to or i did lift the the panel on the floor that we were going through and we found curled up a contractor asleep. We found a contractor. I'm not a narc, but this is a definite situation that's not tenable or safe.

This was reported and we never saw that contractor again, but some people address developer burnout in different ways, I guess. You never saw him again, but you always felt like he was there just underfoot i it was a creepy i'm so glad i've looked all the tiles now whenever you go in you gotta put like clear ones in i try to never be in a cold room anymore it's kind of like one of those things like from your early on in your career, it's like,

oh, yeah, I'm never doing that again. But yes, now I'm always afraid. Okay, so sorry, gentlemen, I got off track. Thank you. So we have now something. So I was describing the dinosaur days, right? What I want to describe now is we've come to where nobody has a cold room in their office. They use Amazon or Azure or whatever.

They're a cloud service, right? And it used to be you can create these infrastructure components through the GUI, but nobody does that anymore either. They provision out systems through code. And a lot of these cloud providers have their own language. But what's cool about something like Terraform is they're cloud agnostic. Meaning I can code up, I can say, stand up a Tomcat server, stand up a load balancer, stand up a database in this one script, and I can point it to AWS or Azure or whatever, and my assets will appear after I run this script, right? Doesn't that sound like a miracle?

You know, yeah, it sounds like now I don't have to do anything to get this, you know, server. I don't have to rack it. I don't have to provision it. I don't have to go to a GUI to do it. And it's all within command line tools. And I'm arguing that things like that can remove, probably folks that are listening right now have had trouble with an environment. They need an environment to deploy their software. They're ready to go. The corporate managers and leadership are saying, this is great.

And we're realizing right now that the bottleneck is somewhere to install that software. So infrastructure as code gets us one step closer to the promised land where I don't have to worry about that. Immediately after building my code, so the current process is check out code from like a source control, right? Onto your build server. That's a well-understood pattern. You build the code into bits that you can deploy.

Also well-understood, very well mature. You save the bits onto an artifact repository, which is a binary repository, similar to source control, but stores a version of your software. That's well-understood. And automation deployment is also well understood. We get it from that commonplace, the artifact repository and install

our systems. What we're still in the baby nation phase of is having that environment codified to be consistent and to be on demand and ready. And infrastructure as code is that next thing I'm super excited about that really is going to help developers not sit around and wait ever for that. We can find the next bottleneck. So yeah, we can go as deep as you want there. So let's talk. Today's sponsor is Mergify.

Mergify is a tool for GitHub that prioritizes, tunes, automatically merges, comments, rebases, updates, labels, backports, closes, and assigns your pull requests. Mergify features allow you to automate what you would normally do manually. You can secure your code using a merge queue, automatically merge it, and many more features. By saving time, you and your team can focus on projects that matter.

Mergeify can coordinate with any CI and is fully integrated into GitHub. They have a startup program that could give your company a 12-month credit to leverage Mergify. That's up to $21,000 of value. Start saving time. Visit Mergify.com to sign up for a demo and get started. Or just follow the link in the show notes. Back to the episode. I have some questions, but I guess, yeah, so to like, to kind of bridge that back,

what I hear you, you kind of calling out is, and I've observed this across many tasks, is that the last thing you want to do, and we talked about context switching, and that is you're ready to go do something, you hit compile. And then, you know, 10 minutes later, when you've awkwardly, like, I don't know what to do, check Slack, whatever, compile. And then, you know, 10 minutes later, when you've awkwardly, like, I don't know what to do, check Slack, whatever, your code comes back, oh, you, you know, you have a typo. You're like, oh, crap, you're like trying to figure out whatever, right? And so that, you know, when you have those friction points, then, you know, it just, it just, it kills more than just the time lost. So if I hear what you're saying is infrastructure code

is in part to do this, that like you get ready to go deploy. And then there's these tasks that need to be done to make sure that in exactly the same way. So not only is it a tedious task, it's a task that needs to be done accurately, precisely, repeatably. And if you have a human do that, they're going to be context switched out, they're going to be frustrated, and you're going to lead into those problems that just take them out of their comfort zone, out of their flow, right? And like, put them into doing this task. And so this infrastructure at Code, you were sort of describing as helping solve that process to help like kind of go in and address it. I love so much that recap of what I just said, Patrick. It's like it was a complete, like a lob, a total softball. I mean, because that allows, so now I get to take

the other side, like the leadership management side, if you think about it. So, you know, I love, I don't know if you in the audience picked this up, but Patrick said one really cool thing is not only is this tedious job that you have to do, and it's done, you know, manually a lot of times, but it has to be absolutely bulletproof, repeatable automation. And it screams. And when you hear that, you know, something has to be done reliably, fast, and 100% of the time done the same way, you think scripting. And when you don't do scripting, you've identified a task that is going to wear down a developer's soul.

Oh, and one more thing I want to say about that is we're assuming that the developer has the necessary skills to build that infrastructure. But that's the rub. We're putting things on the developer that are not their responsibility. Is the environment hardened? Do they have a security opening? Did they conform to their corporate standards in getting the subnet correctly on? These things, you're paying a fully baked rate for a developer to figuring out something that they, there's a skills gap there. If we could somehow, what IAC does, it does another thing for leadership. It's taking a, there's a position typically held by a cloud architect that is responsible for those environments to be created properly, but they're, they number in the few and to make their skills scalable, you, if you put infrastructure as code, they can review scripts and not thousands of individual environments that they would have

on a backlog. So it's like a double win for both the developer and the leadership and it's setting and what infrastructure as code also sets up, sets the leadership up for is taking more stuff off of the off the developers plate. For instance, as a developer, I really am trying to get code out. I shouldn't care about the cloud bill. But to my developers that are listening on the call, on the podcast, you know you have that. At the end of the month, the manager comes up and says,

why did my cost spike suddenly? And then comes the activity of trying to figure that out. That kills me. I don't care. That's your job to figure out. I just write code. Yeah, that may actually not be obvious to people how that works. But a lot of large companies and the ones that don't do end up having someone need to kind of basically review the bill.

Because what they found out is if you don't hold them accountable the bill will just skyrocket and so um having been through companies going through that transition and so you're when you're going in and using a cloud service internal external like you're not paying that bill you're just it's getting built to your company right but it's getting built to some portion of your company and it's getting rolled up and rolled down and all that stuff happens and you're just using it. But then someone in your management chain will get an email at the end of the month or end of the week saying,

hey, here's how much you use. Here's how much has increased. Here's how much of year over year. I'm not telling you to make it go down, but I'm telling you, you should pay attention to it. I mean, at the very minimum, Patrick, it has context switched me. I have to now answer this question. I have to investigate.

But what IAC sort of gets us, infrastructure as code gets us, is there is, it doesn't get us all the way there, but right now I now have automation creating my infrastructure. Now, if your infrastructure is being created by automation, I can put in things called like tags, and I can guarantee that they will show up on my Amazon bill or my Azure bill or my GCP, my Google Cloud Compute bill. Now, that's not 100%.

And I'm going to take a second just to plug, you know, the company that I work for, Quali Torque, Quali has a product called Torque, and we're a control plant, sort of over that. So and all I'm calling out here with this plug is IAC isn't all the way there. It's, you need a process to manage just like code stored in Git isn't all the way there. You need something to sort of act as a control plane and manage that. That's what GitHub is to get repos. You need something over IAC scripts, Terraform scripts floating around in your corporation. That's not going to help you. If somebody reuses that script with your tags on it, you'll get billed for that stuff, even though you're on another project. And so what we thought of is, what's the next step to make this problem go away and to

satisfy both leadership and line working developers? And that's it. It's the control plane that says, I have a list of Terraform scripts or Helm scripts here. We divided up access to different applications, and you can provision all you want in a self-service way. And I can only touch the scripts that I care about, and it auto tags and auto does all that. So now as a developer, I get the environment that I want, and I never have to worry about costs. I never have to worry whether it meets corporate standards because the scripts have been signed off on and now are made available for reuse. And I don't have to worry about permissions.

I, as a developer working on application A, will only be able to see certain scripts. And that's what really I'm trying to sort of nudge us towards. Like, let's stop making this a problem. Let's automate it. Let's give leadership the information they need and developers the ability to just, their fully baked cost is incredible. We want to trust them. If we don't trust them, that's more of an employee

HR problem, right? Let's stop snooping on them. Let's stop micromanaging them. Let's give them the tools that satisfy leadership's valid need for control and compliance and security with the ability to self-service develop. That's the holy grail, right? Maybe I'll express my naivete here. Okay, I definitely will. I have no idea what's going on.

So what i'm understanding in the flow is if i'm a developer and i'm trying to stand up some infrastructure and i can write these scripts you mentioned this terraform home script i'm not sure the difference but there are these two ones and then the idea being that like when we stand it up we want to associate that the things that we're bringing up are uh able to be grouped later so you can analyze them so you have these these tags you put on it you bring your stuff up i imagine you're saying how many of the thing you want like i need x number of processors i want you know x amount of i don't know bandwidth or an engine x you know proxy in front that's gonna do this is this the

level am i kind of you totally got it. I did want to add one more thing. So we talked about the grouping logically. And we talked about doing that in tags. But another thing with the scripts, a lot of times just on their own, don't don't kind of address it's it's the lifecycle of infrastructure. A lot of these were just meant, hey, I gotta, I gotta stand this up fast. But you know, one of the ways that costs increase in the workplace for cloud causes, I forgot to kill an environment. Isn't that the dreaded one? Well, here with a control plan, and one of the things that we did was we took scripts and we say there is a lifetime. You set the lifetime at the beginning, and then it's guaranteed whatever assets were created by the

control plan will be at that time when it's expired, it'll be killed. There's no I went over on the weekend, and I left a very expensive perf environment up. You know, there's none of that. So now, not only did I not have to worry about costs, but I can also confidently as an application team developer, I can confidently say I am reducing costs without it being a burden to me. It'll just die on its own in the time that I set. And I have the receipts to prove it. Nice. Okay. So I see this. This is addressing, yeah, we have this, you know, I mentioned this summary page comes out. Management's like, hey, what's this thing that's been running for this long? Does anyone know who owns it?

We email around the team like, hey, who has this AWS instance running? Like, does anyone know what it is? Is it safe to take down? Like, we could take it down, but we don't know. Is it like serving some critical role? And like, you know, it's gonna... So what you're saying here is like,

not just, it helps with that as well. Not just like, hey, this is expensive and running, but where did it come from? How it get there who deployed it i mean are you getting that kind of like provenance information as well yes 100 and and also i mentioned um compliance and like okay we started talking about developer burnout and iac and those are sexy topics i'm about to talk about something super unsexy ready compliance? Compliance. I can just sort of picture all the folks listening. It's like, yeah, that is pretty, pretty unsexy. Tell us why though. I think actually a lot of people are going to be like, like personally, I've never

run into compliance issues. So I don't want to talk about it because it sounds horrible, but I actually have no idea. Like does it actually actually be yeah i mean compliance for me just it sounds like a person with a suit who has like a two sort of pockets in his lapel and he's got the left pocket for left ear q-tips and the right pocket for right ear q-tips and never the two shall make you know one of these type of things you know okay so let's talk about compliance all right um folks on listening might remember there's a uh a lot of times software is built by you know taking uh public open source pieces of software like log4j and whatnot and recently we've heard about some very public you not mentioning any names, but very public, very embarrassing security breaches made.

And then when they root caused it, it was simply none of their software had a problem. It was software that they brought in that they depend on, such as a vulnerability in an older version of like say Log4j or something that's very popular and used by many. Compliance is making sure none of that happens. Somebody, so, you know, in the olden days, it would be somebody, we would have a BOM. It was called a BOM, B-O-M, a BOM list for software, like, oh, these are everything. And it was shrink wrap software, right? It was like a CD, you know, of, oh, here are all the files. And in the good old days, I could just check off all of these, you know, it's like, Oh, I know where this came from, whatever. And it's burned on CD for life. And it's no problem, right? Things have gotten much

more complicated in a connected, you know, open source, commercializing open source items, type of world. And so this is super important. And some of my colleagues in like, for instance, we have a partner, you know, JFrog makes one of the most popular artifact repositories there. And they offer that's so popular that they offer scanning all your binaries for you, and whatnot to see if you have any of those problematic dependencies. But the point here is the compliance is real. It's not going away. And if you go to any like DevOps, you know, conference, what they're going to talk about, they're constantly just like everything gets cheaper when you push it upstream in the development

process, like in the thinking and the coding part, they're going to start and they're calling it a DevSecOps. They're pushing security up the food chain. Now, I don't know about you, but I don't know jack about security. Okay, I need tools that are going to help me do this. And I don't really want to. And that's one of the things that we encode to you have a cloud architect responsible for this, they're going to make sure your Terraform scripts or your Helm scripts are correct. And you're scanning all the pieces and the infrastructure meets the requirements.

And so then we publish it as a card in a catalog, but this is your infrastructure, super cool app, number one infrastructure for QA or whatever. And when you have those cards and run it, you'll know compliance is done. And you therefore remove the bottleneck of your cloud architects time, you don't need to hire multiple of them to it's just one person scanning all the scripts. And you've also taken away the developer having to worry about this. And third, leadership is happy because now, you know, you have stability, you have compliance, and that all helps you make money. You know, it's confidence that your software is not broken, and you're not going to have an embarrassing, you know, public incident. So the so the control plane and bringing it in what you're accomplishing

here is tying even more pieces together and allowing them to be sort of like view all all at the same time. Because as you're mentioning all these things are somewhat disparate like security compliance this that and what you need is a common place where as you said it's management you want to be able to go and know what's happening and as a developer you don't want to care you just want to say like i didn't get my stuff out and so what you're trying to do is sort of aggregate all those things together put them in a common place so that they can really just oh i hate that word synergy but they can all just sort of like combine to what to use it no no no i always get pissed out when i use it as i was being a shill but uh you

know you bring it together and you know just sort of like it makes more sense to have them always like you mentioned i mean github right git was not in my opinion it was cool but you know version control your own peer review process bringing it all into one place and adding you know the syntax correction suggestions and the peer review comments and the automated jenkins test results right putting it in one place the pull request mechanism in one common place you know i was gonna respond but i think patrick said it all and i just want him to come work with me too because he said it better than than i could let's just like deep dive into that statement control plane is nothing new okay like a control

plane you can find it in in technical literature all the way back into the 70s. What is new is like, and I like, I don't know if anybody else in my company likes this, but I like comparing it to GitHub. On the face of it, you think to yourself, oh, GitHub doesn't sound like that complicated of a piece of software, right? It's just a web page that's displaying repos in a common location. Anybody could have done this, but I think people are missing the point. It was a need. It was a need to centralize a decentralized sort of structure. And here we're on the precipice of that very same need.

You have DevOps as a movement where you're sort of freeing developers and operation folks to do things how they want to. But when folks do things how they want to, there has to at some point be, and usually leadership plays this role, like a true north to get all of the cats herded in the same direction, right? And that's what GitHub does. And I love GitHub for it because it's going to make my job a little bit easier. We're trying to do that with infrastructure. And by the way, this isn't even a new concept. You know, we talk about GitHub. But another place that is a control plane like that is Artifactory, for example, for binaries.

It's a common place where people are addressing what version of their binary do they have? Did it scan and meet compliance? Is there, you know, they publish reports, permissions of who can download that. And we've done this all along the way. And I mean, you know, folks who are into predicting the future, like, check out how easy it is to see where the future is going. We had code stored in a distributed version control system, Git, and now we have GitHub. We had binary stored internally, and now we have Artifactory being a control plane over that. And now we have the need for infrastructure to stop being a bottleneck, and we're going to see that there is a need for that control plane. One place for it all. One place where leadership can guarantee its audits, team development leaders can determine who has permissions to these assets.

And finally, we're talking about the developers and avoiding burnout. I don't ever have to open up a DevOps ticket to get my QA environment. By the way, let's talk about that. When we do this manually and when we throw this on DevOps to provision us an environment, I would love to get feedback from

the audience. How many times in your life has that ever worked? The first time it was presented back, DevOps ticket comes back, it's like, oh, you're done. Does it work? I can't even SSH into it. Forget about it. You know, so it is going to be iterative, you're going. Does it work? I can't even SSH into it. Forget about it. You know, so it, it's, it is going to be iterative, you're going to have to do it. And I would love to hear back from people if there's a ticket needed to open up to start an environment. I'm thinking it's going to be at least a week before you get an environment, you know, prove me wrong, you know, is what I want to say. Yeah, I mean, I, it all makes sense. So I mean, I think we set it up pretty good. You know, I want to make sure we take your time. So tell us a little bit about like,

so you were kind of mentioning, I mean, I think we got the hint here, but where is quality trying to come in here and help? And like, what are they doing to kind of try to address this need that you're pointing out? Oh, yeah, like, thank you so much. So I have been hinting at it. And it is all about the control plan. But let me just like, I'll start off sort of with the corporate line. And then I'll just sort of drill into, you know, where I'm most passionate about. But yeah, we're fulfilling that GitHub and that Artifactory sort of control plane for infrastructure. And there are the pillars that we talked about, right? So there's self-service for developers.

There's a role-based access controls. That's for development and leadership and DevOps team. There's auditability and cost control, all things that leadership care about. And we're trying to put that in one, not trying, we've put that in one place and we're looking for folks to, you know, come tell us what their experience is with that.

I'm hoping it'll be transformed. Okay, now here's where it's the aspirational. Here's where, this is Ronak talking about this. I'm hoping that this basically is indistinguishable. Quali's Torque control plane is indistinguishable from infrastructure as code the same way as GitHub and Git are almost indistinguishable. Some people say, yeah, I'm using GitHub or I have a GitHub repo. It's like, well, it's a Git using GitHub, or I have a GitHub repo. It's

like, well, it's a Git repo that's being hosted over there in GitHub. And I want people to make that same sort of funge, that same mistake, because I'm convinced that in addition to it benefiting my chosen place of work, I believe this is actually something that's going to help benefit people. And if they feel different, or if they don't see what they want, here's an opportunity to sort of direct that. And I want folks who participate and use this control plane to think how this is going to make their life better. Because if it's going to make their life better, it's going to probably make all of our users' lives better. And this is like one way.

And, you know, it's kind of like tuning up a car. You know, it's like, all right, I tuned up a car, I put a turbo in it. It's like, I'm going to find the next part that needs help, right? Let's nail infrastructure as code and let's move on to the next problem. Nice. So Quali has built out this TorqueDisk control plane. control plane they're you know trying to help with this

stuff i mean you you're there obviously like you think this is a this is a worthwhile wild thing tell us maybe a little bit about quali as a company how to work for it like do you feel are they giving their developers a chance to avoid burnout uh not not trying to set you up but you know it's one of the things I discovered, you know, like, it's sort of how I came upon that realization that I don't like lying, because that's too much to remember. So I like working for places where I don't have to parse myself. It gets me in trouble sometimes. But I work for places that are, you know, sort of like mine that fold in with my worldview. And I personally,

okay, so first of all, location quality is located in the beautiful, sunny Austin, Texas, you can't go wrong with that in the in the domain area. So, you know, just super cool place to be, we're working on something that matters. I think. And if you take a look inside and you feel that this matters to you too, come talk to us. And we really, that's, if you look at our company history, we are trying to solve this problem.

And it's almost inextricably, I can't say that word, tied in with developer brand. I really tried. I tried to say that word. Iably, I can't say that word, tied in with developer brand. I really tried. I tried to say that word. I just couldn't. Inextricably? Yes.

Thank you. I just forgot. It's okay. It happens. It's Monday. It's so Monday. Come check us out. There are ways to, feedback is important.

If you don't want to work for us, you're like, oh, that's a little too much commitment. Try out Torque. Do you guys remember the old discount tire commercials? If you don't like your tires, come tell us how it feels. You see an old lady throw a tire through the glass, come throw a tire through our glass pane. Not literally, please. Well, okay, yeah, I guess not literally. I don't want to incite any riots. Yeah, that's it. Oh, and, and personally, I would love to and just the personal part of me, I you know, I want to hear about your experience. And I know where that next place after we nail this problem, it's going to be continuous testing, we're gonna have to, we're gonna have to address that, too. So you have a future. This is just like tuning up a car, we're just going to be continuous testing we're going to have to we're going to have to address that too so you have a future this is just like tuning up a car we're just going to find the next place that needs it and once we have it all under the umbrella of a control plane we're going to give folks the framework to address all these future problems as well i mean it sounds awesome i mean i think for

people trying it out, do you guys have like a free plan, a way for people to try Torque, a website that they can go to? 100%. It is, you know, portal.qtorque.io forward slash join. And there's a free tier that you can sign up for and think about it and it's free. And I was very adamant that, you know, it should be free because I fully believe in like, you know, giving something of value if I expect to get something. And I would love to just, I ask for feedback. That's awesome. Yeah.

I mean, I think, you know, definitely check it out. We'll have the link in the show notes. And this has been a really awesome, I mean, we covered a lot of ground. I feel like probably a lot of questions, people are going to be left like, wow, there was a whirlwind tour of infrastructure as code. I feel burned out listening to it.

No, no, please, hopefully you're not burned out listening to it. I mean, I think, you know, a lot of these things and it helps us start early. I mean, I mean, it's, I guess it goes without saying, but, you know, realizing there's an issue both when you're problem solving for building a company or a tool or software,

but also burnout. I mean, being really attentive to the direction something is headed and making sure that you manage technical debt or personal debt, like making sure that you're really on top of the ball would be a parting admonition I would give people, I guess. Well, thank you so much for having me over. Have me back over and we can go even meta.

We can start talking about, okay, when you start getting rid of this burnout, what are you going to do as a developer or as a tech worker? What are you going to do to actualize that true self? What are you going to do to make this place that true self? What are you going to do to make this place better code on personal time? We could or or how about this? How about we can, you know, every library has, you know, rooms that you can like reserve, why not host like a STEM night and pass on some of your coding skills, just even showing a kid how to use Git, you know, you'll find new ways for kids to hate you in the area.

Yeah. I was completely killed at the end. I was not ready for that. So, you know, I'll say that I think that's really important. And you mentioned this several times, like, we're really privileged for a lot of reasons. I mean, talking i think of you know i see sometimes people driving around where i live there's lots of construction i see people out working in the heat and i think about like oh my gosh like my burnout is an entirely different beast than you know hauling around two by fours in the you know hot summer day so i think we're privileged and i think you said a story ronak about your father being an engineer and sort of like having those books available answering questions i'd say my father was an engineer you know but there are many kids out there that like have the mindset but they they

don't have a live they don't have a book on the bookshelf for them to discover they don't have someone to come up and point the flaws in their Fortran code they wrote on paper or break it, right? Like they don't have, no, be nice, be nice. But like, you know, I think this is a great point, like trying to help those and bring folks in who just, you know, we get sometimes to the podcast where people write us, hey, you helped me get into tech. I mean, now we've been doing it long enough. Some of those people are already like well into their careers now. And it really helps you feel that sense of like you said giving back really finding someone to kind of pass the baton to when when somebody tells you that patrick doesn't it just it doesn't it just make your day and that's that's what we're

talking about in this podcast we talked about developer burnout and that's kind of like I'm equating it in my mind. That's kind of like, oh, okay, I am helping somebody at a car accident, right? And here, addressing developer burnout is more like I have applied a tourniquet to somebody, okay, to stop the bleeding. But we're going to need more help. We're going to need actual help at the scene here. But that's okay. We're going to survive and we're going to do it together. And then you're going to, you know, be it months from now or a year from now, we're going to talk about the next phase to that

actualization and making things better. And I thank you guys for the extreme privilege it was to talk with you. Well, thank you everyone for listening in again, and we'll see you next time. Music by Eric Farndaller. music by eric barn dollar programming throwdown is distributed under a creative commons attribution share alike 2.0 license you're free to share copy distribute transmit the work to remix adapt the work but you must provide an attribution uh to uh patrick and i and uh share alike in kind