DEV Community

Balázs Nagy
Balázs Nagy

Posted on

Paralysis by Analysis — Becoming a DevOps Engineer

I’m sure this is not the first, nor the last article you might come across that tells you a story about, or gives you a myriad of tips or various resources on how to become a DevOps Engineer. This isn’t necessary that article. All of the previous items can be found with a well formulated Google search. (Though a quick link to my personal favorite: kamranahmedse’s DevOps Roadmap. )

Rather, I’d like to share my experience and my views on the topic.

I have spent waaaaaay too much time — a good 2 years in total — thinking and planning how I want to become a DevOps Engineer. I searched a lot, read a lot and planned quite a lot. After some time I realized that all content related to DevOps is practically endless, got paralyzed by what’s important and what’s not; thus never got to the point to execute on the plan I researched and curated so meticulously.

Learning from that I distilled my experience into a few paragraphs. It did help me to get closure on the seemingly endless analysis, and start walking-the-talk.

Spatial Awareness

In my opinion there isn't one (correct) answer to “What is DevOps?” nor there is an ultimate definition. Therefore I find it important to learn what DevOps is about from various sources and develop your own view and understanding of it. You should be able to shortly describe what DevOps is about, with your own words. This is your space, all that encapsulates what’s DevOps for you.

Within that space aim to define distinct topics and practices you want to focus on. It’s not going to be easy in the beginning if you’re somewhat new to DevOps. But as you search and read you’ll see generally hot topics and frequently mentioned practices. These will be your dimensions, and think about them as areas of knowledge and expertise.

The relative relevance of your skills

Now that you have started to develop spatial awareness and have defined a space and its dimensions it’s time to place yourself in it. The tricky part is that all of this is relative to you, not absolute to a universally agreed upon unit of measurement.

Start with comparing your current skills to that of your immediate surroundings. In essence your colleagues; junior, peers and seniors alike. You will discover where you excel and what are your strong points. At the same time be also critical of yourself and evaluate in which areas you need to improve to become a well-rounded DevOps Engineer. This includes also looking outside of your company and see how you and your current skills fare against job openings (for example) at other firms and/or in different sectors.

Pet projects

A very obvious one – not really a lot to talk about here. But. What I had some difficulties with is to keep my effort(s) focused and consistent. I found this especially difficult as in my view of DevOps is not about making a front- or back-end application that's fancy - but making it all work.

What you can do is use the materials (apps) from tutorials, or create a sample app (e.g. from Visual Studio) and build a pipeline around it – or the environment where it should be deployed. In my view it's not completely about a fancy website animation and/or flashy forms, but again – to make it work in a secure and automated manner. Find your playground and start practicing. As you discover more and more you can pivot to different tools and discover integrations, interesting software integrations. What you learn here will be useful as reference. Either for work, or for future designs, architectures.

Contribute & Collaborate

It's harder than it looks actually. I've been on this journey for 2 years now and this is the first actual contribution back to the community. I'm a bit of a perfectionist so I have re-re-re-re written this piece about a gazillion times. But you've just got to get started.

Because every contribution actually matters. Maybe it's an article that helps someone. Maybe it's an issue you've reported on an open source project or an application you're working with, and got solved helping other users, or the maintainers. Maybe it's a tutorial you've written that rids someone of their frustration on an error, issue they were facing.


First of all: I hope this helps.

And remember:

  • Know your space: Have your own view on DevOps and its practices. Express it clearly, concisely and consistently
  • Know your game: Compared to someone you're a SysAdmin, compared to others you're at the HelloWorld level. Be humble but confident in your skills
  • Make it work: Build things that work. Find something interesting and work with it – you don't have to build the next Facebook...
  • Make it heard: Share your views, ideas, and knowledge. It's yours and it's valuable

Discussion (1)