Episode 184

Last updated Sep 4, 2022 Edit Source

Welcome to episode 184 of the Nerd Journey Podcast @NerdJourney! We’re John White ( @vJourneyman) and Nick Korte ( @NetworkNerd_), two Pre-Sales Technical Engineers who are hoping to bring you the IT career advice that we wish we’d been given earlier in our careers. In today’s episode we share part 2 of an interview with Michael Levan , discussing Michael’s career from systems administration to DevOps engineering to SRE to business owner.  Michael also shares some tips on learning and building skills. 

Original Recording Date: 07-15-2022 

• Michael Levan Michael Levan focuses in the cloud native applications space, focusing on Kubernetes and containers.  Remember to check out Michael’s podcast, Kubernetes Unpakced Kubernetes Unpacked on Packet Pushers.  Find Michael on Twitter ( @TheNJDevOpsGuy), and catch part 1 of our interview with Michael in Episode 183 Episode 183. 

Topics – On Titles and Focus Areas, Finding Your Pace, Dive Deep, Enjoy the Process, Reasons for Starting a Business, Finding Stability, Talent Cycles and Parting Thoughts  

=========================== 

• Michael started his IT career as a systems administrator, working in #ActiveDirectory, Microsoft #Exchange, and #WindowsServer.   

• He learned #PowerShell and began to focus more on automation technologies and techniques.   

• Michael remembers writing his first PowerShell script to help get information on Hyper-V virtual machines. 

• In learning more about PowerShell, he learned more about Python.   

• That led him into more of a #DevOps / #SRE (site reliability engineer) / cloud engineer type role.   

• Michael feels it is easier to move from infrastructure to development than from development to infrastructure.  In development there is a ton of infrastructure and networking. 

• Michael has also held some software developer roles while working in the DevOps / SRE spaces and did consulting. 

• The consulting is something he continues today, primarily writing in #Go Go and #Python sometimes. 

• His career went from systems administration to starting to understand automation to combining both into the SRE / DevOps role and then doing different things in the orchestration and container space. 

• Michael doesn’t care for titles.  If everyone could be called an engineer our lives would be better, but titles get aligned with pay scales.   

• What about the difference in the SRE and the infrastructure engineer? 

• An infrastructure engineer worries about the overall architecture - where something is running and how the systems run. 

• The SRE is taking all of these things into account but also focusing on heavy observability and monitoring to make the architecture that is being deployed repeatable. 

• The SRE is more focused on the automation and repeatability of things, but Michael has not seen an infrastructure job in a while that didn’t require some kind of configuration management / automation tooling like Terraform (or even a scripting programing language) as part of it.  

• Michael does not see a big difference in a DevOps Engineer and a SRE these days.   

• There is a difference between a build engineer (who focuses on CI/CD) and SRE, but you don’t see a lot of plain build engineers out there. 

• At the end of the day, there are people who focus on code, people who focus on infrastructure (wherever it may be), and then all of these people are focused on both at the same time (i.e. each one needing the other). 

• John points out a difference in speed of development cycles each of these different roles may support.  A traditional infrastructure engineer may support slower cycles than that of a DevOps Engineer or SRE.   

• The availability requirements of each will be different.  Maybe a SRE / DevOps Engineer measures this in minutes per month as opposed to looking at longer maintenance windows. 

• Michael says there are roles within organizations that have not adapted new standards (healthcare, government, etc.) and operate more on the waterfall model (slower to make changes and not as frequent). 

• Michael was at a government job for a while as a systems administrator but felt the pace was too slow.  

• If you happen to be in one of these slower paced roles and want a faster pace, one suggestion is go to a startup and try it. 

• In the slower paced roles when people get laid off, trying to get into a fast paced job market can be quite challenging.  Nick suggests trying to incorporate some type of automation technologies into what you are doing even if in small steps. 

• While at the government job, Michael spent his time trying to automate things as much as he could.  The extra time he was allowed to learn gave him a chance to build skills for getting the next job. 

• John suggests the traditional developer’s path is from a computer science degree or perhaps some coding boot camp.  The infrastructure engineer has a built in way to get closer to the development side of the house through what we used to call scripting. 

• John has fumbled around playing with Python quite a bit and then heard about the idea of clean code (focusing on code readability), which became a little overwhelming. 

• He wondered if he was learning it the right way and had trouble seeing the iterative path for someone coming from an infrastructure background. 

• Michael says everything makes sense when you dive as deep as you possibly can into it. 

• If you take an hour to learn about Python and then try to dive in head first into more and more content it is probably not going to make a lot of sense.   

• Michael suggests taking a free YouTube course (for example), and then go and apply the learnings.  Then go take another one and do some application of it (i.e. build a small app, a game, etc.) until you have learned the language basics. 

• Once you understand a language, many of them blend together. 

• Programming is giving a computer a blueprint to go and do a thing. 

• Once you fully understand a language, things like test-driven development, clean code, etc. are going to make sense.  

• People tend to take a 1 hour course, dive in, get confused, and lose hope.  Take the time to go deep a little at a time until you can get into the more advanced topics. 

• Nick suggests this is encouraging people to go down the rabbit hole of learning, but how do we know when to come back out? 

• Michael says this is based on experience.  There are noteworthy differences between engineers at different levels. 

• A junior engineer is fixing bugs and trying to figure out what technology is in the first place. 

• A mid-level engineer may be working on a feature or two in the code. 

• A senior level engineer may be building an application. 

• A staff / principal level engineer is architecting the application. 

• Once you get to a certain experience level, played with different tech, worked on various platforms you can see when you might be getting off track and too deep. 

• For the junior and mid-level engineers, if you keep buying more and more courses and are not learning anything new, that is when you should realize you are ready for the next level. 

• Take the beginner / intermediate level courses from various sources.  Each will teach about the same things in different ways.  Then go to the next level when ready. 

• John says when he learns, the best way is by doing a project,  which drives him to keep going.   

• There is a big jump from working on infrastructure things to maintaining a code base, for example. 

• Once you work on a project that motivates you, you want to do it right.  This can drive you into over analysis, a conflict of wanting to learn the language but build in the optimal way. 

• Until you have done things and realize at the end you didn’t do it optimally or that you need to make a change, you won’t learn it a subject at the level of depth that an experienced engineer has. 

• Michael would argue there isn’t a right or wrong way to do something in the beginning. 

• Most of the developers Michael has worked with have their own set of processes, preferred standards, tooling for interactive development environments (IDEs), how they bring in packages, how they do versioning, etc. 

• It seems like there are far less bad practices than people think. 

• When getting into something for the first time (like a programming language), enjoy the process. 

• We are so focused on getting to the end state, knowing it all, etc.  We don’t enjoy the process. 

• “Mess up.  Go a year messing things up…and learn from that process.  That’s the only way to do it.  The only way to be truly great at something is to fail far more times than succeed.” - Michael Levan 

• Michael has a cousin going for a masters degree and asked  about data science as an option (lots of money in it).  Michael’s advice is doing get into tech if you don’t enjoy it. 

• If you’re so focused on what needs to be great in the outcome, you are almost missing the point of why you are doing it in the first place.  If you take the time to go through the process and be truly great at it, the outcomes will be there and so will the learnings. 

• If you start from this context point, perhaps the setbacks don’t feel like setbacks (i.e. setback on a project is a step forward on a learning journey).  It’s hard to conceptualize this until one takes a step back. 

• This is arguably one of the most challenging things you will do.  Michael sometimes finds himself in a state of just wanting to get something finished rather than enjoying the process. 

• Michael is practicing what he preaches but has faults just like other humans. 

• You can take yourself to the next level once you start to catch this feeling / realize it has happened to you. 

• Once you can start to realize you are thinking about the things we’ve discussed on the show today, that’s when you know you have taken yourself to the next level. 

• You’re not going to be able to do any of the things discussed and be perfect. 

*“We are humans.  We will mess up.  We will constantly fail, but the difference is if you fail, are you willing to get back up?  If you are, that differentiates you from 90% of the world.” - Michael Levan 

• If this was easy it would not be worth doing.  If it was easy everyone would be successful, but it’s not easy. 

• Michael describes the reasons for going out on his own. 

• He is very opinionated.  Michael shares the scenario of working on something extremely important to the business but being directed by management to change direction and focus on something of lesser value “because it’s your job.”   

• Michael hates the feeling of being told not to do something that is driving value. 

• Working for himself allows Michael to work on the things he wants to work on and which he also knows are generating value. 

• Working for a company means you are working on things because you have to do it. 

• Michael does not like putting his fate in the hands of others. 

• Many feel having a full time job is more stable. 

• Michael would argue this is less stable than going out on your own because: 

• You are putting your fate in the hands of another team like sales, marketing, or the CEO of the company for which you work.  If the company has layoffs or goes under you may have done nothing wrong and could still lose your job. 

• Getting a consistent paycheck makes you feel like all is well, but one day it could all go away.  Then what do you do if that was your only source of income?   

• When on your own, if something goes wrong, it is likely your fault.  You can learn from it, adapt, and change.  It’s all on your shoulders, which is a phenomenal thing. 

• When working on your own, you have multiple income streams.  If something goes away (depending on size of client, etc.), there are multiple other things on which you can fall back (other clients / ability to get more clients). 

• If Michael is working for another company, they have every right to tell him what he can and cannot do as it relates to giving a conference talk about a specific subject, if he can go and tinker with a new technology, when he can take off work, etc. 

• Michael is a passionate technologist and doesn’t want someone else telling him how to live his life. 

• The paycheck is a false sense of stability.  You are only as stable as the rest of the employees at the company.  If they are not doing their job you aren’t very stable at all. 

• John mentions humans are bad at judging risk.  We don’t often want to face what is risky. 

• You can see a business is in trouble from the outside, and people within the business may not want to acknowledge it.   

• Perhaps if you are going to work for a company, one should have a way to measure and assess the risk to the company’s longevity and health in a negative way. 

• Think about working in technology in the travel industry during a pandemic, for example.  The business could be in trouble because no one can spend money on travel. 

• Another scenario is a business that makes a majority of its revenues within a specific region of the country and then that region experiencing a natural disaster. 

• John explains how diversifying revenues across client bases and geographies can be a benefit compared to working for a company directly as an employee. 

• Michael believes there is a middle ground.  If you’re working for a company and did not sign a moonlighting clause, legally you can moonlight (i.e. cannot be fired for it). 

• Many companies are ok with employees doing side work.  For example, Michael knows people whose company supports their decision to build courses on top of their day job. 

• But if you are doing side work, how much time do you really have to do it if you already have a full time job? 

• How can you truly diversify without working 15 hours per day? 

• It depends on the job and the workload as well as the industry you’re in. 

• Michael feels he is more stable working for himself. 

• He has funds in the bank for a rainy day for one thing. 

• Next phase is equity in his house. 

• He also invests in stocks and other areas. 

• Michael is very particular about his finances and prepared for times without income if things happen that way. 

• Before going out on his own, Michael was moonlighting to some extent.  It was not that he had a full time job, quit, and then became successful. 

• There were a number of bad months and a lot of uncertainty. 

• He bounced back and forth between working for a company and for himself before becoming stable. 

• Michael was very poor growing up.  Going through the transition of not making money for a while wasn’t extremely damaging to him as a result. 

• Some of this is about mindset.  Think about the person who grew up in a family that was extremely financially stable.   

• Going out on your own and not making money for a couple of months could really sting compared to someone who grew up used to not having money. 

• It also depends on how bad you want it.  Michael knows what he wants out of life and how to get it.  There are going to be times when he doesn’t make any money because things will not always be peachy. 

• There are so many factors that go into a decision like this. 

• “Everything is always moving.  And you have to be moving with it.  Otherwise, be prepared to fail.” - Michael Levan 

• Success doesn’t just mean money. 

• You never make enough money.  Michael has had months when he made nothing and others where he made someone’s entire salary. 

• Michael encourages us to look at success about how you feel and whether you are prepared for life. 

• Michael shares a quote from the movie Rocky Balboa - “You, me, or nobody is gonna hit as hard as life.”   

• See also this video clip to hear the clip in context of a conversation between Rocky Balboa and his son.  

• This is the uncomfortable reality of success. 

• John points out we may not yet have the skills to be valuable enough to go on our own, and this means we need to go through the process of gaining more skills.   

• It’s not just flipping a light switch and you’re there. 

• The first two times Michael tried to go out on his own he failed miserably, blowing through a large amount of savings simply because he did not have the skills. 

• Michael was not valued enough in the space to consider himself an independent consultant.   

• You have to build yourself to a certain point.  However, you don’t know you’re there yet until you give it a shot.  Michael learned quickly the first two times he was not ready. 

• If you do give it a shot make sure you are in a good situation.  The first time Michael tried going out on his own he was not in a good financial situation.  The second time he was in a good financial situation but because he was not ready blew through his savings. 

• In today’s tech world being up to date on your skills makes it incredibly straightforward to find a job. 

• Michael reads almost daily about the number of engineering jobs available being higher than those who can fill them. 

• It’s easy to say “I’ll be fine.”  If you always have in demand skills you will always be able to find something. 

• The way to de-risk the process is to stay up to date with your skills, which takes time and effort.   

• The cycle can be too many jobs and not enough people, but sometimes the cycle is too many people and not enough jobs. 

• If a people shortage is happening in the industry, maybe that is a good time to test yourself in going out on your own. 

• John compares this to a powerlifter getting into peak performance and shape, timing it just right so that a safe test can be conducted to determine if more training is needed. 

• The key thing is you have to do it to know.  If you never try to go out on your own, you will never know you’re ready.   

• There’s always a balancing act to remember. 

• There is no way to know if you’re ready to go out on your own until you give it a shot.  That can be scary, but so is staying at a company too long. 

• Nick says we’ve come full circle not only from a fitness standpoint but on the learning topic. 

• It’s like the balance is the mindfulness of the feedback loop you should constantly put yourself through. 

• Michael says all of this stems from deep work and the formation of habits discussed in previous parts of this interview. 

• What you’ve heard on the show is achievable by every person in the world.  The only thing stopping you is you. 

• Michael references a video clip of Steve Jobs from the 1990s. 

• There’s a path we all follow from birth to death (school, job, family, death). 

• Once you poke life and realize something can pop out the other side, you can’t go back to a former way of thinking. 

• We are extremely lucky to be here.  Michael cites a 1 in 5 billion chance that a sperm fertilizes an egg leading to the birth of a human. 

• If you have a 1 in 5 billion chance at life, there should be no reason to have a defeating attitude (i.e. say “I can’t do this”). 

• Michael tells us there is no excuse that should keep you from going and being successful. 

• Michael feels very fortunate to have turned out as he is today based on his childhood. 

• We have short life spans on this earth to build something.  And inside that, you might have 30-50 years if you are lucky to really do something, which is not a lot of time. 

• If you are going to do something, you might as well just go and do it because we are humans (and likely all take that for granted).  You can shape your own reality. 

• Find Michael on Twitter ( @TheNJDevOpsGuy) or LinkedIn. 

• And remember to check out Michael’s podcast, Kubernetes Unpacked on Packet Pushers. 

• Episodes mentioned in the outro: 

• Episode 181 Episode 181 with Bill Kindle and the burnout story 

• Episode 19 Episode 19 - process over outcomes 

Contact us if you need help on the journey.