Why be an implementation engineer

Four years ago, I saw a job placement engineer. From the phrase “implementation engineer” I could only make a very general conclusion about what this specialist does. 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 matched well, and they called me to work.
As it turned out later, the concept of “implementation engineer”, like the “programmer”, unites a lot of different, but related things. All implementers somehow install and customize “something” to the requirements of the end customer. But there are so many areas of implementation that it seems impossible to paint 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, then an engineer for the implementation of any software, because the scope of the introduction of "iron" for me is a dark forest. I also draw attention to the fact that my personal experience can be quite one-sided.

1. Man Orchestra

This is perhaps the main reason. If you do not feel in yourself the desire to become a guru of some narrow specificity, then an implementer is destiny for you. I work with people who at some point realized that they are not interested in diving into MS SQL subtleties to the MCSE level (in this place you can substitute any technology and the Jedi level for it). And this is not “laziness”, but an informed choice.
For the engineer, it is important, in addition to the knowledge of the product being introduced, to possess quite extensive knowledge in all the contacting areas. And also in all potentially contiguous areas. We have, for example, in addition to the maximum knowledge of the program being implemented, a good level of C # and T-SQL, basic administration skills of server Windows and knowledge of all “exotics” like XSLT and VBS are mandatory. And wishes that the engineer can know, you can write up a roll of toilet paper in 54 meters: this is 1C, and Adobe FlexiCapture, and InfoPath, and knowledge of any ERP, SED, and so on and so forth.

2. The director himself

In small projects, often, the entire technical part is performed by one engineer. He thinks over the architecture of the solution, and sets it up, and writes code, and conducts the delivery to the technical specialists of the customer. In large projects, the engineer is given a module, in which he, again, is himself-the-director. Those. excluded situations where you did everything well, and your colleague nakosyachil, because of what did not take 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

The implementation most often goes according to the standard cycle: collected requirements, done, passed, start over. And each stage of this cycle is rather short, therefore situations are excluded when you can saw a module, and only after two years to see its actual use. Here, the result of your 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 that is necessary.

4. Living people

This is quite a controversial point for IT people, whom everyone used to be considered closed and unsociable people. In reality, a lot of people who can and love to communicate with the customer work in the IT sphere. In the case of an implementer, such a need will also be satisfied: at the stage of delivery of the work, you will have to communicate with the customer's IT staff, explaining what you have done to them and how to support this further. And also run on end users, helping them to cope with errors that you made during the development phase (or just explain why clicking the Create Task button leads to the creation of a task). It may not sound so much fun, but in reality, communication with users is quite interesting.
From the same point grows the following:

5. "I baked it myself, and eat it"

You get feedback on the results of your work first hand and, most importantly, you can influence it. Those. it is enough for the user to show any convenient feature, or to fix some inconvenient functionality in front of his eyes, in order to get a “friend” who is protecting your program in front of the manual. That will positively affect future projects.

6. All roads are open.

The last point, which partly contradicts the first one: due to the fact that you are a semi-expert in a large number of different areas, at any moment when you get tired of implementing a particular product, you can choose the path of a narrow specification in one technology management (team lead) or normal management (project manager). You will have enough knowledge to start, and the experience of project work is rather highly valued in the market, and also by your immediate supervisor.

For now, perhaps, everything. I tried to write briefly why this work might interest someone. And if in the mind of a student after this article, the thought appeared to try himself as an implementation engineer, I would be very happy.
If you have any questions, write, I will try to answer.