#187 Michael Levan learned to detect when he is not learning anymore

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Michael Levan 0:00
So I would say the biggest thing, the biggest piece of advice is to not follow toxic people, like follow what's in your heart and follow what you want to do. I promise you, it's not going to always be right. I've made way more mistakes than I have great decisions. And that's just everybody. That's just what happens. But yeah, don't listen to the toxic people. Always follow your gut and follow what you want to do. That's like the biggest piece of advice I could give.

Tim Bourguignon 0:25
Hello, and welcome to developer's journey to podcast, bringing you the making of stories of successful software developers. To help you on your upcoming journey. I'm your host, Tim bourguignon. On this episode 187, I receive Michael divan. Michael is a principal engineer, industry analyst, and technical researcher. He's passionate about enabling excellence in software development, SR II that site reliability engineering, DevOps, and actively mentors, developers to help them realize their full potential. Michael, welcomed afternoon. Thanks, man. Glad to be here. Oh, it's my pleasure. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join this fine crew, and help me spend more time on finding phenomenal guests, then editing audio tracks, please go to our website, Dev journey dot info, and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guest. So Michael, the show exists to help the listeners understand what your story looked like and imagine how to shape their own future. So as usual on the show, let's go back to your beginnings. Where would you place the start of your dev journey?

Michael Levan 1:52
Yeah, so I would say actually, believe it or not gaming, I got into gaming, I was really into PC gaming, and I wanted to like upgrade my setup and stuff and make it look a little bit better make the graphics look a little bit better. And before you know it, I was saying, Hey, I'm gonna go to school for that escalated quickly.

Tim Bourguignon 2:08
Did you start tweaking your windows or tweaking? I suppose it's Windows, if it was still playing, so tweaking windows and the inside of Windows to get the most stuff off your machine and then overclocking, and then cetera, et cetera. How did that escalate?

Michael Levan 2:25
Yes. So you know what I actually I was like, Hey, I was like, I want to make my computer faster. And I want to make the graphics look better for gaming. And I had no idea about computers at this point. So I was like, I'm gonna go buy some stuff called RAM. I thought Ram was gonna help me it did not. So then I was like, Oh, I'm gonna go buy this graphics card. So I bought this graphics card, and I put it in this desktop. And at the time, I had a Dell Inspiron desktop. And it actually worked somehow, I don't know how, but yeah, one thing led to another, I was like, I'm gonna go build a computer. Next, I want to get really into gaming. And then I was like, I actually really like this whole computer thing. So then I was like, I'm gonna go to school for this. And then before that, I was actually doing personal training. So I was like, really into fitness and stuff. I still am still work out five days a week. And I was like, I like it, but I don't really like it. So then I just kind of fell into computers. And then that was it.

Tim Bourguignon 3:12
What is your idealized picture of what this future would be when you enrolled? When you say, Well, I'm, that's gonna be my life. Now, what do you what did you picture?

Michael Levan 3:22
Yeah, I thought that I was just going to be a hardware guy, I thought that I was going to be fixing computers, I thought that I was going to be replacing hard drives and RAM and graphics cards and all that good stuff. I really thought that I would be on the hardware side, because that's what got me into it. Right. Like I enjoyed, you know, fixing computers, and I enjoyed building them and this out the next thing. And yeah, I really thought that's where the future was gonna be. But luckily, I changed my mind. So luckily, yeah, I would say where I'm at right now, compared to where I thought my career would be, is drastically different, and definitely in a good way.

Tim Bourguignon 3:55
Okay, I'm sure we'll come to that. How did you decide on which program which curriculum to enroll into, which could bring you back then in more into this hardware side of things?

Michael Levan 4:08
Yes. So I actually ended up going to a trade school, I grew up pretty poor. So I didn't have really money for like college or anything like that. So I ended up going to like a tech trade school type of deal, which was relatively cheap. And then they kind of taught us just the very basics of like computer networking, and computer hardware and operating systems. Like there was a class on Windows and Linux, for example, again, very high level learn 10% of what I actually needed by the time I got out. So yeah, I went through that program. And after that, I kind of just started diving into like desktop sport and stuff and then grew from there.

Tim Bourguignon 4:42
Trade School, I'm not sure I'm really aware of what it really encompasses. Can you describe a little bit?

Michael Levan 4:49
Yeah, so I'm trying to think where it would be elsewhere. But at least in the US, it's not like a degree. So you're not getting like an associate's degree or a bachelor's or a master's. You're going through like a 10 to 12 month program, give or take, and that 10 to 12 month program, it's, I guess it would be close to like an A, not an apprenticeship but like kind of like that, where you're just you're learning the skills of the trade that you need to go out and get that first job. Okay, yeah, okay. Yeah. So I guess like the a good comparison would maybe be like a coding boot camp or something like that.

Tim Bourguignon 5:22
long and hard bootcamp classes four year. Exactly. Okay. Yeah. Okay, that makes sense. That makes sense. You feel ready for your first job when you came out?

Michael Levan 5:33
I thought I was like, I thought I was coming out of that school. Like, I'm gonna nail this, I'm gonna make all this money. I'm gonna know everything. And then I came out and I was like, Oh, I still know nothing interesting.

Tim Bourguignon 5:45
So how did your first first job work out?

Michael Levan 5:49
Yeah, so I ended up just I actually, believe it or not, I had my first part time tech job while I was in school, while it was in schools, like I need to make money. At the same time, I didn't want to just go work like a retail job or go work at a CVS or something like that, like I, I wanted to actually work in tech. So I started just applying and applying for different places. And I ended up picking up a gig that I was at until I graduated school. And it was a part time, like, desktop support style job. So I was like answering phones and stuff. And I was going on site to different places, and like fixing servers and all that stuff from like a hardware perspective. Yeah, so I got kind of lucky. But at the same time, I was like, pushing for it. I must have applied to like, 300 400 places, and I ended up getting one of them, which was cool. Yeah, because I knew, right. Like, I knew, like, I didn't want to waste my time, like just working at a retail job, and then hoping I would get a job once I graduated. I wanted to actually be doing it while I was in school. So it worked.

Tim Bourguignon 6:42
Were you kind of shooting in every direction? Or did you have already some direction you wanted to go into?

Michael Levan 6:49
No, I had no idea. I had no idea what I was trying to do. I just thought like, what from what I was Googling, and from what I was, you know, hearing from my professors and stuff at school was like, yeah, just try to do like some desktop support job while you're while you're here or after you graduate. So yeah, I had no idea what I was trying to do. I was just diving into whatever I could, I probably applied for stuff that like I had zero, like I had zero skills for, because I had no idea right, but I was just trying to push out everything as much as I possibly could.

Tim Bourguignon 7:16
That's something that always amazes me. When you come with beginner eyes on something and you don't know what you don't know you don't know the vocabulary even you don't know what you should be searching for. And start understanding what has worked and what is connected to what and what you should be asking the questions you should be asking, etc. That how did you navigate this moment in your life? Dude,

Michael Levan 7:38
it's crazy, man. Because that was like a decade ago. So now when I think about it, like I don't even know how I navigated it like I would just literally just like look up online like IT support or like desktop support or something like that. So it was whatever popped up I applied to you. But nowadays, man, like there's so much verbiage around everything like I do not I feel bad for the people that are just getting into tech now that are like just graduating. Now. We're just trying to figure it out now because there's way too much verbiage and like marketing mumbo jumbo out there. So like I actually understand, like a decade ago, dude, it was like, desktop support. Cool. That's where everybody started, or a junior developer. That's where everybody started. But now it's like, what do you like? What direction do you go?

Tim Bourguignon 8:22
Absolutely. I'm nodding heavily. You can hear you say that your school didn't prepare you enough? I mean, I'm sure that did very well. But it's obviously not enough. What did your curriculum prepare you? Well, for?

Michael Levan 8:38
Yeah, I would say that the curriculum did not do a lot really What did a lot was the professor's so I had two professors there. One was like a IT Support Manager. And the other one was a manager as well. But he was very into like networking. He was very heavy in Cisco and juniper and stuff like that. So I would say the thing that got me ready the most was my professors, because they were actually explaining to us like what you're going to need to be able to get that first job and what you're going to be able to need to succeed. So that was the biggest thing. The biggest success that came out of that program was exactly that. And then just the basics of like understanding what virtualization was, for example, we had a I think it was a Windows course. And in that Windows scores, the professor was like having a setup, VMware Player is spinning up a virtual machine or Windows virtual machine or a Linux virtual machine. So like, I understood the basics like that when I got out of school, and that allowed me to like be able to talk it up a little bit in the interviews, which was nice.

Tim Bourguignon 9:33
Yeah, drop some key words, some words here and there. Say well, I've heard about that.

Michael Levan 9:39
Funnily enough, exactly a decade later, I'm still dropping buzzwords and people are still enjoying it. So

Tim Bourguignon 9:45
I guess it's the craft. We all will do that and it will sit remain this way. I don't see it going anywhere. Okay, so where did you land it in? Where did you land in this first job and how did that go?

Michael Levan 9:57
Yeah, so the first job was June. Near field technician. So what I was doing was a lot of the time like maybe three or four days a week I was on customer sites. And the customer sites were like providing desktop support pretty much the company that I worked in with a managed service provider. So like companies would hire the managed service provider to like do the desktop support for them, instead of having a person come in in house. And they were small companies anywhere from like two people like a law firm, for example, to like eight or nine people like real small companies, and I was going in doing the desktop support for them. At that point, I was learning a ton about Windows Server. So like a lot of Active Directory stuff at that point, a lot of just desktop support, swapping out RAM and hard drives and stuff and servers and all that.

Tim Bourguignon 10:39
Still keeping you a hardware shop. The shops. Yeah, exaggeration. Yeah. Putting around where it's supposed to be not adding anything to the game, but it's still putting around. Okay, how long did you need to stay there? I,

Michael Levan 10:53
as soon as I graduated, I left. So I was there for like a year?

Tim Bourguignon 10:57
Yeah. About a year. When do you decide what was there a moment in time when you decided, okay, I need to move out. I need to do something else.

Michael Levan 11:03
Yeah. So funny enough, like way in the beginning, even in my first job, I learned something very valuable. And I still feel that way to this day. I learned when I wasn't going to learn anything new. And I don't know why, like I did. I don't know how I learned that skill set. But like I said, like at my first job, I learned right away when it was time to move on, because I wasn't learning anything new. So it just got to a point where I was just doing the same thing every day. And I was like, I gotta get out of here. So as soon as I graduated, that was a perfect time. And it was interesting, too, because I went to the next job. And I had I went to school, and I already had experience. So I was like, I had one up on everybody else that they were hiring, which was great.

Tim Bourguignon 11:43
That's a good place to be. Yeah. Have you had the experience of coming into a company and realizing pretty much from the get go, Okay, I'm not going to learn that much here. And having already move out. Stay with us. We'll be right back.

Tim Bourguignon 11:57
Hello imposters. If you work in tech want to work in tech or are tech curious in any way you'll want to listen to this. We've launched a community of professionals who come together to share information and advice about jobs, roles, careers, and the journeys we all take throughout our lives as the designers, builders, fixers investigators, explainers and protectors of the world's technology. We call it the impostor syndrome network. And all are welcome. So find the impostor syndrome network podcast wherever you listen to find podcasts, and look for the isn community on your favorite social platform. Hashtag impostor network.

Michael Levan 12:39
Yeah, no, absolutely 100%. I've definitely been in jobs where like, I've went in, and I was like, No, I'm not going to be doing really anything different here. There's always something to learn where you go, if it's not tech, something that I was able to learn was like the business side of things. So I remember I went to one job, and I was pretty much doing the same thing that I was doing in the previous job. But what I did learn was, I was in meetings with the CEO and the CTO and the VPS. And I under I started to understand more from a business perspective, which ended up being drastically important later on and even to this day,

Tim Bourguignon 13:11
so So how do you decide when you have the feeling? Maybe on the technical side, Cetera, you're not learning anything anymore? And just not dropping? Everything right away at the same? Okay, can I pivot a little bit and learn something else? And then move out? How do you balance this Do students?

Michael Levan 13:27
Yeah, so I'm not a I'm a pretty big risk taker. To be honest, I have a pretty big entrepreneurial spirit. So for me, like once I'm ready. And once I'm like, Hey, I'm not learning anything new. At this point, I'll just jump into something new, or I'll figure out like, what the next steps are gonna be. I don't I don't tend to think about risk, I tend to think more about what I can get out of something new. So for me, it's really about like, Hey, I'm not doing anything new. At this point. It's time to move on.

Tim Bourguignon 13:52
Okay, good. All you afraid that you're maybe missing some key learnings that you could have had? If you pivoted and searched in a different direction?

Michael Levan 14:00
Maybe? Yeah, I mean, there's maybe some stuff that I could have learned if I stayed around a little bit longer and all of that, but to be honest with you, it's never been something that's dragged me down or something that's helped me in the wrong direction or anything like that. Like there's I've never had a point where I left somewhere and I was like, Oh, crap, I should have stayed there. I've never had that feeling before because anything that I do, and um, I would say I'm pretty decent at like, figuring out what the next best step is. So everything that I've always done, like always, the next steps have always been something that is like drastically changed my career and my path and something that don't make me much happier.

Tim Bourguignon 14:35
Okay, so when you left this company, did you change something drastically that advance you in a different direction?

Michael Levan 14:42
Yeah, absolutely. So when I went from my first job to the second job, I number one started to be on call. So like, when something were to go down, I was the one that like, had to go in and troubleshoot at 2am Whether it was something software related or something hardware related, so that definitely drastically changed my mind of troubleshooting. But like in the first job, it was like, I was just doing the same stuff all the time I was going into a site, I was fixing somebody's computer, somebody's server, and then I was leaving this job. And the next job I was like, Yeah, I'm actually like hardcore troubleshooting right now. And like, starting to understand the in depth knowledge of systems and and operating systems and software.

Tim Bourguignon 15:18
Was it with the Segway toward the toward software at the time?

Michael Levan 15:22
Yes, yeah. So well, actually, I wouldn't say that was a segway. The next job was the Segway. Okay, yeah. Because they're sure, yeah. So then the next job I had a manager has, and he's actually a really good friend of mine. His name is Carlos. And funnily enough, later on, he was my manager there. And then at a few jobs later, I was his manager. So yeah, there was a funny turn of events. So and we're still really good friends to this day. So when I started working with him, he started telling me about this thing called PowerShell. And at the time, I've never written a piece of code in my life, like I was barely in the terminal, I was GUI admin, as we call that back in the day. And so for me, it was like, kind of scary, because like, I never wrote code before. I never, like understood it. I never understood automation. And once I started doing and I started dabbling into PowerShell. He's like, man, he's like, You should do it for like the virtualization automation stuff, and to create servers and this at the next thing, I just, it was like a rocket ship at that point, like, I got so obsessed with writing code, like I read through pretty much every PowerShell book I could, then I started to dive into Python. And it was like, just time after time, I was just trying to figure out something new from a development and automation perspective. Yeah, that's what really like took my career off, I think.

Tim Bourguignon 16:39
Hence, the the heightened cushion in the background here. Oh, yeah. I like like, six. So that was that was automating? And did you decide at that point to stay in there? Or were you still torn between? Maybe it should do hardware? Or was really, software all the

Michael Levan 16:58
way? Oh, no, it was like 100%. At that point, like, I just did my best to never interact with the UI or GUI again, like everything was automation, and like, what API I could hit at that point. Yeah. Okay. It was like full 100%. Taking that take an automation and development course.

Tim Bourguignon 17:15
Nice. Nice. So how long did it take you to build enough skills to say, Okay, now I learned enough, and I can apply for a different job really going to this direction?

Michael Levan 17:26
Yeah, so I would say, the job that I was at where I was learning PowerShell, Carlos and I, we were like, really heavy on it. And there was other members of the team that weren't, they like didn't see the value in automation. So once I kind of realized that, and I realized that I wasn't able, I wasn't gonna be able to, like really do anything from that perspective, I ended up jumping to a different job. And that different job, it was so low key that it was pretty much like, I had six hours a day to just do whatever I wanted to do. And in those six hours, like I just automated everything, every single thing with PowerShell, every single thing with Python, I was just automating stuff that just didn't make any sense. But I was just doing it because like I could, like I had the time to do it, which is awesome. And that's what I was able to take that and then move into another job. And that's where like, I started to get into like more senior cloud engineering, senior DevOps, senior SRE all that stuff.

Tim Bourguignon 18:22
Yeah. How did you tread the this fine line between writing scripts, which are really doing their job and redoing what it shouldn't be? And going back to where are the key concepts of software development? And what does it look like? I mean, you can do Python in a very sequential, strict manner. But you're going to also create a very elaborate Oh, programs with with Python. And you can do some functional as well. How did you navigate this? So this?

Michael Levan 18:48
Yes, so when I was doing PowerShell, it was definitely more script related. And I definitely wasn't thinking about it as a developer, once I started to dive into Python, and like, because I guess the biggest difference between a purely like automation language like PowerShell, and a language that you can do automation, but also functional base programming, object oriented programming, the biggest differences, the verbage. So like, I knew what a function was, because in PowerShell, you write functions. But I didn't know, okay, I can write multiple functions and call this function from that function. And oh, by the way, this is maybe considered a method and here's a libraries. Here's what I'm importing, because PowerShell doesn't do that for you. Like, for instance, modules, they're like, automatically imported, whereas Python, it's like, Wait, why isn't this running? Oh, you have to import a module? Oh, you have to call upon this API. Oh, you have to call this method. Oh, like, you need this type of string or so it was like it was very different. And that's because the nature of Python is very developer focused, like you could do automation with it. But you can also, you know, dive into object oriented stuff and all that. So that was really like the big lift off when I started to learn Python. And that's when I was like, Oh, I'm doing software development. Now. I'm not actually I'm not Doing just scripting and automation.

Tim Bourguignon 20:02
And that was, Oh, how did you learn that? Did you go back to books or was just empirical and trial and error? Yeah.

Michael Levan 20:08
So I started at the time, it was a lot of books. And it was a lot of courses. And then after that, I started to just kind of be like, I'm just going to kind of dive in and learn it like now I'm at the point, for example, where like, I don't remember the last time that I watched, like a development course or read a development book, because now it's like, if I have to learn a new language, I'll just, you know, dive into it. And it's, it's all the same stuff. At the end of the day, it's like, oh, this how you could this is how you create a function of this, how you create a variable, but back then yeah, it was like a lot of books, a lot of courses, and then just a lot of taking that and putting it into practice.

Tim Bourguignon 20:41
It's funny, when you realize that the grammar is pretty much the same over all languages, you just have to learn enough of it when you haven't encountered a functional programming before. Then there's there's some kind of mindset, some grammar, you have to learn. How does this concept is articulated? How do you create sentences with this? But as soon as you have that, if you're in one language or the other, you realize, oh, wait, it's kind of the same. Anyone can go very fast from one to the other. You have to get there first. So

Michael Levan 21:07
yeah, the way that I explain it to people, it's like English and Spanish. Hello, is Hello, in English and Spanish is just written a different way. And that's the same exact thing with programming language, like functions or functions, methods or methods. It's just written a different way and called upon a different way.

Tim Bourguignon 21:21
Absolutely, absolutely. So from there on, there was level blend all the way. So not just automation, but really going into development and developing developer tools, I guess. Exactly.

Michael Levan 21:32
Yeah. Yeah. So I was doing a lot of back end development and like developer related tools to help developers do their job easier. That was really where like, my sweet spot was. And then also, I would say, I guess I would call it integrations as well, like creating integrations for different tools and all that good stuff. Yeah, I never really dabbled, even to this day, I never really dabbled too much into like, front end front end or like front end back end style development. It's it was a lot of back end development, a lot of creating integrations, a lot of creating developer tools. So DevOps before the term really existed much. Yeah, exactly. Yeah. So it was interesting, man, because that's what kind of like brought me to the DevOps and SRE space, because I had the infrastructure backgrounds, I already understood systems. I understood how to write code, and I understood software architecture. And then I was just able to combine them. And that's where like the SRE journey kind of took off. Because for me, like, I think SRE is like exactly what Google defines it as. So it's thinking about systems and infrastructure from a software developers standpoint. And so it's like the best of all worlds,

Tim Bourguignon 22:32
which was, how do you all know a little bit differently? You mentioned, you're jumping into a new team now today, and you're basically the one bringing this SRE mindset in there. How would you approach discussing about SRE with developers who haven't really been been talking to that discussion so far?

Michael Levan 22:49
Sure. Yeah. So luckily, it's kind of a pretty easy discussion, because a lot of developers are really used to working with systems administrators and infrastructure folks that don't think about the application, they just think about the system, the uptime, we can't deploy this new piece of code, because the system needs to stay up. And we need to hit our SLA and all that. But when I go in, I say, Listen, I completely understand that's why I'm building the system. And that system could be a containerized application system could be serverless, it could be a virtual machine, it could be an actual system. But the way that I explain it to them as like, when I create this system, I created as Okay, I need to host an application here. And I need to make sure that it's up and it's available and SLAs are met met. But I also need to make sure that it's scalable and efficient in the aspect of I could deploy code to it ended up doesn't go down and break. So I'm constantly thinking about, like, from a developer standpoint, and from a systems administration standpoint, and I feel like a lot of people like that and enjoy it, because it will, it does exactly what DevOps is supposed to do. And that's break down the barrier. That's what I'm doing right. And people don't think about it like that people are like, oh, like, he just thinks about it from both perspectives, but not like I'm going into places and I'm trying to break down that barrier.

Tim Bourguignon 23:57
And you have the feeling that this is growing onto people that more people from the development side are going toward the infrastructure and the in the SRE side. And still it's still staying developers, but acquiring some of your knowledge and releasing some of the pressure from your shoulders.

Michael Levan 24:12
Yeah, I think they are. And I think a lot of developers are doing it without even realizing I'll give you an example. Let's say you're working in AWS and you're deploying an application to, I don't know, Eks, or one of the containerized services. Well, when you're deploying that application, and it doesn't work. You're like, Oh, why doesn't it does, why doesn't it work? Why can't I hit this application? And then you dive into VP C's, and you're like, oh, that's what a subnet is, oh, that's what a site arranges. Or you're like, Oh, hey, why can't I authenticate here, and then you dive into IIM. And you're like, Oh, this is what authentication looks like and stuff like that. So developers that are working on like, I guess I'll call it cloud native applications. They're doing the infrastructure stuff without even realizing it. They're doing the security stuff without even realizing it. Yeah. So I absolutely think that like the two sectors are coming together for sure.

Tim Bourguignon 25:00
And then what is if we had such a team with people able to deploy their their application on AWS to troubleshoot, take some time to troubleshoot what's what's, what's going wrong, etc? How would you define your part of the job? There?

Michael Levan 25:14
Yeah. So the way that I define it is, again, going back to like, what a true SRE is, I define it as, okay, I'm deploying these applications. I'm monitoring them, I could be on call for them, I could be setting up the CI CD for them, I could be containerizing them, I could be pretty much doing anything that Well, I guess, really anything from a systems and development standpoint. So I'll give you a perfect example here. I've worked with clients where I set up their on call solutions for them. And I, I help them understand, Oh, hey, you're getting this alert constantly. Because maybe have a memory leak. Or maybe this API can't be hit at the certain times and stuff. And then I'll go in, and I'll actually, like, fix the code. And then I'll redeploy it. And then it's working, and the people aren't getting the alerts anymore. And again, that's like the true nature of like what an SRE is supposed to be. So I guess you're really doing a little bit of both. And I think the SRE or the the true SRE role comes in, after like an application is kind of already there. So like, the application is there, the backend, the front end folks, middleware folks, like they already wrote it, it's already kind of up. But now they need a way to scale it. And they need a way to automate it. And they need a way to keep it up. And they need somebody that could like actually go in and fix an issue in that application. And that's really where like, the SRA comes into play like that, sorry, is really doing everything. And I don't think that means that we're not going to need back end and front end people anymore. Because it's the same thing is like, you could be an infrastructure person. But we also need security people because people are SMEs in their area, and people are focused in one area. So we're always going to need back end, folks. We're always going to need front end, folks. But we're also always going to need people that can kind of meet them in the middle and like, here's the infrastructure stuff. And here's the development stuff and kind of almost be like that liaison between. Here's the application. Here's the system that it's running on. How do we get it here?

Tim Bourguignon 27:02
Yeah, you want to make sure that that you don't have a wall in between you have somebody going one step further on each direction, and if needed to really, really help out with an entrance light? Maybe? Yeah, what's what the other side is saying?

Michael Levan 27:13
Exactly, dude, 100%. Absolutely agree with you.

Tim Bourguignon 27:16
But you said yesterday comes after the application is created that you come in basically, whenever seeing when the when the proverbial shit hits the fan, and when things are not working correctly, and you're here to fix things.

Michael Levan 27:28
So I think that it actually should come in a little bit before that. So like when I say that it comes in after what I'm thinking is like after an MVP is created. So like, if we're at, let's say, like, we're thinking about it, like purely from a startup standpoint, like this is a new piece of software. So it starts with the CEO, the business focus person, it starts with maybe another founder, and then it starts with a technical co founder. And that technical co founder is creating the application, like actually getting it ready to say, hey, people can actually use this now. And then they go out and they get their funding, and they raise their rounds and stuff. But once that application is ready, and then they're like, oh, okay, how do we actually run it now? Oh, well run it on some easy two instances. And then it crashes all the time, you're like, Okay, now we're actually getting customers and customers actually need to be able to use this application. So we need to be able to scale it and make sure that it's always up. That's where the SRE comes into play.

Tim Bourguignon 28:16
Okay, so first in fixing stuff so that it works. And then I assume and tell me if I'm wrong, was some kind of checklist in your mind saying, Okay, what are we gonna need next? Did we think about security? Do we think about data security? Did we think about scalability? Do we think about uptime? Do we think about how to update stuff, etc? And try to prioritize this and say, Okay, maybe we should hit that. Next and etc?

Michael Levan 28:41
Yeah, absolutely. 100%? Yeah, it's all about keeping the application up and operational. That's really the huge aspect of it is like, is this application running the way that it should be? Is it performing the way that it should be? Is it properly monitored? Is it properly doing the things that it's supposed to be doing? If you have an application and you have 50 users that are hitting it, and everything's fine, and then you jump to 100 users, and everything is bogged down, and it's not working the way it should be? Well, you know, what, that's where necessary, come into play and scale it out and make the application and the piece of software work in the way that it's supposed to? And that's a huge aspect of it.

Tim Bourguignon 29:14
And how much of your job is fixing things, versus helping people understand how to fix it themselves?

Michael Levan 29:21
Yeah. So you're talking like in terms of how much of my job is engineering and how much my job is teaching? Kind of? Yes. Yeah. Okay, cool. So I would say, I'm gonna give you the consultant answer if it depends. Regardless of or it kind of depends on where you are. So like, I've been in consulting engagements where they wanted me to just come in and 100% Show them how something is supposed to work. I've been in consulting engagements where they just wanted me to build the thing and then that was it. I've had consulting engagements where they wanted me and this actually happens a lot. This is nine times out of 10. Are you ever consulting engagements where you go in, you build the thing, and then you teach everybody else how to use and fix the thing. So that's definitely like I would say nine times out of 10, especially nowadays, like 10 years ago, people were hiring consultants, and they were leaving. And that was it. Now, it's like, things are so complex for pretty much no reason. There's, there's so complex that like, you need somebody to build it for you like, and you need somebody to show you how the heck to use it, and how to manage it. So yeah, I would say nine times out of 10. That's, that's really where it lies nowadays.

Tim Bourguignon 30:31
So since you started with consulting, I think you have to to a freelance mode two years ago, and so really consulting awful on your own. That's right. Yeah,

Michael Levan 30:41
yeah. So funny enough, that's actually kind of changing right now to get into that if you want. Yeah.

Tim Bourguignon 30:48
Let's tackle the consulting first and then go there. Why did you go the freelance way?

Michael Levan 30:54
Yeah, so it was one of two things. Number one, I was in like lead director level roles from a DevOps and SRE perspective, and I was, okay, I've gained all of this knowledge. From a technical standpoint, now, I can kind of go do it for a lot of different client, a lot of different environments and a lot of different places. So it was one thing I loved, like the life of being autonomous and kind of doing my own thing. And picking and choosing what I wanted to work on. That was a huge thing. For me, it was like I hated working on things that I didn't want to work on. So it was like, the autonomous life is what's for me. The second aspect of it actually comes from like a marketing and a business standpoint, I always felt like I was making all these people so much money, and I was getting a quarter of it. And I was like, I could do all the work. So why don't I just go make 100% of that money. And that was a big aspect of it, too. I was like, I could do this work myself. And I learned how to sell and I learned the business. And I learned marketing. And I learned all that tough, because if you're for whoever's listening, you're thinking about going out on your own. The biggest mistake I made was, I'm a really good engineer, everybody's gonna know that nobody knew it. I had to learn how to market myself, I had to learn how to sell all of it. Yeah, I had to learn like how to not go to jail if I didn't pay my taxes, like I had to learn the business and the accounting and like that, I had to learn how to hire people for what a good accountant looked like, what a good business professional look like. So yeah, that was a big thing. Like 50% of it was engineering. The other 50% was like, learning how business works and how sales work and how marketing works. Yeah, that can

Tim Bourguignon 32:19
be can be interesting.

Michael Levan 32:22
Yeah, yeah, it's definitely interesting. So you

Tim Bourguignon 32:25
were a consultant for two years. And now you're moving out of that? Why?

Michael Levan 32:29
Yeah. So I would say it was like, even before I like completely went out on my own when I was still working full time. Like, I was, like, still creating courses. And I was like, still creating videos and still writing blogs and stuff. So like, I was still doing like, like the content creation and stuff on my own. Really, the biggest thing that changed was like actually going and hands on consulting for customers and stuff. And now Yeah, so it's changing a little bit. One of the things that I learned about myself, and this is kind of where I'm at right now, it might be different when this episode. But But yeah, one of the things that I learned was, as much as I liked the business, and the sales and the marketing aspect of things, it kind of felt like it was taking over. Like, I felt like I was doing like 30% engineering and like 70% business. And everybody that I spoke to, I was just talking to a friend of mine last night. And I was like, because she's doing something similar, where she's like doing a startup, and she's going out on our own and stuff from that perspective. And I'm like, and she's a doctor. So I'm like, do you feel like you're practicing medicine less now? And she's like, Yeah, I'm way more business focus. Now, one of the things for me is like, I love engineering, I love writing code. I love creating solutions. So I didn't like I don't want to go like 100% CEO like and just where I'm just never doing engineering. Again, I didn't want to go down that route. And I kind of started thinking about this a few months back, I was like, I kind of don't want to go down this route. So. And then I started doing more engineering and like more research related stuff. And just recently, I ended up going full time with the organization that I was doing research and stuff for. And I'm leading their engineering efforts now from a something that we call benchmarks. And benchmarks are pretty much like I explained it to people like r&d. So I'm leading the engineering efforts there for that. So yeah, so it's been interesting, man. And the cool thing is, they're cool with me still doing my own thing. So like, I still consult and stuff and I still create content and all that. So like, I'm kind of getting best of both worlds. Right now. I'm doing both, I'm still able to do the stuff from a consulting perspective. And I'm able to, you know, still dive hands on from an engineering standpoint, and have the opportunity to be able to, you know, lead teams and stuff and be able to do all that and yeah, it kind of came to because at the end of the day, I realized that I'm still very much an engineer at heart. And maybe in 10 years like that might be different and I might want to you know, go full time like creating your company again and really focus on the business and the marketing and the sells out. spective stuff, but yeah, right now it's like I'm still very I still want to be hands on. So. So I like the 5050 split. And that's where I'm at. That's where I'm comfortable with. And that's kind of what I'm doing right now.

Tim Bourguignon 35:11
That sounds like you found your sweet spot or a nice place to be.

Michael Levan 35:15
Yeah, exactly. Yeah, it was honestly, it came a lot from like, like I said, I felt like I was doing 20% engineering and like 70 or 80%, sales and marketing. And I was like, I like it. But I miss writing code, like I miss being hands on. And I also a big thing, too. And I actually just wrote a blog post about this. But I don't want to be like a technical lead, or like a technical manager, or VP, that isn't technical anymore. Like I don't want to try to make my decisions based off of like stuff that I knew 10 years ago, because I think that's a huge, like, a huge knot in a lot of people's careers, where like, they go management, and then they have no idea how to manage a technical team anymore, especially now like maybe 10 years ago you to get you could get away with that. But now, how fast everything is changing. Like you have to stay up to date, you have to say technical, otherwise, you're realistically you're not leading the team, like other people are leading it for you, and you're just managing them. So I don't want to get to that point. And that was like, kind of where I felt like it would go if I kept just doing 20% engineering and 80% sales and marketing and then hiring people to do the engineering for me because I was so focused on the sales and marketing. At that point. I just like I wouldn't be an engineer anymore. And I'm not ready for that.

Tim Bourguignon 36:29
When you create content for your blog for conferences, how do you make sure that this smells like engineering and not like maca?

Michael Levan 36:35
It's a craft band, like it's an art to try to figure that out. Because, because here's the weird thing. And this is, it still irritates me like right now, like I'm irritated thinking about it. If I like create a piece of content that's like ridiculously, like deep into a topic, nobody reads it, nobody watches it. But if I create something that's like super high level, everybody watches it and reads it. I'll give you a perfect example. I created a really in depth article on diving deep into like GitHub actions and deployments and all that stuff. And it got like a quarter of the views that my configuration management versus infrastructures code blog got, like that blog was so high level and totally not technical at all. And it got a gajillion views. And then the one that was super technical did not so yeah, and ears.

Tim Bourguignon 37:29
A good catchy title five mistakes I always make. The sixth one is going to amaze you. There you go with some clicks

Michael Levan 37:37
I created. It's actually really funny because this was like, I think like two months ago, I was talking to my friends about this. And I was like, watch, I was like, I'm gonna create a blog post right now I'm gonna write it, I'm gonna call it five. What did I call it? Like five DevOps trends for 2022. I was like, watch, I was like, watch how many views this gets? Yeah, hundreds of 1000s of views. And my super technical ones get like five or 10,000 views. And that's like, come on guys.

Tim Bourguignon 38:05
Five or 10,000? Right ones? Exactly. So true.

Michael Levan 38:07
Yeah. So I mean, like, in terms of going back to your question of like, how do you kind of figure it out? Here's the thing. And this is the truth of the reality that I had to kind of realize, and that a lot of people have to realize, if they want their content to go viral, and to be a big thing, you're going to have to go really high level, compared to all your other stuff, you can create the super technical stuff, but a lot of your content is going to be beginner and intermediate level stuff. Because the way that I kind of explained it is like the Cisco certifications, right? So like, it actually shows a pyramid. And on the bottom is the CCNA. It's the biggest one. And then all the way at the top, which is the smallest part of the pyramid is the CCIE. And it's a really good representation, the CCIE you're gonna get less people, it's super hard, the CCNA you're gonna get way more people. And it's the same thing with content, your advanced level 400 stuff is gonna get way less views than your your beginner level stuff. And that's because there's way more beginners that need it than advanced people. Because like we were just talking about now where we don't have to go watch videos and courses on a programming language anymore, because we could just dive into it and figure it out. Because we're level 400 people versus the people that are just diving into programming, like they need those courses. So it's yeah, it's tough man, like, but I still do create the advanced level stuff. But at the end of the day, I already know like, I'm creating it just because I want to I'm not creating it, because it's gonna go anywhere, because it's probably not

Tim Bourguignon 39:32
within the I mean, it's the question between the small fish, small pond, big fish, big pond, Oh, you want to place yourself, I'm sure there is a mark market somewhere for a very niche level status. But then you have to drill down your expectation and say, Well, I'm going to have only a few 100 of us, but those are going to be people who have reached this level already. And the Nisha is just not bigger than that. But yet but that's the way it is and that's my expectation, but it's really hard to nail down. Which audience you're shooting for. And how big that is and wicked? What you can get out of it. So yeah, yep,

Michael Levan 40:05
yeah, no, you know, no, it's totally true man. And I'll give you a perfect example of this one of my friends, Adam Bertram, he is he like changed the game. When it comes to PowerShell. He was like one of probably one of the first people that was like hardcore writing about it, talking about it, all that stuff. He got so popular because of it. Like he completely changed the game he niche down, completely changed the game when it came to PowerShell. Now, he's like, because of his popularity, and because of how good his content was. He's running his own digital agency, where he's like, he has a team, so many people writing technical blogs, and he the views that his blog gets are like, absolutely insane, the numbers, but he started it, because he had this niche he niched down. And then once he got this audience, this humongous audience, he started to dabble into other things. And before he created this huge company, that there's still PowerShell stuff around it, but there's a gajillion, other tech topics as well. So point being is, you could start somewhere very niche. And once you have that audience, broaden out, that's exactly what I started, I would say my audience started primarily around Azure and Microsoft related topics. Because when I got when I first started getting really heavy into like Cloud and DevOps and stuff, it was very Azure, or it was very, like Azure focused. Now, my content is like TerraForm, and I sorry, and AWS and GCP. And it still gets views because I built that audience. But in the beginning, like I was super narrow and focus, and then I'd go going in different directions and stuff, which is, which is kind of what you need to do. If you're breaking into the content game. You got to like start somewhere, like real finite, and then you can just branch out.

Tim Bourguignon 41:50
Did you want to go broader? Or did it just happen?

Michael Levan 41:54
I did, because for me, like, it started out in my first job. And I was always trying to do new things. And I was always trying to play with new stuff. And I always I've always had shiny object syndrome. This is something that just has never gone away. So like I always wanted to be general and talk about several different things. But I couldn't in the beginning, because in the beginning, I needed to be known for something like I needed to be the guy for something. And then once I was the guy for something, and I had the following. At that point, I could broaden out and talk about a gajillion different things.

Tim Bourguignon 42:24
Now that makes sense. That makes sense. Makes sense. What is the maybe not the best, the most helpful advice you've gotten into your career, you've been in many directions, you diverge many times, you faced decision points, cetera. I'm sure there's a couple advice in there that really changed your views or your game.

Michael Levan 42:42
Yeah, so it's probably cliche, but I think it was the biggest thing for me. Don't listen to toxic people. And you're gonna see that a lot throughout your tech career, like there's going to be managers. And there's going to be engineers that are so toxic, because they want to hold the keys to the castle constantly. They want to be the smartest people in the room, because they're, they have really bad egos. And if you let your career be driven by those people, because those are going to be the people that tell you not to do things, those are going to be the people that tell you that you don't have the experience to do it. Right. Because they don't want you to know, you can get the experience and you can be better than me. They don't want you to know that though. So I would say the biggest thing, the biggest piece of advice is do not follow talk to people like follow what's in your heart and follow what you want to do. I promise you it's not going to always be right. I've made way more mistakes than I've have great decisions. And that's just everybody. That's just what happens. But yeah, don't listen to the toxic people always follow follow your gut and follow what you want to do. That's like the biggest piece of advice I could give.

Tim Bourguignon 43:46
Amen to that fully. Thanks. So Michael, where would be the best place to continue Austar discussion with you?

Michael Levan 43:55
Yeah, absolutely. So you could follow me on Twitter. It's at the NJ DevOps guy. You could connect with me on LinkedIn. It's just Michael Yvan. And then you can also check on my website. If you want. It's just Michael, Yvan dotnet. Those are the three best places and I'll

Tim Bourguignon 44:11
add all three links to the show notes. Thank you very much. It's been awesome listening to your story. Thank

Michael Levan 44:16
you. Awesome. Thanks, dude. Really appreciate it.

Tim Bourguignon 44:19
Oh, likewise, always miss Bader and this has been another episode of therapists journey. We'll see each other next week. Bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms to show appears on our website, Dev journey dot info, slash subscribe. Creating the show every week. Takes a lot of time, energy, and of course money. Would you please help me continue bringing out those inspiring stuff? Every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally, don't hesitate to reach out and tell me how this week store is shaping your future. You can find me on Twitter at @timothep ti m o th e p or per email info at Dev journey dot info. Talk to you soon