Episode 060: Operations Anti-Patterns with Jeff Smith

Mike Pfeiffer on January, 29, 2020

In this episode I catch up with Jeff Smith to discuss his new book called “Operations Anti-Patterns: DevOps Solutions” from Manning Publications.

Jeff Smith has been in the technology industry for over 15 years, both as management and individual contributor. He has managed DevOps transformations at Centro, an ad-tech firm, and Grubhub, an online ordering platform.

Win a free copy of Jeff’s new book Operations Anti-Patterns: DevOps Solutions:

Full Transcript:

Mike Pfeiffer:
All right, everybody, welcome back to another episode of CloudSkills FM. Really excited to have you here today. Appreciate you tuning in. And I’m also excited to have today’s guest. It’s Jeff Smith. Jeff has been in the technology industry for over 15 years, oscillating between managements and individual contributor. He currently serves as the director of production operations for Centro. And one of the things Jeff’s working on is a book through Manning, so Operations Anti-Patterns with DevOps Solutions. Jeff, welcome to the show.

Jeff Smith:
Thanks for having me.

Mike Pfeiffer:
Yeah, it’s great to have you here. And I love the title of the book, the content, the topic. And so I would love to hear what sparked the idea to write the book, and then maybe we can also get into your background, how you got to this point, why you’re doing this book, all that kind of stuff.

Jeff Smith:
Sure, sure. I’m glad you liked the title too. There’s a lot of blood, sweat and tears. I never realized how difficult creating a book title could be. But I originally got in touch with Manning… Yeah, I don’t know, maybe like seven or eight years ago. I was doing a lot of work in puppet, and they approached me to write a puppet book. Unfortunately, at the time… Well, not unfortunately, I just had a kid, and it wasn’t the best time to say, “Yeah, I’m going to take on another crippling challenge.” So then fast forward a few years, I wrote article for CIO magazine and another one of the Manning editors saw it and said like, “Hey, I loved your DevOps article. Would love to talk to you about perhaps writing a DevOps book.”

Jeff Smith:
And it’d been something I’ve been noodling on in the back of my mind for a little while anyways, predominantly because I felt like a lot of the source material there spoke to a particular group or type of infrastructure team or development team. There’s a lot of preconceived notions about where you were at already in terms of your organization’s journey. A lot of it had sort of a Silicon Valley bend to it. So I wanted to write something that was for the folks that are maybe a little further behind than the typical audience of these DevOps folks.

Mike Pfeiffer:
I love it, man, because it seems like that’s the most people… It seems like [crosstalk 00:02:26]. Yeah.

Jeff Smith:
Right, yeah. We get caught up in this echo chamber… I do a lot of public speaking, and you get caught up in this echo chamber, and you think everyone’s running Kubernetes, everyone’s in the Docker and it’s like, “No, that’s not the case at all. There’s a lot of people running bare metal, there’s a lot of people that spend two hours in change management meetings.”

Mike Pfeiffer:
Absolutely.

Jeff Smith:
These are all very real things. So I really wanted to write a book to those folks and say like, “Hey, you can make these changes.” And the other thing I wanted to do was write a book to the individual contributor or the middle-level manager knowing that there are things that you can do that don’t require the C-suite to be pushing this DevOps transformation. Granted, it’s a lot more effective, it’s coming from the top, but there are plenty of things that you can do to make your life a little bit better that you can implement on your own.

Mike Pfeiffer:
Yeah, awesome. Yeah, I agree 1000% with what you said. It’s easy to get caught up in the hype these days. And I’ve found myself lately just trying to remind people of the fact that, yeah, the highlight reel is social media and grounded. One of the things that I was noticing as going through your bio is that you were previously a Site Reliability Engineering manager at Grubhub and that’s a topic in our community that’s been coming up a lot like, “What’s the difference between DevOps and SRE?” I wonder if you can shine a light on that for us as we get into this.

Jeff Smith:
Sure. There’s a lot of people that are going to disagree with me, so feel free to send your hate mail on Twitter. But for me, Site Reliability Engineering is really a different approach to how we typically think about operations. And specifically it’s about getting involved with application-level code and giving guidance around how that code can be more effective and more resilient in a production setting. And that’s something that in a typical DevOps operation, that exchange may not happen or there may not be an explicit job responsibility for that.

Jeff Smith:
But for me, a site reliability engineer is someone that is working hand in hand with devs, not just in operating their software in production, but working with them to say, “This is how we can make it more efficient, this is how we can make it more resilient, coming up with actual different development techniques and approaches to leverage that and make that a bit more robust.” DevOps to me focuses more on that relationship between Dev and Ops and making sure that developers have the tools necessary to do their job effectively, but also that there’s the shared sense of responsibility for the production infrastructure because for so long production has been the purview of operations. And a lot of devs have no idea what their code looks like in production at all. They have zero visibility into it.

Jeff Smith:
So for me, DevOps is more focused around breaking down those walls and making sure the developers have the tools. Because to be perfectly honest, in a lot of shops, developers aren’t that in touch with production because they don’t really have access to it. They can’t see it, they can’t touch it, they can’t manipulate it. So, of course, you’re going to take a back seat to that when your situation is set up like that. So DevOps really focuses on empowering both groups to be more effective.

Mike Pfeiffer:
I’m glad that you said that because that’s a major problem that I’ve noticed over the last couple of years of working with IT teams because the teams that we’ve worked with, going back to your earlier point, they’re not mastered level of DevOps practitioners. They’re getting into it for the first time. And to what you just said, I always have noticed that where the developers don’t really get to see what’s going on in production, and then there’s this expectation that you just deploy to this black box and it’s going to work out perfect. That’s setting you up with the expectation of like it’s unpractical, right?

Jeff Smith:
Right, right. Spoiler alert, I have massive imposter syndrome. So the fact that I’m writing a book doesn’t cure me of that. And I think one of the things early on in my career that I learned coming from the Ops side of things was that in my mind, I thought developers knew everything and anything about computers. I thought because they were writing code, of course, they know about networking, of course, they know about DNS, of course, they know about security. And that’s just not the case.

Jeff Smith:
And again, going back to what we were talking about, level setting, like on the internet, you read these guys like Aaron Patterson or Brendan Gregg and you’re like, “Wow, this is what developers are like.” No, that’s the top echelon of developers. Your everyday developer doesn’t have time to learn the ins and outs of DNS because they’re learning the newest JavaScript framework or whatever it is.

Jeff Smith:
So I think in a lot of ways as operational professionals, we put too much onus on developers and what their knowledge that is, and at the same time downplaying our own expertise because we don’t take the lead and say like, “Hey, this is my area of expertise. Running code and production is something that I am actually probably better at than you.” So I think that contributes to that scenario of, “Well, why don’t devs just know this?” Well, they don’t know because they’ve learned 52,000 other things that they had to do to do their job on a daily basis.

Mike Pfeiffer:
Yeah, it seems like a big part of all of this and being successful is just simply putting yourself in the other person’s shoes sometime and looking at it from their view. But I’d like to switch gears just a little bit because I love some of the stuff I’ve been seeing in your book so far. I know that it’s like an unManning preview right now. So people can start consuming the book, but you have a chapter called The Paternalist Syndrome, and you get into the concept of gatekeeping and how much that can just slow you down, eliminating gatekeepers and some of the things to think about through there. And I would love it if you could maybe talk a little bit around that today on the show.

Jeff Smith:
Sure.

Mike Pfeiffer:
[crosstalk 00:08:20] get a huge problem that most of the people listening are probably running into.

Jeff Smith:
Yeah, so gatekeeping is a huge problem in the industry. And just to level set for folks now, gatekeeping is basically this idea that there is this artificial barrier between you and something that you need to do, a literal gatekeeper, in order for you to either deploy code or move along in a process or something to that effect. And some gatekeeping isn’t necessarily bad. Like when we’re talking about a PR review, sometimes it’s good to have someone in the middle reviewing your code, making sure that things look right and that people understand it. But then there’s the unnecessary gatekeeping, where you are preventing me from doing a particular task that is necessary important just so that you can give your undo stamp of approval.

Jeff Smith:
So one of the big things we talk about is change management. In a lot of organizations, change management is the biggest gatekeeping process. And a lot of times it’s not adding the value or reducing the risk that teams think it is. So a common story when I talk with folks is they submitted change management requests to make some change in production. They’ve done the change 100 times. We know the expected outcomes of it. It goes in front of this change management review board, people that are not really connected with the process or making the decision if this is safe. And then ultimately, they go back to the person that initiated the request to say, “Hey, is it okay if we do this?” Well, yeah, it’s okay. That’s why I made the change request. So how much time are we losing in that cycle doing nothing?

Jeff Smith:
So what I talk about in the book is advocating for this idea of how do we codify the things that we are concerned about, where we have gatekeepers, and how do we create digital signals so that we can have automation around that? So change management is a perfect example because when we’re looking at change management, we’re worried about risk of failure, we’re worried about what the rollback process looks like, we’re worried about how do we ensure that this is going to work successfully. We can do that through automated testing. We can do that in lower environments. And each of these things can create a signal that says, “Yes, this is okay to do.”

Jeff Smith:
So an example is in our company at Centro, we’ve created a system that basically when you deploy to production, you can only deploy from one particular repository. And in order for code to get into that repository, it had to go through staging testing and then promote it. In order for it to go through staging testing, it’s got to go through an automated build process where there’s a bunch of automated test scripts that have run against it. But after you’ve done all those things, now the deployment is really just a matter of like, “Yes, we’ve checked all the boxes for everything that we need to do, now we can just deploy.”

Jeff Smith:
And if we’re setting up our deployment process so that it’s a safe process, there’s a lot less concern about when we go about doing it because we know it’s something that we do regularly, we feel comfortable about it, and everyone knows what the expected outcome is and what the potential failure points look like. And when you have a repeatable process, people become much more open to the idea of it breaking free of the gatekeeping process.

Mike Pfeiffer:
Got it. Yeah, I think that really helps. One of the things that you mentioned or touched on there that I think is fascinating and also saw something about this in the book that hasn’t been released yet is you have a section on automation. And then you talk about the value of automation, but also the arts of automation. And I’m wondering if you see this pattern in the field, especially you’ve worked for so many places and-

Mike Pfeiffer:
Pattern in the field, especially you worked for so many places and have been in the field and working with teams and managing teams. Does it seem like people sometimes get stuck thinking too analytically and there is not enough of the creativity and experimentation? Because what I’ve found is a lot of times, are we supposed to check all these boxes or am I supposed to be doing it like Centro where I have these different phases to go through? Does it seem like people are getting stuck or they need to maybe experiment more and then find ways to add value and not worry so much about all the checking the boxes and all that kind of stuff?

Jeff Smith:
Yeah, I agree. People are getting stuck and they’re in analysis paralysis. Right? They’re at this mode where they are thinking if I don’t automate everything from beginning to end, it’s not worth doing. And there are plenty of small steps along the way that you can automate to build confidence in. Right?

Jeff Smith:
So for example, let’s say the start of your process is you have to log in and run a sequel query to get a bunch of different values. Right? You could write a script to automate that portion of it. Right? Build a little momentum in that and it’s not a huge savings, but still if you’re saving 45 seconds per execution, over time that starts to add up. The other thing I talk about is, in the book is when you’re doing automation, it doesn’t have to be that I type a command and then I walk away and at the end it’s complete.

Jeff Smith:
You can have different phases of automation based on your confidence level and what it is you’re doing. So you can have a phase where it says, all right, this script is going to run and it’s going to run a simple stupid query and it’s going to give me the result. Now I’m going to use that result as the input to the next phase. If I feel confident about that, I can just have the next phase execute on its own.

Jeff Smith:
If not, I could prompt the user and say like, “This is what I think is the right answer to move forward. Should I move forward?” If it’s correct, you hit yes and continue on. If no, you bail out and you do something manual. But there’s all these small steps that you can do along this automation journey where you build up this suite of automation and then before you know it and you’re like, Oh wow, we’re ready to turn this on from beginning to end.

Jeff Smith:
So I would say don’t get caught up on having a complete automated solution. Build it up over time, build confidence. Start with the easy stuff. In the book I talk about task complexity where you’ve got simple tasks, you’ve got complicated tasks and you’ve got complex tasks. Right?

Jeff Smith:
A simple task being I do steps one, two, three. Right? In order. Then there’s complicated tasks where, well, my inputs will change the thing that I do. Right? So those things are still reasonable in your mind. You can pick them out, but they’re not as easy as just one, two, three. Right. Now you’ve got a branch tree. If the value’s less than five, do this. If it’s more than five, do that.

Jeff Smith:
Then you’ve got complicated tasks, things like database tuning where it’s like, well the answer is it depends. Right? Those are the things you should shy away from. Start with a simple task, move onto complicated tasks and then who knows? Maybe you never get to the automating the complex tasks, but that’s not a loss. Right? You’re still gaining value out of automating the simple and the complex.

Mike Pfeiffer:
Yeah, it’s an investment, right? The front end of it may be a little bit of extra work to get it going, but the payoff long term could be massive if you get something automated, even if it’s a small thing, to your point.

Jeff Smith:
Right. And I think the thing that we learn is no one is ever happy with the technology that they’ve got. So you’re going to continue to build on that. Right? At first it’s going to be amazing. And then three months later it becomes standard and you’re like, well why doesn’t it do this? And you need to build on that.

Jeff Smith:
A perfect example is again at Centro, we used to have a environment creation requests where people would say, “Hey, I need a new integration environment.” And it would take a week and a half before we got the request, process it, got the environment up and running. Once we automated all of that the environment creation takes 30 minutes.

Jeff Smith:
Fast forward a year and a half, 30 minutes is too slow. Right? So it’s like, well, it was a week and a half not that long ago and now you’re complaining about 30 minutes. So people just adjust and you just got to keep iterating.

Mike Pfeiffer:
It’s a good underlying though to all of this because it’s easy to focus on the downsides or what you’re not getting out of it. But a lot of people need to shift that focus on because it is continuous delivery and continuously trying to add value. And if you’re just focusing on what’s not good, you get stuck on that. Right?

Jeff Smith:
Right. Yep. Yep.

Mike Pfeiffer:
So one of the sections in your book also that I’m really excited to read is you have a part two in the book that it looks like there’s about three chapters on culture, in which I think for folks that are paying attention in this space is usually one of the hot buttons. Right? Because if you don’t have air cover from leadership, doing all this cross functional work between teams and stuff is very hard to accomplish. I would love to get your hot take on culture and how it fits in to this world of the doing DevOps and implement these new patterns a lot of companies have never really done before.

Jeff Smith:
Right. So I’m going to give you an inside scoop on the book writing process. The culture part originally was at the very beginning of the book because I think it’s so important and I think it’s front and center. But Manning, being a technical publisher, they were like, “Well maybe we can start with a bit more technical stuff in the front and then get to the culture.”

Jeff Smith:
But I agree, culture is so, so important and I really wanted it front and center. The reason culture is so important is because believe it or not, with all of the new tooling and all of the cloud automation and all of that, at the end of the day, really the hardest problem that we have in our organizations is people. Right? It’s talking with each other, it’s communicating with each other. Because guess what? Docker isn’t going to solve the fact that your incentives are misaligned. Right?

Jeff Smith:
Docker is not going to solve the fact that ops is measured by uptime. Right? And stability where development is measured by pushing features out as frequently possible. So the culture piece of it is huge because one, you need to create an environment where dev and ops can talk to each other. Right? And they can work towards a common goal. And I think that comes with some shared responsibilities. Right?

Jeff Smith:
There needs to be some ownership on uptime with dev just as much as it is with ProdOps. The other part of that though is, like we said, aligning the goals and the incentives for what people are striving towards. But without that alignment and without that open communication, no technology that you implement, is going to solve the thing that’s really rotting your organization from the inside. So when I was at Grubhub, before everyone bought into the DevOps thing, I was doing very small guerrilla stuff to build that trust and that dialogue between operations and development.

Jeff Smith:
Simple stuff. Just like, “Hey, I know that you guys made a request to me to do this thing because I have access, but how can I get you guys to be able to do it yourselves?” Right? That builds trust. That builds credibility. Not to constantly lecturing anytime someone needs production access, but instead understanding, well why do you need production access? And how can we get this to you in a way that’s safe?

Jeff Smith:
Part of it is explaining. Right? Because most developers have never gone through an audit. Right? So they don’t really understand why it’s not okay for you just to put their SSH keys on the prod box and they can hop in whenever they want. So really having those conversations. And you said earlier, and I couldn’t agree more. Empathy is at the epicenter of all this I have to be able to empathize with the people around me and the people that I interact with. And understand what is it that they’re going through? What is it that they’re trying to accomplish?

Jeff Smith:
So that’s really what the culture chapter talks about. But without someone there, I refer to them as the culture champion in the book. Without someone there taking this and saying, “Hey, we’re going to change the way we interact with each other.” I don’t think a true DevOps transformation is possible. You’re just going to have cooler tech with the same old arguments.

Mike Pfeiffer:
Totally man. Cool technically, high bills for a cloud computing [crosstalk 00:20:17] Yeah. It’s so true man. And I think that you mentioned that should have been the first part of the book, which I agree with. But I understand having to hook people with the technical side.

Jeff Smith:
Yeah.

Mike Pfeiffer:
I would’ve loved to see that first too. But because I understand from the stuff that we’ve struggled with that that is the crux of the issue most times. And I think the common question starts to become from people when you start telling them about this is well, how can I start to do this from the inside? And you mentioned a little bit of just questioning and not pushing so hard.

Mike Pfeiffer:
There’s the element of people having a strong ego and not wanting to give up access, so that’s an issue. But is there a way for people to get their leadership on board with this way of thinking to help the teams play nicer with each other? Or is that a hard thing to pull off?

Jeff Smith:
It depends on the leader. Right? Some people are entrenched in their positions, others are more open and receptive to it. Part of it I think is just demonstrating the value of this better communication. So for example, there were a lot of things that my team was responsible for at Centro when I first started. And when I said, “Hey, when these guys make this request for X. Right?” A perfect example is there are scripts that they need to run to potentially correct bad data in production. Right? So normally that would be a request made to my team.

Jeff Smith:
It would sit in the queue, we would finally grab it, we would run it. We wouldn’t really know what the output meant, but we would just copy and paste, like, “Yeah. Hope it worked, it looks good.” And then they would tell us whether it’s okay or not. Right.

Jeff Smith:
The idea of us policing whether this was a safe script or not, didn’t make sense because we didn’t have the expertise to actually do that. So we’re like, well, we’re not adding any value here. Right? We’re in the process. This request has queue time of about two days. So for two days it’s just sitting there doing nothing, waiting for someone to get to it. Then it takes five minutes to execute and I don’t have the expertise to tell you if this is safe or not.

Jeff Smith:
So what we did was we said, “Listen, we can build an automation chain. Right?” Where one, the change has to be reviewed by another developer who has the expertise to say, yes, we should do this or no, we shouldn’t. And then we can automate the execution of that script through JIRA tickets. So we’ve got an audit trail. Right? And I explained this is going to let the devs move faster. It removes us from this fault gatekeeping responsibility where the devs feel like they’re being treated like children. Right? Well, someone that doesn’t know what they’re talking about is going to say whether this is okay for me to do or not in a system I built. Right. In the system I wrote.

Jeff Smith:
And then three, it really allows them the autonomy and the speed to do what they need to do. And it frees us up to do more interesting things. Right? Because now we’re not stuck pairing with the developer, adding zero value. So when I frame it like that, they say, “Yeah, all right, that does make a lot of sense.” And again, you’re listening to your manager and you’re understanding what it is that they’re concerned about. I need to make sure that it’s audited. I need to make sure that it’s safe. So it’s like, okay, well it’s audited because it’s in JIRA, so we know who approved it. It’s safe because they can only execute the script that they’ve attached to the ticket. Right? And it’s repeatable because we know that the automation is going to do the same thing over and over and over again.

Jeff Smith:
And once you play it like that, they’re like, “Oh, right. Yeah. It doesn’t make any sense that we’re doing it this way.” So you get a few wins like that under your belt and people start to realize. They’re like, yeah. And they start to ask the critical question, “Well, why is this person in the middle of this process?”

Jeff Smith:
It’s a critical question. Well, why is this person in the middle of this process? What are they adding to the value stream of this? And if it’s nothing, what do we do to get them out of it?

Mike Pfeiffer:
That’s such a good point because I think people get caught up and forget about value. It’s like I’ve been in a few conference rooms where you kind of look up at the board and you wonder, “What are we doing?” And you ask the people like, “Hey, what is it we’re trying to accomplish?” And then you realize they just feel obligated to go do this next thing and they’re not focusing on how is this going to add value down the road. So I love that you keep bringing that up because I think it’s something that’s needs to be reminded to folks.

Mike Pfeiffer:
But one of the other things in the culture section of your book was a portion about hiring. And I think for our community and the people listening, a lot of people are transitioning in their career and going for these dev ops or SRE type roles or they’re a hiring manager, right, like yourself. So I would love if you could share some of your perspective there that would help either a hiring manager or a candidate get into this new world.

Jeff Smith:
Yeah. So from a hiring manager to other hiring managers, the first thing I would say is stop obsessing over senior talent, right? It is a such a competitive field out there for senior talent. So I would say ask yourself, how many senior engineers do I truly need? And then once you fill that, commit to filling from mid and junior level roles. And this why I say this, because one, there’s a lot more junior and mid level talent out there. And they’re eager and they’re hungry and they’re desperate to learn. Two, you don’t have to worry about undoing all of the bad habits that they may have learned at a previous job.

Jeff Smith:
The biggest thing is though, the reason most senior talent leaves is because they want an opportunity to lead and to mentor. And if you’ve got 15 senior engineers, guess what? You know what I mean? Senior engineers don’t want to be mentored by another senior engineer. But if you’ve got mid level and junior folks, not only are you building up your pipeline, but you’re giving a reason for your senior talent to stay beyond pushing you into the next technology. Like first it was the Cloud, now it’s like, “All right, I need to learn the next thing. We’ve got to move to Docker. All right. Now we need to do the next thing. We need to move to Kubernetes.” And it’s like, “Do we really or do you just need to continuously be challenged?” Put that energy into mentorship, into training, into leadership.

Jeff Smith:
For people that are looking to transition, this is something we talk a lot about and I, and I have a particular section in the book … in one of the later chapters, I was just finishing up … around Windows folks specifically. You’ve got to build your skillset around development. You don’t have to be a rock star developer, but you need to be able to code in some language. And I think that’s going to be table stakes. To give you an example of just you don’t have to be a rock star. For example, when we interview senior engineers, we give them the FizzBuzz problem. I know if you guys are familiar with the FizzBuzz problem, but basically it’s like, write a program that loops one through a hundred. If the number is divisible by three, print Fizz, if it’s a visible by five print Buzz, if it’s divisible by both, print FizzBuzz. It’s not really that complicated. We’re looking for pseudo-code. You’d be surprised the number of people that can’t complete it as senior engineers. But that’s all we’re looking for.

Jeff Smith:
So like the bar isn’t that high, but you have to have the capability to read and write in some object oriented language. I think Windows folks are at a slight disadvantage here specifically around programming and automation because for so long they came up in an ecosystem that didn’t encourage that. So when you’ve got a GUI based system, there is no value to learning automation because simulating a mouse click was very fragile at best. So I think the Windows landscape has changed tremendously. PowerShell is actually a great addition to the Windows ecosystem and I think if you’re in the Windows space, you would do yourself a huge advantage to learn that and really dig into it.

Jeff Smith:
The other thing for people trying to make a transition is, highlight the skills that matter and look at the job description because in a lot of places there are teams that are weak in certain areas and you might be able to beef up the team from that perspective and highlight that as a skill set.

Jeff Smith:
So for an example, we’re actually currently hiring for a senior dev ops engineer and we’re particularly weak when it comes to networking and database administration. So maybe you don’t have all the Jenkins CICD stuff, but if you can tell me the work that you’ve done in Postgres and how you’re an expert at BGP routing and all that stuff, that would help me round out the team in a way that just hiring another Linux system level admin doesn’t really change the structure or dynamic of the team. So try to get the inside scoop on the teams, leverage your LinkedIn network if you can find someone that works there. “Hey, where are you guys deficient?” So that when I put in my resume I can make sure that I’m highlighting like, “Hey, five years ago I was an Atlassian administrator and even though the job doesn’t require that, I know you guys are drowning with Atlassian work. I might be able to lend a hand there on top of these other duties.”

Mike Pfeiffer:
Sounds like a better pattern than just going and submitting your resume into the abyss and hoping to hear back. [inaudible 00:29:38] a little bit and connecting with people on LinkedIn. I actually talked to a guy this morning who just landed his first job as a dev ops engineer, and a lot of what you said was pretty much what he was saying because he doesn’t have any previous experience as a dev ops engineer, but he’s got lots of IT experience. He was able to play that up. And I think the one thing that you said … you said a lot of amazing stuff in that last answer to thinking about a person looking for the job. But one of the things you said that I keyed on was the passion and the hunger and how that comes through to a hiring manager. And if you can show that by, oh, you’ve been doing stuff in your own GitHub repo or you’ve been experimenting, you’ve been trying to show other people this stuff. I think that goes a long way. Right?

Jeff Smith:
It goes a long way. I can’t train passion. I can’t train passion. And if you’re coming to the table with passion, I know the other stuff will come. There was a guy, Poggi at GrubHub, Michael Poggi, who started as a help desk guy, but his passion was evident. His passion was so evident. Within a year, he’s an SRE. Within two years, he’s a contributing SRE to the pipeline. And then within three or four years he’s working at Amazon, doing a lot of their cloud infrastructure stuff. That’s all passion. I left GrubHub and then I had a lunch with him and we were talking and just hearing the stuff that he was talking about within the span of a year, year and a half, I’m like, “That’s not GrubHub. That’s you. That’s you spending nights and weekends sort of learning about this stuff.” And just when passion comes through, it’s just something that excites me in a way that I’m so willing to overlook so many different things.

Jeff Smith:
And like you said, we’re in a good industry where you can demonstrate that passion objectively. You can have a GetHub repository, you can have a Twitter feed where you’re talking about these things. You can have a blog where you’re doing even the simplest stuff, right? It doesn’t have to be … This is something we should probably talk more about. We are constantly comparing ourselves to folks on the internet and the amazing things that they’re doing. “Hey, everyone. I just wrote a new module for eBPF for tracing kernel traps, right?” Yeah, that’s fine and good. but you know what else is good? Showing us your experience with ‘Hello, World!’ and a Ruby on Rails app for the first time. Tell us what you learned, what you thought was weird, what was difficult for you to grasp? Because somewhere that’s helping someone.

Jeff Smith:
Your voice is unique because it’s your voice and you don’t have to have some revolutionary mind blowing thing to say, but just saying it in your voice is going to touch someone and it also demonstrates your sort of passion for the industry and your passion for learning. So don’t discount how valuable your voice is to other people.

Jeff Smith:
I remember I gave a talk in Berlin and I was concerned that it was a little too basic for certain aspects. But again, being me, sometimes I don’t realize where I am in terms of my career journey and to have someone come up to me after the talk and say, “Thank you. I am new to databases, but I understood everything you said and it made the talk … it’s super impactful for me.” That wasn’t anything revolutionary that I was saying. That was just my voice and I connected with this person and was able to help them out. So don’t discount your voice. I would say blog, tweet, get your GitHub repo out there. Don’t be embarrassed if it’s something basic or simple. Just demonstrate that you’re passionate about this stuff and that you’re working on it and that shines through. And I’m telling you, it puts you ahead of so many people. People think that the bar is super high. It’s not. It really isn’t. Having that repo out there puts you ahead of, I would say, 60% of the applications I get.

Mike Pfeiffer:
So true. And I tell people all the time and I sometimes feel like, “Man, do they think that I’m just BS-ing them?” But I know it from my own experience, going through as a passionate person and kind of barging my way in every level of the way. But that guy I was talking to this morning was the same thing. The passion and then just the basic awareness around some of these patterns, these new things, and the willingness to just get in the game was this kind of like the hack, if you want to call it that, that he used.

Mike Pfeiffer:
So I think that your message on this show, Jeff, has been massively impactful. It’s awesome. Where should people be looking, besides Manning, for your book to come out? And by the way folks, we are working with Manning to give away copies of Jeff’s books. So go to the show notes as you’re listening to this. You can enter the giveaway. That’ll be running for like three weeks after the show goes out. So we’re going to give a bunch of free copies away. But Jeff, where should people try to follow along with you, what you’re working on and all kinds of stuff like that.

Jeff Smith:
Right now Twitter is probably the best place. I’m @darkandnerdy on Twitter. That’s always a fun one. But yeah, Twitter is probably the best place. I do a lot of interaction there and then anything I post will usually go out through that Twitter feed. I have a medium blog that I haven’t been updating as much because every time I go to write something I say I should be writing my book, not writing this blog post. But once the book finishes up I’ll be writing a lot more there. I’m also doing a bit of work on ethics in computers and in computer science. So you’ll probably see a lot more work regarding that space coming out soon. And then, look for me on the conference circuit, too. I do a lot of dev ops speaking and stuff like that.

Mike Pfeiffer:
Nice. Very cool. Well, Jeff Smith, thanks so much for bringing the value today, man. I really appreciate it. Thanks so much.

Jeff Smith:
Yeah, it was great chatting with you.

How to Make the Transition to DevOps Engineer

Discover a proven step-by-step game plan to move into a rewarding career in DevOps and automation.