Here at AL, we strongly believe we have some of the most talented DevOps engineers in the industry. But, what does that actually mean? With the DevOps movement growing and skills being high in demand; what does it mean to call yourself a DevOps engineer? And, more importantly, what skills does that give you that can really allow those you work with to achieve their creative potential through the successful adoption of digital?

A personal favourite, from one of our engineers, was this:

“A very particular type of laziness

Like the hatred of repetition”

Naturally, I asked him to expand slightly…

“So, any of us are happy to try to deploy something complicated that takes a long time or do a less than exciting task involving extensive reading.

But we really, really hate doing it again and will go out of our way (learn a new programming language, write a script, fix a broken program) just to get it to take no effort the second time we do it.”

Coding, scripting and understanding multiple technologies in order to tackle problems head-on are all key to being a good DevOps engineer. However, the ability to collaborate and communicate effectively are also just as important, DevOps engineers need both skill sets to deliver value.

When I last spoke to our renowned DevOps trainer Steve Shilling on growing tech talent this was his comment:

What do you think are the most important non-technical skills to have is?

“Being able to communicate. For DevOps that is definitely the most important.”

Collaboration is one of our core values. To collaborate effectively we’re aware that communication is key. Every one of our engineers must show more than just a technical aptitude, but a human intelligence as well.

To get their take, I recently caught up with two of our DevOps Engineers – Martyn Pratt and Jack Sheppard.

What was the start of your career in IT

Martyn: It was probably a module that I took at uni, I did chemistry and physics and it was a computing module all about programmatically solving problems with mathematics.  Although I don’t use those tools anymore, I enjoyed the instant gratification of writing tools for a while then getting an answer straight away.

Obviously, I then didn’t go into sciences after uni, I just got a job in support of an internet service provider. I’d definitely say it was that module that got me into IT. I just liked the design processes in chemistry, it was really satisfying, but the lab work was a pain. With physics, I liked just doing it on paper and getting the instant gratification of getting it right. More about the process of building, designing and thinking through problems. It’s all about the problem-solving aspect really.

Jack: I started as an apprentice as a third line engineer. I came out of school without qualifications and didn’t want to go to university. So, I decided to pursue an apprenticeship role instead. I had a general like of computers at the time, that’s where it all began.

Why DevOps, not Dev or Ops?

Martyn: I enjoy owning the entire process, so even if I’m not writing code in the application I can look at that code and see potential issues. It all comes down to ownership for me, from start to finish. Being able to look at different levels of process and know where problems might lie so that I can fix them. I really enjoy working with other people as well, because that’s how I learn quickest. Most things like the commands and tricks that I use day to day will come from a 2-minute conversation with another person and them going ‘’oh, you should do this.’’ Leaving me thinking, why have I never done this before? If I had to choose, I guess I’ve got a slight preference for development because you can build an entire little wold on your laptop, even if no one else can see it.

Jack: Purely by accident, the role that I was in needed both dev and ops skills and I just so happened to grow into it during my time there. So it literally just so happened that the role available was a DevOps role. I think it’s a better role, more interesting. Pure dev and pure ops seems boring to me, I like to change it up. You’re not alive until you’re hacking live.

If you could give one piece of advice to someone beginning their career as a DevOps Engineer, what would it be?

Martyn: Deploy an application automatically from your laptop and write that app yourself. It doesn’t matter what it does, or if it’s copied from someone else, just do the job. And also, you can never automate enough.

Another thing that I think is quite obvious in the industry is that the subject of your degree doesn’t matter, I’ve always just enjoyed learning, with IT there’s always something new to learn. Even if I had done a computer science degree, I’d still have the attitude of wanting to learn new things and you can’t learn everything in a degree. I think I could have done any degree and still ended up on this path. If I were to do it again, I’d love to give video game design a go.

Jack: Probably to be persistent,  because it’s going to be horrendously difficult when starting out and sometimes tedious and frightening. But, if you stick with it then you will get into the stride of things. Thick skinned would be a helpful trait.

Any common pitfalls associated with adopting DevOps ways of working?

Martyn: Anytime spreadsheets are involved or not starting a fresh, people try and modify old processes when what you really need to do is start a new process. Start with monitoring, authentication and testing rather than just getting stuff out the door. Rushing code out the door always leads to those 3 things being a second thought when they should really be the most important.

AL is great, there are so many really really clever people from different backgrounds. Interestingly, amongst the senior engineer team, it’s cool to hear how people got into DevOps without any formal path being defined, everyone I know in this industry seems interesting outside of work as well, you need to have a passion for something.

Jack: Probably not understanding the underlying technology would be the big one, trying to make rash decisions in the face of automating things and not fully understanding the consequences of them. The core thing to understand is to automate from the offset, rather than working backwards, build something you can automate from the beginning. Build something once and make it highly configurable.

What cultural attributes do you think make a great DevOps Engineer?

Martyn: A willingness to listen to other people, customers, engineers. Just listen to what they have to say and be willing to make your opinions heard as well. Most of the DevOps engineers I’ve met are just enthusiastic people. They talk about anything, food, politics, they’re people that just want to listen and learn anything and absorb information, regardless of what it is. I’ve never had a conversation with anyone that works in DevOps that made me think they didn’t want to hear what I had to say.

Jack: Freedom, I’d say. Being confident enough and within the right environment to just have a play around with technology and see what we enjoy using and what works best in each scenario. People who are constantly trying to self-improve, rather than a 9-5 mentality, turning off at the end of the day. Most good engineers that I’ve seen have side projects they’re tinkering with and books they’re reading and all sorts of stuff. It’s that hunger to learn more about it.

DevOps should enhance the way Dev and Ops work together – how could collaboration be extended beyond DevOps and what impact might this have on IT programmes?

Martyn: I love the idea of non-technical people also adopting a DevOps attitude, speaking about what processes bog them down and talking with teams to smooth out workflows and get through bottlenecks. All DevOps is, is just removing bottlenecks with IT pipelines.

Jack: Some customers should be brought in earlier, there’s no point building a massive suite of applications for someone, only to then find out it doesn’t suit their workflow. Applying DevOps best practice to as many aspects of the business process can only help.

Which tools do you think have been game changers and why?

Martyn: Ansible. For me Ansible has the simplest syntax, it’s so nice coming from other automation tools and using ansible because it really hones down what you want to do and what you want to happen in a system. I even used it to get my job at AL on the technical test.

Jack: I do love a good bit of octopus deploy. I like configuration management, it allows me to automate a huge subset of tasks that would usually take hours to do. It comes back to building something to be automated to begin with.

So, whats next for your career?

Martyn: Next is learning more Azure cloud environment, I’ve always worked in AWS and Azure is a slightly different world. I’m getting used to the toolset and seeing how well it integrates into a classic windows environment. It’s nice to be on the forefront of windows automation because I’ve always seen it as a much slower process driven environment and it’s good to see they’re also trying to get things automated along with the rest of the Linux using world.

Jack: I haven’t given it all that much thought, I usually just take things project by project. Because no two are ever the same, I’d have to say continuing to focus on continuous learning.

Finally, how do you think automation can have a positive impact on how organisations do business?

Martyn: Good Automation allows engineers to focus on improving processes and deploying more of the things. Deploying more means more problems can be discovered and fixed before applications go live and reduce the risks associated with going live.

Jack: Automation allows engineers to better focus their time on being productive and happier by cutting out the tedious and mundane tasks that can consume a working day. Doing this reflects positively back to the organisation as a whole, as happier engineers are more likely to take pride in their work and use their time to better their skills and knowledge thus creating an environment for collaboration and self-improvement.