The project company has been employed for half a year, and two months have passed, which is different from what I thought.

Benjamin
·
·
IPFS
·
The half-year experience of the last article was planned from about four months ago, and it was delayed until after half a year and two months later. what happened after that.

Continuing from the previous article , my team consisted of 17 people in total, mainly divided into two groups to be responsible for the development of two projects. Human support was dispatched according to the status of the projects. Therefore, I developed another project for about a month and a half.

The content of the project I belong to is to refurbish two existing services of the customer in operation. There are different versions developed in two years. Since the service has an open API to provide read and write data for relevant manufacturers and units, in order to maintain the input and output format unchanged, The logic of programs originally written in different languages must be clearly inventoried.

However, the steps to decipher the original program structure are quite laborious. It cannot be developed according to the format provided in the old version of the documentation because the program itself is not aligned with the document, and even the same functional structure of the documentation of the two old versions of the program is inconsistent. Which specification to implement is really troublesome.


Employees arrive in sequence, so there is a distinction between seniors and juniors, and seniors are usually responsible for more complex or influential matters. The same is true for this project, including starting multiple machines to share the load. Load balance setting, database installation, And the monitoring function of the follow-up maintenance is responsible for the senior seniors.

It happens when such seniors leave.

Unfortunately, there is more than one senior who plans to leave, so the follow-up maintenance work falls on my head. I will be responsible for this project with another senior until the end of the year, including several small functions scheduled for subsequent development and testing.

For me, the most troublesome thing now is that in order to take over the job, I need to supplement the knowledge required for this job that I didn't have contact with, including how to set the equipment, where to check when a temporary problem occurs, and how to deal with it. This is very important to me. Too much to study for an engineer who has only developed a small part of the functionality.

In addition, the internal documentation on the operation is quite lacking. In the major version update, when the to-do items listed for the day are claimed by each member, the specific implementation steps are "ask him, he knows." Through word of mouth way, or after researching the information on the Internet, find a senior to confirm whether this execution step is feasible, but there is no feasible operation step that has been verified.

To put it in a bad direction, if the official execution fails or even causes harm, it is claimed that the execution steps are confirmed with the predecessors, and the other party may respond "I didn't say that". In fact, I was recently pointed out that I developed according to the document two months ago, and asked the seniors many times about the function of the modification method. Recently, a senior pointed out "How did you do this? Who did you ask?" This was two months ago. I really don't remember who I asked at the time for two of the functions I developed, but this implies that he thinks that I am changing the specifications for convenience, and I don't even want to see the actual definition of the document. I really can't accept it, maybe I will consider going to work in the future. Keep a recorder on all the time? Protecting yourself is really important.


Therefore, on the to-do list the day before the launch, I wrote down the specific steps for the projects that I was responsible for executing and the projects that I needed to ask me how to implement, and I could refer to them when I implemented them that day.


In fact, from the standpoint of the project company, the scope of responsibility for a general case should be testing in the test environment, and after delivery of documents and programs, it is responsible for finding problems and revising when problems occur, while the management of the formal environment should be the responsibility of the client company, but now This case is not the case. For us, there may be mistakes, and the scope of responsibility has become much larger, and errors outside the program such as database settings also need to be studied.

Of course, the result of this is that I can learn more things, but to be honest, it is very tiring. In addition to killing my enthusiasm as an engineer, this job has even recently appeared "to the point of being so tired that I can't even get my original interest in the holidays". The situation is really bad.

Ask yourself "How much quality of life am I willing to sacrifice for my job?" This is not a question of money, even a salary increase is useless. The predecessors once said, "When someone wants to resign, they usually make up their minds and can't keep it." I deeply understand that if I mention my resignation, I will never regret it.


Advice obtained during psychological counseling with HR: "You should stay in the company for the goals you want to achieve. From the company's point of view, if an employee leaves the company, a suitable person can be arranged to replace him. As a reason to force myself to stay.” Therefore, it is tentatively planned to work hard until the end of the year, while carrying out daily development and maintenance, while sorting out useful notes for myself, and at the same time looking for what goals I have left behind, if I really can’t find it Resign after the year.

CC BY-NC-ND 2.0

Like my work? Don't forget to support and clap, let me know that you are with me on the road of creation. Keep this enthusiasm together!