Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Episode 1: Tales From the Trenches with Josh Marotti image

Episode 1: Tales From the Trenches with Josh Marotti

The Forward Slash Podcast
Avatar
74 Plays1 year ago

We sit down with Josh Marotti to hear some tales from the trenches from his 25+ year career.

Recommended
Transcript

Importance of Transparency in Career

00:00:03
Speaker
being transparent, being able to discuss things with people, not being afraid to say, listen, this is just the way it is. I'm learning how to push back. My career really started to kind of go somewhere when I was just willing to be able to be transparent. The more you do it, the more you realize people aren't going to yell at you, but they're going to want to understand and work with you. And in turn, you start really wanting to work with people and understand their point of view. And that's really how you move forward.

Podcast Introduction with Hosts and Guest

00:00:36
Speaker
Welcome to the Forward Slash, where we lean into the future of IT. I'm Aaron Chosney with my co-host, James Cartman. James, who are we talking to today? Today, we're going to be speaking with Josh Marotti, one of our principal software engineers at Collibrity.

Josh Marotti's IT Journey

00:00:51
Speaker
I'm Josh Marotti. I've been in IT for around 25-ish years.
00:01:00
Speaker
I've been a consultant the vast majority of my life. I've worked in various different roles from I've tried project management to, you know, I got to agile real early, um, didn't enterprise architecture, was a director at one point. Uh, so I've kind of touched a little bit everywhere throughout my career and I've been with Liberty a pretty long time. I'm coming up on eight years.

Refereeing Insights and Thick Skin

00:01:22
Speaker
So I have an interesting factoid here that was handed to me that you're also an NFL referee. Yeah. So do you like picking on guys that are bigger than you? I'm a college football, football referee, not an NFL referee. So I know several NFL referees, including some guys that just did super bowl. Um, but no, I, uh, uh, and, uh, yeah, it, uh, I get picked on a lot more than the play I pick on any players. That's for damn sure.
00:01:52
Speaker
Yeah, you learn how to get thick skin really quick. And this is going to be my 12th year in college. And I'm almost 20 years since I've started doing referee altogether. So it's an interesting side job. And it's a lot of fun and keeps me in somewhat shape, although that shape right now is a pair. But at least it gets runner out of it.

Lightning Round Explanation

00:02:16
Speaker
All right, Josh. So the way we're going to do this, you're going to get a series of questions. You get 100 points for each question. And for every question you miss, we'll set you back to zero. And if you have any points left at the end, you win the grand prize, which will be your supply of respect and instant gratitude. And there's no way of saying thank you like instant gratitude. So without further ado, James, let's go into the lightning round.
00:02:46
Speaker
Josh, are you ready? Are you clear on the point values and what they mean? Yeah, I think if I answered all of them correctly, I'm not going to get the prize, but that's fine. I'm

From Gaming to Software Engineering

00:02:57
Speaker
still good. So what got you into the field of software engineering? I think I'm going to speak with, at least in my generation, a good 90% of everybody got into this because we really liked video games and wanted to code video games. I mean, let's be honest. What was your first exposure to software development? How old were you and how did that happen?
00:03:17
Speaker
I can't really give you an age. I was young, but it was a Commodore 64 that you plug into a TV. It was way back in the 80s. I'm giving away my age a little here.
00:03:33
Speaker
And that that kind of got me doing like the 10 go to really 20 go to 10 print something in 10 and seeing it go on the screen in high school. My sophomore year, not my junior year of high school, we had the math teachers teaching some basic
00:03:50
Speaker
And I aced it into the point where there was like four of us that were really good at it. In my senior year, we got to do Pascal. And I got to learn how to use pointers and references. I wrote a fractal and we had a 486 with a math code processor. So by the end of the day, you could actually see the fractal. It didn't have to be overnight that it had to run.
00:04:10
Speaker
So that really got me interested. And then I went into school.

College Days and Early Web Exploration

00:04:14
Speaker
I was a college computer engineering degree major. Fun fact is that right before my freshman year, we had this little course where you just learn how to use the Unix systems there and stuff like that. And while we were there, they're like, hey, there's this new thing, the World Wide Web. Do you want to go to Yahoo? And because we were all learning how to use Gopher and Telnet and stuff like that. And it's like, yeah, like for one day we learned how to do this thing that ended up blowing up
00:04:39
Speaker
while I was in college and learning about it all. So that was a, that was interesting. But yeah, we went immediately into C and that was a weeder course. And the fact that I knew the how pointers and references work like got me out by the skin of my teeth on my first year. So it was an interesting journey and probably very different nowadays. Um, we didn't have YouTube and stuff to help us teach these complex concepts like pointers and stuff, especially for a young high school kid. But, uh, yeah, that's kind of how I got into it and, uh, fell in love with it and all that.
00:05:10
Speaker
Great. When you look back on your career, can you think of any any sort of like, you know, moment a pivotal moment in your career that that may have significantly influenced you and how you how you go about software engineering today?

Learning Transparency as a Consultant

00:05:23
Speaker
Yeah, I'm going to say not more than just software engineering, but the whole consultant mindset. In my I mean, I had a pretty big moment in my like mid 30s when I was I was having some issues at home and I had to go through the wars and all that kind of stuff.
00:05:40
Speaker
And I used to be really good in my 20s. And I'll readily admit this is being kind of a jerk. I learned how to, you know, make throw a whole bunch of balls in the air to lie, to make sure things went smoothly to people, please, and that sort of thing. And it all kind of came crashing down at that moment in my life. And I had to go through a lot of therapy.
00:06:00
Speaker
And I learned to be transparent. Now, I wouldn't recommend people doing it the way I did it, which was throw out the baby with the bathwater and be super transparent about everything and not caring and stuff like that. You still need to add caring and, you know, don't be a robot. But being transparent, being able to discuss things with people, not being afraid to say, listen, this is just the way it is, learning how to push back. It's so much easier when you're transparent. Whenever you can say upfront, hey,
00:06:29
Speaker
This is a problem. We're already running into and we're way early in the project That's a lot easier for people to take and be able to move dates and stuff like that if necessary Then waiting till the last moment say oh we didn't finish we need another month You know that that kind of was a big transformation on my part And that's whenever I my career really started to kind of go somewhere when I was just willing to be able to be transparent
00:06:54
Speaker
I mean, the more you do it the more you realize people aren't going to yell at you but they're going to want to understand and work with you and, and then in turn you start really wanting to work with people and understand their point of view and that's really how you move forward it's like,
00:07:09
Speaker
whenever you're young, you're always like, I have this point. I wish people would listen. And it's like you need to kind of reverse your thought process of they have a point. I want to listen to theirs. And hopefully if I listen to theirs and acknowledge theirs, they'll be able to listen to my point and maybe we can come to a solution. And that's I was way too late in my life, I feel, to kind of get this. I really wish I would have gotten it by 20s. But yeah, that's the real big kind of shift in my life that kind of happened at some point in my career.
00:07:38
Speaker
Yeah, I guess the problem with being overly transparent is people see right through you.
00:07:43
Speaker
Yeah. Wow. Well done. Well done. Something. Good times. Good times. Good times. That's pretty good. So, I mean, I don't know. Don't sell yourself short on the, you know, the violence swings, you know, going all in. That's kind of the way our entire industry works, right? You know, oh, hey, this DevOps thing. Okay. Nobody, there's no data centers ever. Let's run everything from our laptops. Like, you know what I mean? It's just these,
00:08:10
Speaker
violent pendulum swings with the whole industry. So I think you fit right in.

Advice for Aspiring Software Engineers

00:08:15
Speaker
Well, you mentioned a little bit of advice, but we had a question here that kind of jotted down about if you had any advice to give to an aspiring young software engineer or an aspiring young consultant, what would that be to help them excel in their career?
00:08:30
Speaker
This is a canned response that everyone that's ever been mentored and reported to me has heard. And that is find three things that everybody hates or no one wants to do and become an expert at it. I will give you by three. It is testing. It is pipelines like DevOps pipelines. And it is observability logging alerting.
00:08:53
Speaker
Um, if you ever go, I'll go and I guess normal order, which is like testing. If you go to any organization as consultants, we never go to. You have rainbows and puppy dog environments where everything's working great. They need our help. So I guarantee you, you look at their tests and people are just going by the numbers and trying to hit a metric or something like that. And they don't truly do good testing. They don't understand good testing. They don't fall back. They don't do, they don't want to do refactoring because their tests don't or, or, or, or, you know,
00:09:23
Speaker
they'll fail easily, they're brittle. So learn how to do that really well and just go in there. It's like, when I'm first on a project, I want to go, it's funny, I was just talking to Daniel Silva about this yesterday, you know, what's different about being a consultant and being a Caliberty consultant versus, you know, just an FTE there. And it's like, my first day to kind of, you almost want to show your potential as easy as you can, but don't overdo it. Don't try too hard, but it's like,
00:09:49
Speaker
I could go into a client and go into their tests and make amazing tests out of it and improve whatever they're working on Without having to really know the domain I could go into their pipelines my last client. I went to their pipelines They were having a lot of stuff that wasn't automated automated automate all the things. That's what pipeline developments all about I don't want to hit buttons and push things and wait for responses No, just put it into the pipeline and let her do it automatically every single organization
00:10:15
Speaker
Dashboards terribly alerts terribly. You should be able to go to one dashboard see the entire system green yellow red Everywhere when necessary and red really means things are down yellow means that yes There's a consistent problem and green means everything's good And if you do that it the yellows and reds pop out like crazy and it's really easy to say hey There's there's a potential problem here or this system's down we need to know how they're all related and what all's missing and down and and
00:10:43
Speaker
You know that sort of thing. I mean stuff like resiliency is big nowadays containerization You understand these things that some people don't quite understand you can really stand out and you could really be very very important to a group early on and and really be able to
00:11:00
Speaker
Because you're doing stuff people don't like. I mean, who wants, who doesn't want someone like that on the, if someone wants to do documentation, you can be on every one of my teams. I will, I will, you will be my right hand person. I will love you to death because I hate documentation. So just find some things people hate and be great at it and you will really stand out and it'll really help further your career because people will want you around.
00:11:27
Speaker
That's great and good advice. So that brings us to the halfway point. So far, you've got a perfect score of 300 points. So let's take a break to know you a little better.

Understanding Perspectives and Taking Criticism

00:11:40
Speaker
What would you say your favorite skill is outside of IT?
00:11:44
Speaker
I used to think that I was really good at seeing other people's perspective, but I've known too many people that do it so much better than I do. Being able to try to put myself in the feet of other people. It all relates back. You do a great job. My best trade is I could take a lot of heat. I always offer to people, if you want to yell at someone because that's the way you relieve stress or you need to
00:12:11
Speaker
That's the best way for you to cool off. I mean, I want a little bit of a heads up, but come yell at me. I literally do it. I've learned how to do it. It's a skill I've established in my reffing career and stuff like that. I can sit there and take a beating all day long. Feel free. I mean, I'm great at that. But really, I mean, what really falls, I fall back to is trying to understand people's perspective and why they're doing the things they do. It really does.
00:12:40
Speaker
It's become start it's funny coming from me someone that talks way too much
00:12:45
Speaker
It's like developing that listening skill to be able to try to understand people's perspective. And it could be silly things, and you can be wrong. They're doing this for traditional sake. But you kind of have to learn how to ask questions. Be able to approach a conversation and say, instead of saying, why aren't you doing this thing, you idiot? It's like, I need to understand why this decision was made. Because I know you made the decision for a good reason. What was it?
00:13:11
Speaker
and try to take that kind of stance. And I guess I'm pretty good usually at that sort of thing. If you've ever heard me vent, when I vent, I sure don't do that. I just vent to vent. But I do try to get into that perspective whenever I'm actually talking to people and having a serious conversation or something like that. So trying to get other people's perspective and get that little bit of thought process is something I really strive to do well.

Staying Informed in IT

00:13:36
Speaker
Well, and they do say that before you criticize a man, walk a mile in his shoes. That way, when you do criticize him, you're a mile away, and he doesn't have any shoes. Yeah, that's good advice. Because I could take a verbal beating, but I don't want to take a physical beating. So a mile away sounds good. Yep. I think we should start giving points to Aaron for these quips. For dad joke points. Yeah, I think that's good. When they're really terrible, we'll give you 10. Yeah. That's good stuff. That's good stuff.
00:14:06
Speaker
As a consultant and as any technologist, our field changes so much so often. I think since we started this episode of this podcast, there's 12 new JavaScript frameworks have been invented. It's just crazy. How do you stay informed and stay up on all the latest trends and new best practices and all of those sort of things? How do you go about doing that and how do you incorporate that into your daily work?
00:14:34
Speaker
We're just going to skip over. We're going to talk to Josh about JavaScript frameworks. Okay, this is where I'm going to lose all of the points that I just earned for the record. Maybe this should have been my answer to my last question, but I'm going to go in a completely different direction. I'm going to roll back, I promise, to what the actual question is. I always say there's two types of consultants, ones that understand the whole system. So they take a lot of time up front to understand top to bottom and really understand how everything kind of works and interconnects.
00:15:04
Speaker
And there's people that it's like, give me the problem spot, where it is in the code, what the problem is, I'll solve it, and eventually I'll learn the system as I kind of touch all the different points. I am that second person, where it's like, I can get stuff done quickly.
00:15:17
Speaker
But I'm not going to understand the full system, and I'm going to have a lot of questions. And if it touches other systems that I'm all aware of, I could cause problems. But I can usually get in there quickly and learn quickly. I learn on the fly. I learn by fire. Hey, we're going to be using a container. OK, I got to learn this now. And I don't know if that's...
00:15:36
Speaker
Part of like an ADHD thing with me or anything like that but it's like I it's been a long time since I've actually gone out and learn stuff but that's also because I've got decades of experience so it's like this works similar to how this other thing worked and you know like how we used to do proxying works similar to how spring but you know does their proxying.
00:15:55
Speaker
cglib works so it's like i already kind of an understanding of the overall how it works i just need the details and i've had to learn different languages but you know once you learn how functional languages work and procedural languages just work it's just syntax at that point
00:16:08
Speaker
So I'm not the best. I use containerization earlier. I'm not the best containerization person. I have an understanding how it works. I know from a very high level, if I need to get the details, I'm Googling and querying and learning on the fly. So I'm not the best answer. We all need to be learning if you're not learning. What is it? Liya Koka, if you're not moving forward, you're going backwards. But yeah, I tend to learn on the fly. And fortunately, I've been in projects where there's been a lot of new tech.
00:16:36
Speaker
I'm learning tech upfront, but yeah, I don't do a ton of reading. I've got multiple children and a family and a side job, so I don't have a lot of time, especially in like the fall and spring times, but so I don't do a lot of learning outside of work, but I do a lot of learning inside of work for sure.
00:16:57
Speaker
Yeah, I think everybody's career, you know, the engagement ebbs and flows, you know, you mentioned children and that's a big part of our lives, of course, and those things just kind of come and go. I would imagine when you were younger and before you had a lot of these other situations going on in your life, you probably did do a lot more research, I'm guessing. I know that was the case for me.
00:17:20
Speaker
I don't have them out right now because they're all breath books. But yeah, I could have all of my old the C language book. And yeah, I learned from books because it was before the internet because we're all that old. But yeah, absolutely. I mean, there was a lot of reading. I remember Spring having good online documentation. It's the only time I could actually say, wow, this is good online documentation. That's changed quite a bit because now books are so old that whenever they published your two versions behind,
00:17:47
Speaker
Can you discuss a time when you faced maybe a particularly challenging problem at work with your project or some sort of a setback maybe and how you overcame that?

Learning from Mistakes in IT

00:18:00
Speaker
Let's say a massive online retailer. If you go into their signage and it looks like someone hand wrote, this is what this item is and this is the price. That's all. It's actually a specialized printer that does that and it's all
00:18:17
Speaker
in a system and I helped write or not write it, but I was maintaining that system. And back in the day, I just had various different Linux terminals up and I would go into the database and do stuff and I was testing and before there was unit testing and I was, you know, I was doing testing in a test environment and often we just blow out the database, recreate it and with more test data. And I did that.
00:18:41
Speaker
Except the creation didn't work. The blowaway script worked fine, but the creation didn't work. And I was wondering what the heck's going on. And I'm debugging, debugging, debugging. And then it hit me. I was in prod. And I blew away all the prod data. And this was, I remember when it happened, I remember feeling that dread. Like, oh my god, no, no, no, no, no. Looking, yes, it's prod. And going to my boss and saying, I think I just wiped out prod.
00:19:10
Speaker
And he went and verified. And I was at my desk sweating bullets. And he pat me on the back. And I was like, I don't think you can do much more damage today, Josh. We're going to have to get back up so you can go home early for the day. And I remember going home thinking, I think I just got fired. And whether I should go to work again the next day. And I did. And I wasn't fired. And it took two and a half days to do it.
00:19:40
Speaker
It was a learning experience. What I did at that point was you change your terminal when your production to a bright red background and green writing that's hard to look at so that you don't stay on it and you're not on it accidentally. But it eventually led me to never, ever, I have a big, if anyone ever talks about just going into prod and changing a database, like just logging into the database, I am way against that. I believe services especially should have
00:20:11
Speaker
endpoints that are administrative that have auditing and you can you have to have a special permission or whatever to log into that you can service your own account you should never ever ever have a production database where you can just go in and do whatever you need to do except for extreme last case scenarios and if you do that you're gonna find yourself a lot more secure but yeah it was one of those that
00:20:36
Speaker
those days that that stuck out in my mind because it's the only time I actually thought I got fired for screwing up in my job. And also whenever you get to more of a management kind of or like someone's reporting you kind of scenario, whenever someone fouls up, I can think of a scenario on the other side where someone did almost the exact same thing in a big data project much later in my life and he reported to me.
00:21:00
Speaker
And, um, and he accidentally blew away the database and my response is, ah, well, we're just going to have to recreate it. We've done this before. And, uh, it was a prod database and it's like, let's, let's get that all set up and I'll buy dinner. You know, we'll be here for a few extra hours. And I asked the kid that did it, why don't you, cause he was sweating bullets and he was nervous and it's like, Hey, why don't you come help me? I've got to get a whole bunch of pop and I need to help bring it up, come to the elevator with me. And.
00:21:26
Speaker
He came into the elevator and broke down crying because he thought for sure I was just going to sit there and scream at him. And I was like, no. I actually wanted to go relive all of these experiences when I screwed up fraud, including the one I just gave. And I was telling him all these stories. And it's like, it happens. It's going to happen in your career.
00:21:41
Speaker
I don't need you to fall over and feel so bad for yourself and don't think you're, you know, are afraid to move forward and you're going to be double checking yourself on everything. Just continue to work. We'll put stuff in, you know, processes in place so it doesn't happen again, but I need you to pick yourself back up. You know, it's like everyone's going to be kicking themselves so much in these scenarios that like, this is why I love the fact that we're advocates and cheerleaders for our people. It's like when you're
00:22:09
Speaker
fall over, let us know, because we're going to help pick you back up, because that's what you need. You don't need someone else yelling at you. You're doing a good job of that all by yourself. We're going to help get you back on track, because that's what needs to happen. You have screwed up. And I hope everybody that listens to this screws up massively in their career, not because I'm trying to curse you, but because they're great learning experiences, and I guarantee you'll never do it again. And that's kind of how this line of work is. You screw up, or you have this great architecture. This thing works great.
00:22:39
Speaker
except whenever you actually implement it and you find all the things that are wrong with it because now that it's implemented, it was a new idea. Here are all the cons because nothing is 100% great whenever you're finished. And you learn from that and you move on and make a better architecture next time. It's how we move forward. So hopefully not screwing up production and costing companies billions of dollars worth of damage, but it's like you're going to screw up. Hopefully you screw up as early as possible, learn from it and move on. That's how we all got good in our career.

Caution with Production Access

00:23:07
Speaker
Yeah, I want to go back a little bit and talk about that. Too much access is a dangerous thing. I had a system administrator once tell me it's like, I'm going to make it so you can no longer do any work and I am not going to touch a thing. And I'm like, well, how are you going to do that? And he's like, I'm going to give you root password. And I'm like, no, don't do that. I don't want that level of control.
00:23:35
Speaker
I like to have plausible deniability. Don't give me any production access that I don't need because if something else screws up, I don't want my name coming up. That's a really valuable tip. If somebody wants to give you more access and more controls, think about that before you accept that responsibility. I say that we do a good job of bringing people up.
00:23:59
Speaker
Vice presidents of sales are going to be happy. They're going to want to yell. So you don't want your name involved if you're not actually involved. Well, I think if you don't, especially if you've been around and had a little bit of a career in our industry, if you don't have a I screwed up production story, you're not trying hard enough. You don't have enough passion about what you do if you don't have one of those stories. So that's good to hear. I'm sending anyone straight to you if they purposely screw up production now.
00:24:25
Speaker
I didn't say purposefully. Most people do it on accident. If you do it on accident, that's understandable. We've all been there. We've all done that.

Team Dynamics and Preferences

00:24:38
Speaker
So when you think about the people you like to have sitting next to you on a project or working together on a piece of code or a product, what are the qualities of those kind of folks that you like to have around the job?
00:24:52
Speaker
Oh, number one first and foremost is dependable. I just want someone that I can give someone a task and I'm not saying dependable like I give you a task, it gets done. I give you a task and either it gets done or if you have issues, there's this fine line between going and figuring something out yourself and running your head up against a brick wall over and over again.
00:25:16
Speaker
would you get kind of in the mode where it's like, I don't know what to do. Ask the questions. I don't expect anyone working for me to have all the answers. It'd be great if you did. I mean, but it's like, don't be afraid to ask and get feedback as opposed to thinking that I expect everyone to be able to do everything all at once. Two is being able to work together and not, you know, there's
00:25:40
Speaker
Every team has different dynamics and different personalities and just being able to work together and build trust. Because if you have trust on a team, you can solve world hunger. I mean, trust is so vitally important. Being able to be open with one another, being able to be
00:25:59
Speaker
to criticize thoughtfully and be able to take that criticism and introspect, being able to push back, being able to say no. All these things, if you can do it within your team, is just the ultimate you can get on a team. Personally, with just Josh Morati and not a general sense, I always like someone that likes to do documentation, as I said before, because I hate it.
00:26:23
Speaker
But really I like to my job the way I see because there's different kinds of Leads because I typically lead a team
00:26:33
Speaker
But it's like, I know Aaron's a get in the weeds kind of person. You're going to be in the code a whole lot. I like to go to meetings, help get decisions off the table, let the devs do the work, and I do a lot less coding. So it's like I need someone that I can trust is going to be a good shepherd of the code in my absence.

Decision-Making and Team Focus

00:26:53
Speaker
And I'll still look at PRs, and I'll still help
00:26:55
Speaker
with decision-making, but I tend to stand a little higher than some other leads, so that's something very important to me, is to have a code shepherd that I could always trust and depend on that will have good code, make sure the tests are working well, we're going to cover edge cases, error handling is held well, we're logging well, all that kind of stuff. Yeah, but dependability and people willing to work together and build trust and work to
00:27:24
Speaker
be transparent, introspective, you know, that sort of thing. So you mentioned you like to go to meetings. What does your therapist think about that? I don't like to go to meetings.
00:27:35
Speaker
but I like to call this the white knight factor of Josh Marotti, but I like to go to meetings so no one else has to. It's like, I'm willing to make that, that's the sword I can fall on for the team. I will do all of that stuff so you all can code. And because I know if I know anybody that's developing, it's like you like to sit and code. That's what we like to do. I remember being on a,
00:28:02
Speaker
when I was a current client the first like year I was there I was just a team member because I was just put on there like as a T&M to kind of break the client and it's like after a year I was like man I really do like to code that was a lot of fun and then I got more into the roles that I'm in now which is more like architecture meetings and all that kind of stuff but it's like I'm willing to do that so everyone can do the the work that they like to do and try to get some of the stuff they don't like off their plate
00:28:31
Speaker
But we do have a, we do have a lightning lightning round that we, you know, that these, where we double the points and double the risk.

Podcast Conclusion and Credits

00:28:40
Speaker
So, uh, Josh, I hope you're ready. Um, just a few quick questions. Coker Pepsi. I don't drink much pop nowadays, but I used to be a pop guy, but are you a Pepsi guy, but I could really drink either. I, I, I don't have a preference. I know that's weird.
00:28:58
Speaker
That is weird. We will accept that answer. You won't get any points for it, but we'll accept it as that it is an answer. Okay. Um, I said something. V I or E max. Uh, right. Uh, I would say after college, I was an E max guy, but being in the field long enough, I'm a VM, a VI guy now them. All right. I'd rather have an ID.
00:29:24
Speaker
Kotlin or Scala? I know the answer to this. Oh, you know the answer to that. This isn't even worth asking. Kotlin is the best language in the entire world. Nice. Nice. Just the truth, see or falsie there either, by the way, folks. Yeah. Just for the record, this is not being sponsored by Kotlin. Should be. Right. Should be.
00:29:50
Speaker
All right, so how's he doing on points, Aaron? I think we're getting to the end of time here. So after the lightning round, he has redeemed himself with 200 points. So he's won our grand prize of a year supply of respect in the instant gratitude.
00:30:11
Speaker
All right. So that wraps up our show. Thank you for listening to the forward slash our, our lean into the future of it. I'd like to thank our producers, Dylan courts, Ryan Wilson, and Zach Welchel, as well as our editor, John Corey, and my co-host and lovely man that he is James Carmen. Uh, I am Aaron Chesney and thank you for listening. Stay tuned for future episodes of the forward slash.