How to become a DevOps Engineer: Mihail Chinkov’s story

Finding a name for this story was the toughest job of all, cause it meant that I needed to identify what I do and give it some name. Here on mkdev you can find the stories of a Java-developer, a PHP-developer, a QA engineer. But how I can define what I do?

To make everything clear, I’ve decided to name this post “a DevOps Engineer story”. However, you have to know that when you see the phrase “DevOps Engineer” in a job description on a vacancy website, you can never know what it really means. This title is some sort of a Schrödinger's cat in the IT world. Well, it’s mainly because DevOps is not a job title, but an engineering culture.

How I didn't want to be a programmer

As a child, I wasn’t really interested in programming and was never messing around with computers or hardware. I was doing sport as an after-school activity and was into such subjects as literature, history, and social studies. Maybe it was more of an aptitude than an interest, though. When I was 14 and had to upgrade to Windows 7, my father’s friend was asked to do it, not me. If there was some problem such as a porn banner that I caught trying to pirate something, I usually contacted some master from a newspaper ad and paid from my own savings to get rid of it. As a teenager I used to do some small jobs like handing out flyers or running errands and this is how I earned money I later put in my piggy bank. I didn't pass my exams well enough to enter my dream faculty of economics in my dream city Saint Petersburg. Life’s tough. That summer I decided to take computer studies as one of my school exams only because I thought it would be a piece of cake (and it was). So I decided to stay in my native city of Penza, entered a local university and took Information Technology as my major.

I'd been struggling with reality for about a year. The main programming language of the course was C and it made me go weak at my knees. I used to just blindly copy my mates’ assignments and pay freelancers for the code for my term projects, which actually were pretty simple. My summer work earnings were enough to pay for around 8 projects and, when I realized that, I was shocked how rough life can be if you have a degree, but know nothing and can’t get a proper job. When I was thinking about giving up my studies I was so scared that all I saw was army hardships, faces of people who’d believed in me, and pointless future. That was a complete no-no for me. This is why, even though I still thought that programming wasn’t my cup of tea, I decided to give the world of system administration a chance.

How I became a programmer anyway

I stocked up on e-books about networks, computer architecture, operating systems and Linux fundamentals and was reading them by day instead of boring lectures and set aside my favorite TV series at night. After about 4 months, I drove the head of my university research lab crazy by asking about a job there and finally got a place as an intern. I didn’t get paid for the first few months but I was happy anyway. Having an opportunity to see and touch all those production servers, live monitoring, and networks with their switches and routers was enough to feel blessed.

After some time, I started to annoy HR specialists of all local companies with requests to hire me. I tried media-streaming outsourcing, but it wasn't paid well, so I changed that job really fast. My next job was the project on AWS. This is when I started encountering the word “DevOps” pretty much every day and began to dig deeper. I realized right away that DevOps is more of a culture that solves business' major problems with all sorts of technical and communicative mumbo-jumbo than anything else. So this is how I got the idea to switch from the “support, set up, and repair” specialist to the one who can see real major problems in development and help solving them.

I continued jumping from job to job, taking on another new project every 6 months, which was kinda suspicious for the recruiters. At some point, I started working at iFunny. The product was aimed at the American market but was being developed in Penza, Russia. And, what a twist, that was the city where my university was situated. At that point in time I was studying and working full-time.

That was the most iconic Web-Operations lifestyle I’d read in the books about. There were 5 database engines (such as Cassandra and MongoDB) with 15 clusters, attempts to create CI/CD pipeline to let developers deploy their monolithic application several times a day on a bunch of production EC2 instances, and an obligation to be on-call round the clock and wake up at 3 a.m, if needed, as it was a very busy time in the US. During the nighttime all the problems that weren't properly checked would suddenly pop up.

Happy end

After a year at iFunny, I found a job in Berlin, and this is where I live at the time of writing this post. That mere pay that I was getting in an outsourcing company 2 years before now seems like something that never happened with me. After some time you start taking a steady pay rise, frequent training courses, and a wonderful environment for granted. It’s amazing how fast you get used to such things.

It took me just under 5 years from the moment when I chose to work in IT to start being called a Senior Engineer by recruiters and colleagues. That wasn't easy at times, but it was worth it, and I hope it will be.

Questions

Can you give some advice that is usually considered to be controversial?

It sounds trivial, but I can’t just avoid this one: do more, think and analyze less. IT is a young area, there’s no conventional career path or the one and only that is 100% right. Don't be too strict with yourself. If you are a Junior Developer, your code will be shit…um…not the best anyway, but nobody expects perfect results from you from the very beginning .

Choose an area with fewer limitations. It’ll probably be a startup or an outsourcing company. Work fast, look at the result, correct your mistakes, improve, and go on. Speed is the biggest advantage of the young and ambitious.

Managers and team leaders are likely to be judgemental, closed-minded, and subjective. Which is totally fine, we’re all human. The most important feedback is the one from the software you’re developing. The faster you introduce changes to it, the faster you get the feedback.

How do you maintain your skills to be relevant? How do you grow and get better as a developer?

In my case it usually happens naturally. At work I sometimes face the issues I can’t solve with the tools I have or know. I search for the technology that can help with that, read the docs, try it out and it becomes my new skill! It’s also good to go to your favorite job site every now and then to check the most needed skills and technologies at the current time.

Your top 3 books for a newbie?

I really want this article to remain relevant for the next 5 years, so here are only tried-and-true ones:

  • Modern Operating Systems by Andrew S. Tanenbaum

  • Computer Networks by Andrew S. Tanenbaum

  • The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

Your top 3 sites/newsletters/information sources that every developer should read?

I've unsubscribed from all the newsletters and company or personal blogs, as they made me react to any insignificant new topic in the industry. I follow Telegram channels "Devops & SRE Library" and "DevOps Deflope News" to stay tuned. You can also listen to the Arrested Devops Podcast and subscribe to the DevOps Weekly Newsletter.


Перевод с русского на английский сделан Анной Можаевой.

Translated from Russian by Anna Mozhaeva.

Cookies help us deliver our services. By using our services, you agree to our use of cookies.