October 3, 2014 at 10:10Why be an implementation engineer
Four years ago, I saw a job as an implementation engineer. From the phrase "implementation engineer" I could only make a very general conclusion, what this specialist is doing. But since the requirements indicated the knowledge of C # and the need to write code, I decided to try myself in this role. The stars coincided successfully, and they called me to work.
As it turned out later, the concept of an implementation engineer, just like a programmer, combines a lot of different, but related things. All implementers in one way or another install and configure "something" to the requirements of the end customer. But there are so many areas of implementation that it seems impossible to describe the specifics of each.
In this article I will try to describe why you might be interested in becoming an implementation engineer. To be more precise, it’s an engineer for the introduction of any software, because for me the sphere of introducing hardware is a dark forest. I also draw attention to the fact that my personal experience can be quite one-sided.
This is perhaps the main reason. If you do not feel in yourself the desire to become a guru of some narrow specificity, then the rover is fate for you. I work with people who at some point realized that they were not interested in diving, for example, in the subtleties of MS SQL to the MCSE level (in this place you can substitute any technology and the “Jedi” level for it). And this is not "laziness", but a conscious choice.
It is important for the engineer, in addition to knowing the product being introduced, to possess rather extensive knowledge in all areas of contact. And also in all potentially adjoining areas. For example, in addition to maximum ownership of the implemented program, a good level of proficiency in C # and T-SQL, a basic skill in administering server Windows, and knowledge of any “exotic” like XSLT and VBS are mandatory. And with wishes that an engineer can know, you can write a 54-meter roll of toilet paper: this is 1C, Adobe FlexiCapture, InfoPath, and knowledge of any ERP, EDMS and so on and so forth.
In small projects, often, the entire technical part is performed by one engineer. He thinks through the architecture of the solution, and configures it, and writes the code, and conducts the change to the customer’s technical specialists. In large projects, an engineer is given a module in which, again, he is a director of his own self. Those. there are no situations when you did everything well, and your colleague screwed up, because of which you did not accept all the work, well, or you got a terrible architecture, with which you have to put up and saw crutches under it. All by himself and only by himself.
Implementation most often follows the standard cycle: collected requirements, done, passed, start over. And each stage of this cycle is quite short, so situations are excluded when you can saw some kind of module, and only after two years see its real use. Here, the result of his work, as well as its application in life, can be felt 3 months after the start of work. Either you did everything cool and comfortable, and the customer uses it, or your work was meaningless. For lovers of quick results, what you need.
This is a rather controversial moment for IT people, whom everyone is accustomed to thinking of as closed and uncommunicative people. In reality, a lot of people work in the IT sector who can and love to communicate with the customer. In the case of an implementer, this need will also be satisfied: at the stage of delivery of work, you will have to communicate with the customer’s IT staff, explaining what you have done to them and how to maintain it further. And also run around end users, helping them to cope with the mistakes that you made at the development stage (well, or just explain why clicking the "Create a task" button leads to the creation of a task). This may not sound like much fun, but in reality, communicating with users is quite interesting.
From the same point, the following grows:
You get first-hand feedback on the results of your work and, most importantly, you can influence it. Those. it is enough for the user to show some convenient feature, or to fix some uncomfortable functionality before his eyes to get a “friend” protecting your program before management. Which will positively affect further projects.
The last point, which partly contradicts the first: due to the fact that you are a semi-specialist in a large number of different areas, at any time when you are tired of implementing a specific product, you can choose the path of a narrow specification in one technology, technical management (team lead) or ordinary management (project manager). You will have enough knowledge to start, and the experience of the project work is rather highly appreciated in the market, and by your immediate supervisor too.
That's all for now. I tried to write briefly why this work might interest someone. And if in the head of any student after this article there was an idea to try myself as an implementation engineer, then I will be very happy.
If you have any questions, write, I will try to answer.
As it turned out later, the concept of an implementation engineer, just like a programmer, combines a lot of different, but related things. All implementers in one way or another install and configure "something" to the requirements of the end customer. But there are so many areas of implementation that it seems impossible to describe the specifics of each.
In this article I will try to describe why you might be interested in becoming an implementation engineer. To be more precise, it’s an engineer for the introduction of any software, because for me the sphere of introducing hardware is a dark forest. I also draw attention to the fact that my personal experience can be quite one-sided.
1. The orchestra man
This is perhaps the main reason. If you do not feel in yourself the desire to become a guru of some narrow specificity, then the rover is fate for you. I work with people who at some point realized that they were not interested in diving, for example, in the subtleties of MS SQL to the MCSE level (in this place you can substitute any technology and the “Jedi” level for it). And this is not "laziness", but a conscious choice.
It is important for the engineer, in addition to knowing the product being introduced, to possess rather extensive knowledge in all areas of contact. And also in all potentially adjoining areas. For example, in addition to maximum ownership of the implemented program, a good level of proficiency in C # and T-SQL, a basic skill in administering server Windows, and knowledge of any “exotic” like XSLT and VBS are mandatory. And with wishes that an engineer can know, you can write a 54-meter roll of toilet paper: this is 1C, Adobe FlexiCapture, InfoPath, and knowledge of any ERP, EDMS and so on and so forth.
2. Director himself
In small projects, often, the entire technical part is performed by one engineer. He thinks through the architecture of the solution, and configures it, and writes the code, and conducts the change to the customer’s technical specialists. In large projects, an engineer is given a module in which, again, he is a director of his own self. Those. there are no situations when you did everything well, and your colleague screwed up, because of which you did not accept all the work, well, or you got a terrible architecture, with which you have to put up and saw crutches under it. All by himself and only by himself.
3. Five-year plan in two years
Implementation most often follows the standard cycle: collected requirements, done, passed, start over. And each stage of this cycle is quite short, so situations are excluded when you can saw some kind of module, and only after two years see its real use. Here, the result of his work, as well as its application in life, can be felt 3 months after the start of work. Either you did everything cool and comfortable, and the customer uses it, or your work was meaningless. For lovers of quick results, what you need.
4. Living people
This is a rather controversial moment for IT people, whom everyone is accustomed to thinking of as closed and uncommunicative people. In reality, a lot of people work in the IT sector who can and love to communicate with the customer. In the case of an implementer, this need will also be satisfied: at the stage of delivery of work, you will have to communicate with the customer’s IT staff, explaining what you have done to them and how to maintain it further. And also run around end users, helping them to cope with the mistakes that you made at the development stage (well, or just explain why clicking the "Create a task" button leads to the creation of a task). This may not sound like much fun, but in reality, communicating with users is quite interesting.
From the same point, the following grows:
5. "I’ve baked it myself, eat it myself"
You get first-hand feedback on the results of your work and, most importantly, you can influence it. Those. it is enough for the user to show some convenient feature, or to fix some uncomfortable functionality before his eyes to get a “friend” protecting your program before management. Which will positively affect further projects.
6. All roads are open
The last point, which partly contradicts the first: due to the fact that you are a semi-specialist in a large number of different areas, at any time when you are tired of implementing a specific product, you can choose the path of a narrow specification in one technology, technical management (team lead) or ordinary management (project manager). You will have enough knowledge to start, and the experience of the project work is rather highly appreciated in the market, and by your immediate supervisor too.
That's all for now. I tried to write briefly why this work might interest someone. And if in the head of any student after this article there was an idea to try myself as an implementation engineer, then I will be very happy.
If you have any questions, write, I will try to answer.