9 hidden talents of devops ninjas
High-performing devops shops fire on all cylinders, with each team member committed to the overall mission. When one team member doesn't inherently believe in the mission, they can soon find themselves holding up the pipeline and becoming the bottleneck in what would otherwise be a successful deployment strategy.
Following are nine qualities that anyone practicing devops should have. Some may at first appear to be inherent to one’s character, but with practice, all can become second nature to anyone seeking to establish a successful career as part of a high-performing devops team.
This trait may sound counterintuitive, but there's a catch. Of course, laziness, by itself, is a characteristic trait not likely to be welcome in the workplace, but the actions you take because of your laziness can be a real asset. One core devops principle is automation, which is what allows teams to deploy reliable code, frequently in a consistent, predictable manner. Left up to humans alone, code deployments would take forever and be fraught with errors.
If you're a naturally "lazy" person, you probably hate doing things more than once. It seems so inefficient and waste of time. If so, this is a great characteristic to have! For example, do you get angry when you work for an hour on an important piece of code, forget to check in to source control and your IDE crashes losing all of that work It sucks! No one wants to write all that code again! That's my point, although an extreme one. If you agree with me, then why are you doing the same things over and over again
Truly lazy techies absolutely hate doing the same thing twice. This attitude naturally leads to automation. Why continue treating your servers like snowflakes painstakingly installing the same software and changing the same settings for every single server That's my version of torture! Script out those installs and configuration management tasks so you don't have to worry about them again.
Humans are born into routine. We get up in the morning, live our life during the day, and go to sleep at night. Our natural circadian rhythm ensures this. Instinctively, this is why we all probably enjoy routine; it's recognizable and it's comfortable. Thinking is hard and requires effort. In a routine, we transfer that thinking to our subconscious to where activities feel natural. That's understandable. But to be a true devops ninja, you must set this instinct aside and roll with the punches.
The only constant is change in this world. This cannot be more true than in a devops environment. Constant improvement: that's what it's all about. We recognize problems, fix them, add the fix into our automated tests, and iterate. Rinse, wash, and repeat. To be a successful devops ninja, you have to set aside this routine mentality. Devops is a volatile work environment to be in. Changes are happening constantly. We're not in a waterfall world anymore where we plan, plan, plan and implement once a year. It's now plan a little, implement, get feedback, and iterate as quickly as possible. Never a dull moment, few repeated, predictable days -- that's the life of a devops ninja.
You are no longer allowed to pack your lunch, come to work, close your office door, and only appear to occasionally relieve yourself. You must be approachable. You must socialize with your team and work on issues together. Think of devops as a team sport. Devops is not golf or singles tennis. It's basketball or football. You have to contribute to the team to win. In order to do this, you must collaborate with your teammates.
A long, long time ago, IT was considered to be a business expense. IT was the department in the basement that was only necessary to keep the lights on. As a result, the industry self-selected and hired to fit that mold -- people who could code or manage systems, more or less on their own, sometimes literally in the dark. These were the kinds of people that few talked to for fear of what they might stir up in someone so isolated in the workplace, or for fear of inadvertently disrupting a basic technical service of the business. If you thrive on this kind of cone of silence, you may not survive in a devops world.
Everyone doesn’t necessarily have to like each other but we all must be able to make others comfortable with communicating with us. If not, you will soon end up being a dead man walking. If you're not contributing to the solution, you are inherently contributing to the problem.
When you don't have a vision, technical debt will ensue. Technical debt arises when you are caught up in the moment. "We'll get to that later," "That's not a problem with this current release," and "I'll do this manually this one time" are common statements that reflect an accumulation of technical debt. If you're someone who cannot envision what your code or system will look like when it's getting slammed with thousands of requests per second, then you're at a major disadvantage in a devops world.
Devops ninjas can envision and architect a solution that will not only solve the problem in test and production when it's released to the current user base. A true devops ninja can foresee a time when your company is bought and a sudden influx of new users are brought onboard.
Do you enjoy helping others Personally, I love the feeling when someone comes up to me and is truly thankful for assistance I provided. It makes me feel good to know that I can share my experience with someone else. If you're going to be a devops ninja you must share in this mentality. No one's going to take your job. No one's going to "steal" your idea or your work. It's time to set all of that aside and think for the team rather than covering your own butt.
Devops is about sharing your successes and failures for others to learn from regardless of your ego. Egos have no place in a successful devops shop. If your team is truly practicing devops, your failures will be treated as learning opportunities and your successes will be awarded. If you truly share your work and receive the opposite responses, I'll go out on a limb and say, "It's not you; it's them."
You must be transparent and open in your day-to-day activities in order for your team to measure what works and what doesn't.
Devops is rooted in trust; trust of your team and of the business itself. Any member of a team practicing devops must be able to trust that others can do their jobs as well as or better than they can.
A true measure of trust would be demonstrated by working on a particular software feature that you envisioned, proposed, and built yourself, and when the time comes for you to work on another project, you hand your baby off to another developer. You must be able to let it go -- to trust that your feature won't be bastardized or taken into an extreme new direction. Even if it happens to do so, you must be able to live with it and understand that the users and business has mandated this new direction.
You must be able to depend on your team members, and if you feel you can't, you must approach them and have that awkward conversation. If they themselves are approachable (Talent No. 3), this should be easy.
Developers with pagers! Sys admins who code! What's this world coming to anyway Devops, that's what. "It's not my job" should be erased from your vocabulary completely. This isn't to say you're going to be able to assist everyone for every task -- quite the contrary. This is about either assisting, when you can, or pointing them to the right person who can.
This talent is about retooling the concept of a "job." Sure, we each have our areas of expertise, but the true devops ninja is flexible. Developers must be responsible for their code and assist system administrators when server resources suddenly spike. On the other hand, system administrators must be able to read a developer's code well enough to understand it might be a code problem that will require getting the developer involved in the solution.
This talent is about realizing you are not a horse meandering down the street with blinders on, seeing only the road in front of you. It's about removing the blinders and, instead of getting spooked at every distraction, becoming more open to others' positions in the team.
The pace of devops is fast. After all, continuous deployment is the goal. That means only one thing: continual speed. Without proper tools in place, you'll never be able to keep up. This talent is loosely related to No. 6 (“You can let it go”). One issue with engineers that don't possess the ability to "let it go" is perfectionism, even to the extent of disliking automation. They don't trust tools but are constantly trying to reinvent the wheel and do things "right," in their eyes.
To be a true devops ninja, you must realize that tools are critical to your success. Granted, high-performing devops organizations build their own tools -- for good reason. However, I'd argue that configuration management shouldn't be one of them. Teams have no excuse not to use one of the many choices out there for your configuration management needs.
Configuration management tools can automate so many tasks and allow you to focus on what's important: writing code and getting it deployed to your customers.
This talent is more geared to the system administrators. Software developers build products by writing code. These products are then packaged and placed onto infrastructure to service the customer. If developers need to make a change, they don't have to get up from their desk, go into the data center, and physically manipulate an object. It's text. A few keystrokes from their keyboard and a commit will make the change. Code is dynamic, flexible, and easily changed. If not, how do you think agile development practices survived this long That's a lot of changing!
An ops devops ninja has learned and can see the benefit of the "infrastructure as code" paradigm. Though this is a new concept to most system administrators, you must be able to see the obvious benefits of treating infrastructure as code rather than physical objects. You must be able to understand "disposable" servers and keep your cool while that server is simply rebuilt from the logic already built inside of the code.
You must understand that a server itself is simply a host. What allows an organization to quickly recover from service downtime is the code itself. The code is the blueprint. If your house is destroyed and must be rebuilt, without the initial blueprints, you're going to have to build a house from scratch again.
Truth be told, there are no "hidden" traits or talents of a devops ninja. Anyone practicing devops wouldn't even be considered a ninja if you didn't show these talents in the first place. These are nine talents that all successful devops team members possess and demonstrate in full view of their colleagues every single day. If they are hidden and you deeply believe you possess these talents, show them off! Organizations notice and praise these talents. If you try to hide them to fit in with an organization that doesn’t appreciate these skills, you have more successful organizations that will pay you a much higher salary for them.
Related articles