What should the TECHNICAL director do? A person’s energy is limited, development, take people, training, management how to balance? What’s the best way to do it? The author of this article is Han Wei, who will share his personal experience with us. Han Wei works in the R&D department of Tencent Interactive Entertainment. This article is reproduced from his wechat official account (ID: Handa1740168).

Senior programmers are the most productive part of a team, but are often wasted by poor scheduling. Therefore, as the technical “head” of a team, it is necessary to have a clear understanding of the main transactional work out, while giving up a lot of management “power”, in order to improve the quality and efficiency of team development, and to arrange their own work for the main goal. Generally speaking, the technical director position consists of two main roles: master program and project Manager (technical).

Therefore, we need to clarify the division of the two positions and assign the project manager’s job to another person, who may also have the title of “Technical director” or “main engineer”, but the better it sounds.

Let me talk about their main roles and project manager roles. Starting with the main process, the real main process (cTO) should be involved in as many technical tasks as possible, the most important of which is development — producing code and documentation.

The development of

No senior surgeon ever puts down the scalpel and goes outside the operating room to point fingers. An experienced programmer should not leave coding and documentation behind and just make architectural diagrams. As the person in charge of a complex system, he must personally lead and participate in the construction, so that he can have enough ability to shoulder the responsibility. So you need to spend at least 60% of your time on development, and it’s recommended to start as soon as you get to work. Morning productivity is slow, but like any hard job, it’s hard to get started. Hello is not easy for computer slowly opened all the IDE, requirements documents, reference materials, the work plan after this pile of bad things, you are the most important step, you will find that you don’t need to look on the Internet microblogging and QQ chat to boost start working passion, and will be a certain optimization code of inspiration and motivation, Or get caught up in a complex and interesting problem and jump into development faster. Insisting that the first thing you do is start your IDE is the most important step in all of this.

Let me talk about the main aspects of development.

1. Make non-functional requirements

In general, functional requirements are a major source of frustration for developers. In fact, many projects die after release because non-functional requirements such as performance, product quality, scalability, and secondary development efficiency are not properly addressed. The master, as the most experienced member of the team, must draw on his own experience and lessons (which are often more important than experience here) and come up with his own “non-functional requirements” to ensure that the project does not collapse after release. This is a thankless task, because bosses and customers often complain that technicians are playing games, fleecing more resources or worrying too much. It may not be the main program’s job to convince these guys, but the main program must bring the problem to the table with a high degree of responsibility. The job of communication might be better done by project managers, who have a whole set of tricks for bullying and cajoling bosses and clients.

2. Design and modify software architecture

Software architecture design is critical and arduous. The technician who dares to start work without drawing is either a genius or a fool. For teams, architecture plays an irreplaceable role in many aspects, such as division of labor, risk avoidance, and quality improvement. The most important step for an architecture to avoid becoming an empty document is for someone to take control and implement it. The main program hosts the design and revision of the architecture, and hands-on implementation, so that the team is completely unable to avoid the evil people, otherwise the code will not run! By designing and revising an architecture, I do not mean that all documentation should be written by one person, but that every part of the architecture is agreed upon by the main process decision. Best, of course, these documents can be written by him as far as possible, for the “rookie” team, output the document itself means “power”, to help master cheng build personal credibility – this looks a little dirty “politics”, in avoiding team in endless wrangling, and stable members that ready to jump ship, are quite practical.

3. Development of difficult codes (key requirements)

The main program has to write code, code that everyone thinks is too risky. Some systems have high performance requirements, so he must perform the parts that are prone to performance problems, such as IO operations or designing database indexes. Some system requirements were so erratic that he had to figure out how to complete the framework code or script engine so that many of his younger brothers could follow the production people around. This type of work allows the programmer to “master” the code without having to read all the code, so that the team members don’t have to be back-up when they have to rake. As part of the team’s code development, it is also a matter of letting the architectural design take control of the system from the day-to-day work. And the host code is often approached by others, can directly educate other team members, and can also build credibility.

4. Fire fighting and pest control

This work is consistent with code development, and it is often difficult to solve urgent problems without daily development. But there is a requirement for debugging skills, such as the use of various diagnostic tools. These tools may be used less often by the average developer. The process of problem finding itself can also improve the skills of the rest of the team.

training

Training should take up about 30% of your working time. Training is not only the most important means to stabilize team members, but also the most effective means to improve team development efficiency. Tools, processes, systems, rewards and punishments are not substitutes for programmers writing code line by line. The most straightforward way is to make them do it faster and better, which requires experience and knowledge.

1. Code review

There is much to be said about code review (editor’s recommendation). But code review is also a way to “force” a style or technique, which is the truest way to “control” a system. It is also the most direct means to promote knowledge and experience. One person’s code usually doesn’t address a particularly “broad” set of problems, so reviewing just one portion of the code will benefit most of the others.

2. Review of technical solutions

What should a technical proposal be written and then reviewed is a key question. It is generally accepted that a project should be made first if the development time is more than 2 weeks. Often the technical solution is a complement or challenge to the system architecture. So the involvement of the main procedure is very necessary. However, it should be noted that there is no need to do too trivial, but to extract “key” requirements and “key” solutions for review, and these “key” is often not function, but quality requirements, such as the expansibility of the system, whether it can facilitate subsequent development and so on. Arguments may arise at these meetings, but the role of the decision-maker is unshakable. Every programmer can have his or her own opinion, but the code must work as planned, and the main program must always state this.

3. Study and lecture

If the team runs into problems, development efficiency will not be improved without new approaches and techniques to solve them. It’s like if you use cattle for farming, no matter what management you use, it won’t keep up with mechanization. The main program is responsible for constantly pushing its own technical limits, introducing and pushing the team to use newer technologies to solve problems. Incomplete and rigid thinking will eventually be abandoned by team members, and the team’s efficiency will fall behind the industry, which will directly affect the life and death of the product. Learning a new language every year may seem a bit radical, but it’s a passion you should have as a programmer.

management

Management equals power? Management equals communication? Management is equal to wenshan Huhai? Years of professional training out of the technical personnel how to do management?

The goal of management is to improve performance, and if it has nothing to do with that goal and everything to do with the title of “manager,” it’s best to leave it to someone else, including that title. The main means of management is innovation: come up with new ways to solve problems, not complicated clerical work! A professional secretary can do a hundred times better than the main process. Innovation in technical work is mainly in technical work, rather than jumping out and saying: do this, do that.

Managing more than 10% of your work time means you’re more of a project manager than a master engineer.

1. Performance appraisal

Weighing the work of others with professional opinion is a burden no one can bear. This work is often a means of distributing benefits. Similar rewards and punishments. This approach to management is not new. But in practice, technical people tend to be somewhat reserved and ambiguous about performance, because such things are difficult to clearly define. The need to judge, not measure, is the real measure of performance. If you must score, two items are enough: progress and quality on a 5-point scale. The more important thing is to tell everyone what the master’s view is, and to tell others how to do it better. Or tell the team what’s best for us to succeed (get rich, go public, win bosses and clients…). Communicating goals clearly to the team and using their initiative is the most important objective in performance evaluation.

2. Demand assessment

Perhaps the biggest headache for a technician is negotiating with customers. This matter should not actually let the technical staff to sad, there is a project manager can. Requirements assessment is more of a feasibility discussion. If the main program participates in each requirement assessment, it would be difficult for him to do so in three different ways. The correct way is for the specific development team members to attend, and the main program gives his own opinion before the meeting, or listens to the summary of the participants after the meeting. This is an important way to learn what other people do, but don’t get too caught up in it, as code reviews and project managers can help.

3. Cross-departmental communication

There’s no need to take part. Hide where you can. It’s the heaven of bickering. Leave it to the project manager, who has the expertise to make these things more effective. Just come back and ask the project manager to tell you what happened.

4. Progress review and task assignment

Again, it’s a very “powerful” job, and actually everyone knows about team members, and deciding who should do what isn’t something that takes a lot of time to think about. So it’s okay to give the project manager directional advice and let him do it. There are plenty of good developers out there who can play EXCELPROJECT or something worse than a secretary with a year’s experience. Stop beating yourself up.

5. The interview

If you really want to help, prepare a differentiated written test. There are so many unreliable people that your boss doesn’t pay you to talk to them. Let the project manager do the talking. Don’t worry if they’re not skilled enough, they’ll be better than most candidates. The guy they can’t handle is the guy they should hire. What about graduate recruitment? Just check to see if they are engaged in some professional activities. Motivation is more important than other things, and HR will be more accurate than the main program. Trust me.

6. Meetings

No good meal, no good meeting, meetings of more than six people should be resolutely boycotted. If you have a program waiting to be written, you must hate these meetings. Go with your heart. God bless you.

Finally, the project manager’s job. Project managers are like sewer cleaners. They bend down to do all the things the main program doesn’t want to do. It’s great. So why not give them a better title? Without them to handle the work, any master program would be driven crazy, or they would become project managers themselves, depriving the team of one of its most powerful code engines.

1. The progress of the

2. Resources

  • Integrate and provide various resources, such as find DBA, IT, operation and maintenance personnel, hardware, SVN permissions, test environment, benefits, weekend activities…

  • Interviews: People are the most important resource, right?

  • Resource negotiation: Usually with the boss, let others understand the real situation. Another thankless task, but it always needs someone to do it.

3. Communication

  • Requirements review: Bargaining with the demand side, the project manager is really a hard life ah…

  • Organize meetings or inform everyone in other ways: loudspeakers, loudspeakers, full-service broadcasts, world channels…

For a small company, authority, title, revenue, tend to be more sensitive. But none of this is a reason for a project to fail. A programmer called the seed said: grow up I am called managers of the tree. This false belief will only keep the seed from germinating. Software development is a surgeon’s business, not a sweatshop, so you don’t need a manager with a whip, you need a doctor with a heart.

Recommend an architecture class meeting

When business volumes explode, highly available architecture is a constant topic. Mobility, e-commerce, social networking, real estate — each seemingly different area of technology architecture suffers from the same high concurrency impact. Didi, JD.com, Facebook and Lianjia, four different industry giants, will share their own insights on high availability architecture here. Archsummit10% off the countdown, click “Read the article” to learn more.