Self introduction
Hello everyone. First of all, before I start, I would like to introduce myself. My name is Yixiao, and you can also call me Xiaoshu. He is a Java programmer who is good at coding and loves to write code. Of course, this is also my current idea, and I may also think about writing in other languages later. After the introduction was completed, I simply wanted to record my development life in this way. It can also be considered as a way for other friends who want to enter this industry or work in different fields of this industry to see what my field is like.
Beginning of text
Regarding this topic, I thought of a saying that life is like a movie, but there is no rehearsal and it is broadcast live every day. So regarding the way of recording this kind of life, I want to give it a name and call it "Yixiao's Large-scale TV Series" and present it to everyone in the form of a weekly summary. Of course, I also want to record the traces of my own growth. Then the director and actors of this drama are relatively single, it’s me, Shu Yixiao, hahaha.
This week I completed the basic development of the performance interview module, but there are still many problems. Of course, from this, I also made some practical summaries and experiences of the knowledge I learned that I would like to share with you below. .
time
August 28, 2023-September 1, 2023
This week’s work summary
Completion
This week is the first module I have taken over in my formal development career, and I have completed the development of the basic process of the performance interview module. The process targets the three major roles of performance specialist, performance manager, and performance employee. Mainly complete the process development of employee assessment. There are still 11 bugs after get off work today. I feel like people are like avatars. I have to work overtime.
Problems
Due to the unclear understanding of business concepts and the current implementation of the management employee module database design, confusion occurred when I used code to implement the business logic when everything was started. What was originally written was to start the process based on the field corresponding to whether to assess or not and the performance manager in the assessment relationship table. However, due to unclear understanding of performance part-time jobs, they mistakenly believed that performance part-time jobs were performance managers and department heads were direct superiors. The original correct logic is to go directly to the assessment relationship table to find the employee to be assessed in the unit based on the unit code currently logged in, and then to find the employee's performance manager based on the employee to be assessed and then generate a to-do information and transcripts of their interviews. However, I changed the correct way of writing the first version into searching for the departments under the unit based on the unit code of the current login, and then based on the person in charge of the department, and then based on the person in charge's code to find out who belongs to him and needs to be assessed. So there are several problems here.
Question 1: According to my wrong way of writing, the performance manager also started the to-do after finding it, which is equivalent to me also giving the interview data record, but in fact it is not needed because the assessment object of the entire interview module is the employee.
Question 2: The interviewer in the performance interview has the business attribute of whether to be evaluated, and at the same time, there is also the attribute of whether the department is evaluated. The two are two concepts and are not directly related. Simply put, just because a department is not assessed, it does not mean that employees under that department are not assessed. Therefore, when negotiating with the product, there was a deviation in the understanding of the business concept. The product said that it would directly recruit people from the department for assessment, and it would be whoever was selected regardless of whether they would be assessed. As a result, when the final product was about to be written, it was asked to do so. Appraisal can only be started after appraising employees. Such verbal descriptions end up being unclear, leading to problems.
Question 3: It is undeniable that the product itself does not have a clear and in-depth understanding of business knowledge for the module it is responsible for, which leads to problems when describing related concepts. Then, because I am constantly accumulating my understanding of this business, I have not implemented it into documents. Or sometimes the description in the document is not very clear. For example, if the latest cycle is needed, there is ambiguity in what exactly the perceptual latest refers to. Different people have different understandings. For example, there is a description in the document from top to bottom and from near to far according to the cycle. The assessment cycle is divided into years, quarters and months. How this manifests itself is not described in detail.
Improvement points
-
In response to the first point above, I think we can start from the following points:
The first point: First of all, the problem must be to find the cause within yourself and strengthen your language communication skills. For this reason, I bought a general book "Nonviolent Communication". Sometimes there may indeed be a problem with the product design, but I cannot deny his design directly. Take a tactful approach and ask other senior developers to see if there are any problems with the design.
Second point: Before taking over a new business module next time, the product must provide a summary document of functional design in advance. Otherwise, I will directly demonstrate to you what the prototype diagram looks like without having a preliminary understanding of business knowledge. If you look at the prototype diagram he demonstrates to you, you will not be able to understand it. Having said that, the continuity of prototype drawing is not very friendly.
The third point: Regarding the delay in the implementation of product documentation, I think it can be done by asking. When he feels that I am annoyed by asking, he will naturally write the documentation obediently. If he says that I told you why you still don’t know, then I will say that I still have to write code and conceive of technical implementation. I also have a lot of things to do, so if I forgot the document and it didn’t say it, I can only ask you.