Different Attitudes determine different aspects of the project

I have been working for half a year since I was released. I have experienced many things, such as the merger and splitting of departments. Every turbulent job has benefited me a lot, regardless of whether it is good or bad.

When I first came to the Department, the Department was still in a steadily rising stage. This stage was a sweet period, and it was also very good for new personnel, some new modules or functions will be provided, and the development tasks are not very busy, the requirements are very clear, and the departments basically do not work overtime. At that time, I had not graduated yet. I just came in for an internship. I was reading the source code, previewing functions, and learning a lot.

After half a month, the Department was merged by other departments. The requirement was to generate a whole task within one month. As a result, the project progress was very fast, the speed of a version is growing every day. In the initial pursuit of speed, two different projects were merged, and then added and modified continuously. Such a result naturally leads to bugs that are constantly corrected, and new features are constantly released...

After four months, the Department was split again because the effect after the merger was too bad...

After splitting, I went to another department and changed my team lead. I was deeply impressed by the different style of the two leaders.

The first team lead belongs to the type that only requires fast communication. He will ask us to run it as long as we can. As for the optimization, we will consider it later, and we will not do any optimization, because there is no time in the future... He will give a task to a person, and then he may not have a deadline. When he needs it one day, he will come and ask for it. No matter what he does, he will gather it, all tests are complete... When the task is not busy at ordinary times, I leave on time. When I get to release the version, I get nervous because of a lot of problems, the product manager will suddenly run to change the demand at the time of release, which leads to a new demand while changing the bug... I was impressed by the fact that every time I published a version, I always heard this: how can there be so many bugs... At that time, I felt really tired. because of the tight schedule of the project, he would not give too much important things to new people. All the things he did were repairs and supplements, then the heap of code basically didn't write comments, a lot of hard-coded things, and did not pay attention to the naming of variables and methods. The readability was very poor. The original design was good, but it was encapsulated by many people, into a bunch of things that are hard to understand... In the face of such a situation, I have told the team lead, but the team lead's opinion is: Don't move anything, let it stay there, even if it is really bad, but it can run now, every time he asks him some questions, he will immediately throw a solution to let people follow suit. In fact, I just want to know where the class file of that function is located, the specific code hasn't looked at yet. I have to listen to him talking about a lot of things. I am still confused about how to do it with a solution he gave me...

The actual effect is: at ordinary times, everyone has nothing to do. When the version was released, they worked hard to work overtime. Finally, they could not help but release the version. After the version was released, they continued to change the bug the next day, because there are too many bugs in the released version...

Reference: www.yxkfw.com Game Development Network's best game programming development technology website.

The second leader belongs to those who have strict control policies, but he is allowed to give full play to his team. He will hand over new tasks and new requirements to new people, and then organize experienced people to restructure and open two branches. In addition, it is required to work overtime on Tuesday and Thursday, so you can leave after you finish your work. His statement is: I usually work a little bit on duty to do things better, so I don't need to rush in the future. When the result is released, he basically does not work overtime. I usually add some classes, but it is not very late. It takes about an hour to get off work and sort out the progress and work. He doesn't mean much about other people's work, but he will set a date, and then hand it over to the person who gets the task, whether it's a newbie or an old bird, but each time, it will indicate the requirements that he will finally meet. What he often said is: I only give you the task, and it is up to you to decide how to do it, but you must ensure that the effect is achieved within the specified date, you have to work overtime. He also asked every time he writes a new module, he must make sure that it is independent and can be extracted, and the document must be written first, and there are requirements for annotations, specify who has written and changed.

The actual effect is that everyone has something to do at ordinary times, and can ensure performance while creating new requirements. It is okay for every release, and the progress is significantly faster than that of my former team lead.

This means that different attitudes lead to different aspects of the project.

Different Attitudes determine different aspects of the project