# # # training
Sometimes delegating power makes people vomit blood. If you have to do everything by yourself, you will be very tired, but if you don’t come by yourself, you always feel uneasy. At this point, it’s best to train one or two people, depending on the team. Brainwash them, share all their current experience and knowledge with them, preferably so that they can surpass me, replace me or even get rid of me. Why not all people, just like the master and apprentice in Journey to the West, many people are sand monks, don’t tell me what values what sense of mission what later, I like to go to work on time and get paid on time, welfare can be divided into me what else don’t pull with me. It’s awkward when you have to spend a lot of time and a lot of it is determined by experience, but the team can’t do without them. Therefore, when the project is not urgent, the one-year experience in the interview is no different from the three-year experience. It depends on your learning style and attitude, and your pursuit of knowledge, because I don’t need you to do anything at the beginning. In order to improve the efficiency and stability of team members, you also need to take out 20% of working time for training and communication, as code farming system, you told me to speak, speak a lot of all don’t replace the we are going to write code line by line, the most direct way is to get them done faster and better, if can than IOS development cycle is short, more stable program, they will be very happy, Of course, this requires the accumulation of knowledge and experience. There are three things we usually do during this time: task completion, technical implementation plan discussion, study and lecture.
# # # development
As long as you are a team member, you should not leave the code and documentation and just do architecture drawings or let others do it instead. Let alone what others think of you, just take the system as an example. When you need to put out a fire later, someone else leaves. As the person in charge of the system, he must personally lead and participate in the construction, so that he can have enough ability to take on this responsibility. So you have to spend half your time on development at first, so the first thing you do at work is put your phone in a drawer and physically insulate it, then open your IDE and start coding. There’s no need to write everything:
1. Design and build architecture
This is the most important step, and very tedious, do not draw the design drawing on the code of the technician, the more to the back of the more miserable, and miserable not, of course, if you like sewing, like overtime every day nothing, I do not believe that so many things you can remember all in the head, strange strange. For the rest of the team, architecture plays a decisive role in collaboration, quality, speed and ease of development. You can focus more on code architecture, a lot of people like to focus on runtime architecture, but runtime architecture is a must. The code architecture is a more stable design solution. Once there are some small requirements changes, the operational architecture will definitely change, but the big direction usually does not change frequently, so we can organize the code according to the big direction and divide the modules. So you can’t mess this up, because if you mess it up no matter how you adjust it, it’s going to be a big problem.
2. Difficulty key development for part of the code that is difficult to implement we still have to do it ourselves, in some small and medium enterprises, if you let others do it, you will end up in trouble. The code with lower quality will cause faults and bugs, and once problems occur later, it will consume more time and cost. Originally, we have to fight fires everywhere, which will lead to working overtime every day and not getting out of the project. Some members often do not have that ability. If you ask them to implement the function, it may lead to the function being realized, but the controllability is not high. Once the demand changes slightly, various problems will occur. In large companies, teams tend to be highly qualified, which is rare, but the core code is best done by ourselves. 3. All kinds of fire fighting
The architecture part of the code is often the most prone to problems, as the requirements constantly change sometimes need to adjust, serious bugs may appear, sometimes also need to prevent members copy your code to start all over again, when you change the code to change multiple places is also more troublesome. Other members of the team often have bugs in their code, and they can’t fix them themselves. Of course, the process of finding questions can also improve your skills. The key is to teach yourself and your team members how to use various diagnostic tools and how to think and analyze problems.
### Manage and learn
1. Code reviews need to convince the team that code reviews are about improving the ability of the team as a whole, not about checking “checkpoints” for individuals. In addition, code review itself improves the ability of developers to learn from their own mistakes and from the thinking of others. If the developer has resistance or aversion to the process, this purpose is not achieved. If a problem is found during code review, it is not recommended to use this method to punish the person found. Bugs are inevitable in software development, and being overly demanding is inherently perverse. Worse, code reviews are of little value if they create a fear of accountability and a lack of motivation.
2. Progress review and task assignment
Task allocation is a big problem, and it is a powerful job. When faced with a task, members often cannot arrange their time properly and rationally. If you can’t get out, there will be several reasons, such as being busy, delaying the task or working overtime, and finally delaying the whole project. How to avoid this situation can not let the team members do it separately, we have to have a set of task breakdown, task description and time allocation principles, risk management and planning, first of all, we can do things well, and then we can share it with the team members.
Interviews and meetings
Prepare a discriminating written test. There are a lot of unreliable people who claim to have years of experience. But you ask him to write a countdown and he can’t write a countdown, and we’ve sent a lot of people away with that. Bosses don’t pay me to talk to them, so I usually ask about four areas: source code, design patterns, optimizations, and the NDK. For fresh graduates, I tend not to pay special attention to technology, also do not need him to achieve a variety of functions, a lot of things I can write for you to adjust. Therefore, I pay more attention to learning attitude, motivation, listening to arrangements, and avoiding trouble, which HR is often more accurate than us. We can boycott some meetings and not go to them if we can. In particular, departmental communication is a bullshitter’s paradise. Testing, production, and design are far more bullshit than programmers. If there’s another feature waiting to be written, it’s going to hurt. At this point you can just send someone over and come back and tell you what’s going on.
When we stop learning, we basically die. Putting our mobile phones in the drawer is also for us to learn when we are free. Generally, I choose to write more articles, participate in technical salons and communicate with others, and look at other people’s framework source code on weekends. Anyway, everyone has a basic understanding of my status, and I will do live sharing for everyone on Saturday and Sunday night. Only in this way can I improve myself, only in this way can I control the project, only in this way can I influence the team members rather than by saying, of course, what needs to be said.
Although we are not there yet, it is important to learn to think like a technical director, to be positive, to learn, to think, to work hard, to be altruistic, day, day up!