X
Business

4 habits of effective DevOps engineers

'Knowing and realizing the strengths and weaknesses of technologies is a massive superpower and can really help empower your DevOps career when you make decisions'
Written by Joe McKendrick, Contributing Writer

For those interested in expanding or developing their forte in DevOps, an open mind may be your best tool. Successful DevOps engineers are always learning, as they actively endeavor to understand both the coding and delivery sides of the equation, while keeping the business problem front and center. And, importantly, they try to avoid over-engineering their solutions or processes.

img-1128.jpg
Photo: HubSpot

That's the word from Marcel Dempers, software engineering specialist, who, in a recent video, urges those interested in pursuing DevOps careers to broaden their horizons. Dempers divided his presentation into three nuggets of advice, but I think there was enough information to merit four areas every DevOps candidate needs to consider: 

Effective DevOps engineers have four habits in common:

They strive to learn how the other side works.  Developers need to understand infrastructure, and operations people need to learn coding. "If you're struggling to write code, focus on that and learn how to code," Dempers says. "If you're struggling to learn about hardware, focus on that. Learn about infrastructure and learn about networks, load balancing, proxies. Part of being a DevOps engineer is having the ability to write code, build your own tools so you can build your own command-line interfaces that will help like bridge the gaps between development and operational processes, and whether it's monitoring, performance, or whatever it is."

They seek to understand the underlying fundamentals. Having an understanding of technology foundations will go a long way in DevOps, says Dempers. Enterprise deployments are accelerating, and there isn't enough time to dig into the weeds of every new technology, he says. "Learn about the underlying fundamentals of a technology, rather than how to use the technology, and how to apply the technology."  For example, "instead of just learning how to run a Docker container, dive into the Linux features that make containerization work, and learn about those features. It makes it really easy to understand how Docker works. Then you can then move on to technologies like Kubernetes that use the same Linux kernel features."

With an understanding of the underlying technology, it will be easier to communicate across the organization and understand how the technologies interact, Dempers adds. "You basically learn how to put all the pieces of the puzzle together and paint a picture in your head about the technologies. Then you can focus on the gaps of the things you're missing, rather than just focusing on how to use a technology."

They work to avoid bias. It's important to avoid bias in all aspects of life, and this applies to managing business technology implementations as well. "Being biased about certain technologies is okay, but when you have tunnel vision focus on a certain tech stack," says Dempers. "It's not going to help you or your team. Now I have my own biased opinions about technologies. But knowing and realizing the strengths and weaknesses of these technologies is a massive superpower and can really help empower your DevOps career when you make decisions."

They want to keep it simple. "We live in a world where developers and operations constantly over-engineer, and technologies and cloud providers allow us to easily overspend," says Dempers. "Cloud providers are absolutely loving us these days. Google 'cloud over-spend, and look at the hundreds of articles talking about the millions and trillions of dollars that people are just throwing away on cloud solutions."

Before getting tangled up in complicated solutions to what may be simple problems, "it helps to take a step back looking at the problem with a wide-angle lens -- and also ask, 'is this actually the problem I want to solve?'" Dempers suggests. "Sometimes these problems are self-inflicted, and by talking to the right people in your organization, you actually figure out that that it might not even be the problem you had to solve in the first place. You may find you can actually bend and transform the problem and come up with a much better solution."

Editorial standards