Different attitudes in development determine different aspects of the project

It has been half a year since I started working, and I have experienced many things, such as the merger and splitting of departments. Every turmoil has benefited me a lot, whether good or bad.
     When I first came to the department, the department was still in a stage of steady growth. This stage is a sweet period, and it is also very sufficient for the training of newcomers. Some new modules or function points will be given to do it, and the development tasks are not very rushed. , the demand is very clear, and the department basically does not work overtime. At that time, I hadn't graduated yet, and I just came in for an internship. I was looking at the source code, doing function previews, and still learning a lot.

      The good times did not last long. After half a month, the department was merged by other departments, and it was abruptly required to produce a whole thing within a month. As a result, the progress of the project was very fast, and the speed of one version every day was issued, and it was originally for the purpose of In pursuit of speed, when merging, it is also abruptly combining two different projects, and then continuously adding and modifying them. Such a result naturally leads to the continuous occurrence of bugs, and new functions are continuously sent out while bugs are constantly being fixed. . .

       Four months later, the division was split again because the combined effect was so poor. . .

       After the split, I went to another department and changed a team leader. The two team leaders have completely different styles of doing things, which left a deep impression on me.

       The first group leader is the type that just asks to get things across quickly. He will ask us to run as long as we can. As for optimization, we will consider it later. In the end, no optimization is done, because there is no time later. . . He would give people a task, and then set a deadline. When he needed it one day, he would come over and ask people for it. No matter what he did, he would gather in, and he would gather without testing. . . Usually when the task is not in time, I leave on time. When it comes to the release, I get nervous again, because there are a lot of problems at this time, and the product manager will suddenly come over to change the requirements when the release is released, so it causes one side change. A situation where bugs are made while making new requirements. . . What impressed me is that every time it is released, I always hear the words: how can there be so many bugs. . . At that time, I felt really tired, because the project schedule was tight, and he would not hand over too important things to new people. All he did was tinkering, and there were basically no comments in that pile of code. Hard-coded things do not pay attention to the naming of variables and methods, and the readability is very poor. The original design is good, but after many people's encapsulation, it becomes a bunch of incomprehensible things. . . In the face of such a situation, I have told the team leader, but the team leader's opinion is: don't move what can't move, let it stay there, even if it's really bad, but it can run now, and Every time I ask him some questions, he will immediately throw out a solution and let people follow suit. In fact, I just want to know where the class file of that function is. I listened to him talk about a lot of things, and I still ignorantly took a solution he gave to do it. . .

      The actual effect is: Usually, everyone has nothing to do. When it comes to the release, they work overtime and work hard. In the end, the release is helpless. too much. . .

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

      The second group leader belongs to the kind of strict control, but allows his subordinates to play to a certain extent. He will hand over new tasks and new requirements to new people, and then organize experienced people to refactor and open two branches. Moreover, they are required to work overtime on Tuesdays and Thursdays, and they can leave after finishing the work at hand. His argument is: I usually work a little overtime and do things better, so I don't have to rush so much later. When the results were published, he basically did not work overtime. I usually work overtime, but it's not very late. I spend about an hour longer than normal get off work to sort out the progress and work. He doesn't dictate much about other people's work, but he will set a date, and then leave it to the person who takes the task, whether it is a novice or a veteran, but each time he will explain the final requirements he wants to meet. What he often says is: I only give you the task, how to do it is up to you, but you must ensure that the effect I want is achieved within the specified date, even if you work overtime. He also requires that every time a new module is written, it must be ensured that it is independent, detachable, and that the documentation comes first. must be noted.

       The actual effect is: usually everyone has something to do, and they can also ensure performance while meeting new requirements. Every release is no problem, and the progress is significantly faster than my previous team leader.

       That is, different attitudes lead to different faces of the project.