Retraining in DevOps - what to prepare for yourself
In this article, Alexandra Romanenko, who collaborates with EPAM as a Lead Software Engineer, shares her view on retraining and tells you what to look for if you want to become a DevOps specialist.
Photo source: pexels.com
I came up with the DevOps specialty, still being a developer in the course of working on a project, using serverless technologies. In classic Java projects, the roles of testers, developers, and DevOps are clearly demarcated, and serverless systems are fundamentally different. This new, interesting topic “fueled” my professional curiosity, I began to delve into the project, to study it, not limited to just my own job site. After that, she began to prepare reports on the topic of serverless services at Amazon and speak with them at the DevOps meetings. In my current position, I was ideally suited for skills, and there was a reorientation.
')
My experience shows that DevOps, as a rule, "come" from system administrators and, less often, developers. In order to be a reliable “bridge” between the development process and operating activities, you need to have knowledge in both areas. In practice, this is extremely rare, because in the process of work colleagues have to share experiences. For example, I did not have enough knowledge in the field of system engineering. I did not study the necessary disciplines at the university and did not encounter them in practice. Filling in the gaps was helped by colleagues with experience in administering networks with which I, in turn, shared my knowledge. In a good team, symbiosis and mutual aid always reigns, otherwise there is no way.
In my opinion, it is easier for developers with a developer’s background to get started in DevOps for two reasons:
True, there is another side to the coin. If, for example, one of the tools that DevOps needs is not working properly, fellow system administrators can only express their displeasure loudly. At the same time, I, as a developer, add myself to my work: I am looking for a mistake in the code and even try to fix the bug. But this is possible only if the instrument is written in the language I speak, but if not, bitter disappointment ensues. One of my reports is called “Why I hate Terraform”: initially, because it often breaks down because of bugs. But the fact that it is written in GO, which I don’t own and, therefore, I cannot fix bugs, doesn’t help either
I am for not following others blindly, but making my way. Therefore, I advise you to use the opportunities that are at hand and develop at a comfortable pace for you.
My friend bought a MacBook. Something went wrong with him, she decided to “ask” the Internet for an exit. On one of the forums I found the most “filled out” answer and decided to use it. As she learned later, lovers of sarcasm voted for this comment. In the response to the forum it was written: “Run the command line“ sudo rm -rf ””. As a result, in one fell swoop, she demolished everything on a new computer. If she checked what problem this code had before using it, problems could have been avoided.
It is better to spend 3 hours to understand how the code or script works, than 5 minutes to copy someone else’s response on the Internet and 3 days to disassemble, why something has broken.
These skills you will automatically develop. They will have to engage every day. The main thing is to be ready and know what awaits you.
The precondition for the change of specialization is interest. It is he who encourages the study of related areas. For professional development, it is extremely important to study not only your profile topics that already have experience, but also to get acquainted with completely new directions for you if they inspire. Perhaps one of them will determine the vector of further career development.
Need to try different things. “Madness to do the same thing, hoping to get a different result” - I really love this expression.
Professionals who want to be "on the crest of a wave", work with advanced technologies, earn more, you can not stop for a second. It is important for them to follow the trends daily, to be interested in new projects of the company, to track current trends.
But personally, I have a more romantic approach to professional realization: I like to quietly enjoy my favorite work, hone my skills, if you want to “go with the flow”, and forcing myself to reorient to something new just because it is popular is not my style.
Photo source: pexels.com
My history
I came up with the DevOps specialty, still being a developer in the course of working on a project, using serverless technologies. In classic Java projects, the roles of testers, developers, and DevOps are clearly demarcated, and serverless systems are fundamentally different. This new, interesting topic “fueled” my professional curiosity, I began to delve into the project, to study it, not limited to just my own job site. After that, she began to prepare reports on the topic of serverless services at Amazon and speak with them at the DevOps meetings. In my current position, I was ideally suited for skills, and there was a reorientation.
')
Where DevOps Specialists Come From
My experience shows that DevOps, as a rule, "come" from system administrators and, less often, developers. In order to be a reliable “bridge” between the development process and operating activities, you need to have knowledge in both areas. In practice, this is extremely rare, because in the process of work colleagues have to share experiences. For example, I did not have enough knowledge in the field of system engineering. I did not study the necessary disciplines at the university and did not encounter them in practice. Filling in the gaps was helped by colleagues with experience in administering networks with which I, in turn, shared my knowledge. In a good team, symbiosis and mutual aid always reigns, otherwise there is no way.
In my opinion, it is easier for developers with a developer’s background to get started in DevOps for two reasons:
- They are more understandable requests from the development and testing teams, they "speak the same language ."
- Programmers are accustomed to structural complexity . They develop a knack for working with large amounts of data, thousands of files and folders. Any project, in any programming language, is more complicated than the code DevOps has to deal with, because, as they say, they are not used to it. But colleagues without development skills account for a little more difficult.
True, there is another side to the coin. If, for example, one of the tools that DevOps needs is not working properly, fellow system administrators can only express their displeasure loudly. At the same time, I, as a developer, add myself to my work: I am looking for a mistake in the code and even try to fix the bug. But this is possible only if the instrument is written in the language I speak, but if not, bitter disappointment ensues. One of my reports is called “Why I hate Terraform”: initially, because it often breaks down because of bugs. But the fact that it is written in GO, which I don’t own and, therefore, I cannot fix bugs, doesn’t help either
Sources of knowledge
I am for not following others blindly, but making my way. Therefore, I advise you to use the opportunities that are at hand and develop at a comfortable pace for you.
- Start with your project. Surely there is a DevOps specialist on your project. Analyze what he does, what skills he uses. If you have questions, ask directly. Your task is to become a DevOps on your project. It is always easier to retrain in a familiar environment than to come to a new job in a different role. You know the objectives of your project, you are familiar with the team, comfortable conditions. To the strangeness of new skills will adapt more easily.
- Full-time meetings, lectures, meetings. If your project does not have a DevOps specialist, professional events are a great solution. At such conferences and meetings you have access to practices. Developers can ask questions and ask for advice. And the topics of the reports will prompt what is now relevant in this profession.
- Work with official documentation. I am not a supporter of online courses and video tutorials. All the necessary information is contained in the official documentation. Often people are faced with a problem, google the solution, copy and paste the code or script from the most "unspoken" answer on the forum. Globally, this problem does not solve. The person still does not understand how what works or why it still does not work. Moreover, you can search for a solution, and create more problems.
My friend bought a MacBook. Something went wrong with him, she decided to “ask” the Internet for an exit. On one of the forums I found the most “filled out” answer and decided to use it. As she learned later, lovers of sarcasm voted for this comment. In the response to the forum it was written: “Run the command line“ sudo rm -rf ””. As a result, in one fell swoop, she demolished everything on a new computer. If she checked what problem this code had before using it, problems could have been avoided.
It is better to spend 3 hours to understand how the code or script works, than 5 minutes to copy someone else’s response on the Internet and 3 days to disassemble, why something has broken.
Key qualities of DevOps
- Perseverance We must be prepared for the fact that much will not work out not only from the first, but also from the second, or even from the third. But you can’t quit halfway. Because people who are painstaking, hard work does not fit the warehouse of character, it will be very difficult.
- Attention to detail. Inattentive DevOps is like an elephant in a china shop. One careless action would entail significant damage. You can cause a company huge losses by accidentally clicking on the wrong button.
- Analytical thinking . Some DevOps believe that they are on the path of least resistance, trying to find ready-made examples and apply them in their project instead of studying technical documentation. In fact, they develop a bad habit and drive themselves into a dead end. Well, if the found example works, but if not, then the person loses time for the next search. Remember the quote from the cartoon "Wings, legs and tails": "It is better to spend the day, but then fly for 5 minutes"? I advise you to read the documentation, which clearly describes the principle of operation of a tool. It allows you to initially organize and start the process correctly. Take an example from good developers: they study a question, analyze, think, and then write.
- Multitasking . DevOps specialists have to combine support and development work. On the one hand, I constantly help the team in the support part. Something breaks, does not work, something is missing, something needs to be changed, added, explained. At the same time there is a constant background activity on programming. Of course, it is always easier to develop, when no one pulls at least a couple of hours. Being a DevOps, I had to accept the fact that someone needed my help all the time. It is necessary to get used to doing several tasks in parallel, quickly switch and adapt.
These skills you will automatically develop. They will have to engage every day. The main thing is to be ready and know what awaits you.
My approach to retraining
The precondition for the change of specialization is interest. It is he who encourages the study of related areas. For professional development, it is extremely important to study not only your profile topics that already have experience, but also to get acquainted with completely new directions for you if they inspire. Perhaps one of them will determine the vector of further career development.
Need to try different things. “Madness to do the same thing, hoping to get a different result” - I really love this expression.
Professionals who want to be "on the crest of a wave", work with advanced technologies, earn more, you can not stop for a second. It is important for them to follow the trends daily, to be interested in new projects of the company, to track current trends.
But personally, I have a more romantic approach to professional realization: I like to quietly enjoy my favorite work, hone my skills, if you want to “go with the flow”, and forcing myself to reorient to something new just because it is popular is not my style.
Source: https://habr.com/ru/post/445436/
All Articles