Do technical leaders want to write code?

Do technical leaders want to write code? This is a problem.

I just heard when I was working, the programmer (at that time there is no "yard farming" argument) is to eat youth rice, to 30 years old can not endure the night to write code, so to the early transfer management. Correspondingly, if you embark on a management route as a technical leader, you naturally do not have to write code for this low-level repetitive manual work. So at that time, I wrote a lot of code, technical ability to grow quickly, but always feel a bit awkward. It feels like, you can drive fast and skilled, and finally just to arrive at the airport on time to catch the plane. Then you'll never have to drive again.

But in any case, catching the plane seems to be a more advanced choice, for it, to abandon the painstaking training of the driving can also accept.

But when I really came to the management post, I found that the truth and I think completely different. At that time, the company's business growth was rapid, supporting the business of the system is a few years ago, "affair" outsourcing project, but also the technical team's personnel composition and work habits are still in the workshop state. From my point of view, looked is a big pit, pits speed is very slow to people worried, in the process also often dug a new pit ... In my career, I have never written so much code in such a short time. A few years later we looked at the submission rankings, my name still first. Fortunately, my efforts were not wasted, the system finally did not collapse, smooth back to the right track.

Was it true that I was a technical leader who had spent a lot of time writing code, excluding hiring, setting processes, doing operations? If is right, later I did not write so many code, as if also with "incompetent leadership" missed, even praised "resist let subordinates go to work, exercise the organization", this is how to go?

I've been thinking about this for a long time, and I've found a lot of different things to say about you. Some people certainty "do not write code good leadership is not good leadership, because only their own code to write the heart of the bottom", but also some people categorically "when the leader also write code is sorry company, the company sent you to lead the salary is not let you knock code."

Everyone's views are incompatible, so perhaps there is no unified answer to this matter, only to return to the specific question to have the answer. What I can be sure of is that in the circumstances I was in, I would be paralyzed by not writing my own code system. But out of view, can not say "leader to write code" is universal. So can only specific problems specific analysis, the following talk about my "specific" view.

The first thing to be sure is that writing code is not a disgrace. In order to calmly rational discussion, we should abandon those natural with strong emotional color words, such as "yards", also should pay attention to remove other tinted glasses. In our time, the complexity of the algorithm, and then the delicate system, you must enter a line of code to achieve. This is like writing an article, the person who writes well, also has to have a word to knock out the article.

In fact, this metaphor is not so appropriate, knocking on the keyboard is a "standardized" process, there is no "typing quality" problem. Writing code is more like "creative", such as multiple programs, with the same input and the same output, but how many exceptions can these programs handle, how stable, how inefficient, and leaving the code is hard to find. Because the quality of the program depends largely on the implementation of the Code, writing code is a necessary part of the work, writing good code is a very worthwhile goal.

Second, technical leadership is not a "superior" role. Software "Soft" is that it is invisible to touch, many times can not be copied from the real life model, only by thinking and experience to grasp. Technical leaders shoulder a greater responsibility, they should have more profound experience and more rigorous thinking, to ensure the effectiveness of software development. Thin professional experience coupled with the power to dictate, such a combination in other industries may be able to lead, but at best in the software development industry can only be born incompetent technical leadership. In "How Google Works", Eric Schmidt writes that Google needs "creative elites" who have both leadership and ability, and I think they are the best candidates for technical leadership.

Since "Write code" is not embarrassing, "technical leadership" is also not superior, there is no need to oppose the two. So we might as well broaden the horizon to see the more important question: what should the role of technology leadership be?

To be sure, technical leaders lead the technical team, so be responsible for the work of the entire technical team. Below we use a simple model to analyze the work of the technical team.

A is a very good programmer, write code speed is 2, is the average programmer twice times, the code quality is 1.5, is the average programmer 1.5 times times. He is more satisfied with his condition, and thinks that "development is the way to go". Indeed, his productivity is 3 times times that of average programmers (2x1.5), and he's really good.

The performance of a has been affirmed by the superior, so promoted to technical leadership, leading 3 ordinary programmers to develop programs. If everyone's work remains the same, then team productivity is 2x1.5 + 1x1x3 = 6.

But when a is promoted to leadership, it is necessary to spend a lot of time doing things outside of the code and not maintaining the "personal contributor" role. Assuming that he spends half his time doing other things, and the code quality remains the same, his productivity is reduced to (2x0.5) x1.5 = 1.5,a productivity drops a lot.

A remember that you are not a "personal contributor" now, so you should be concerned about the productivity of your team. If the team's productivity does not change, then the entire team is (2x0.5) x1.5 + 1x1x3 = 4.5. This is almost the worst case in which technical leaders are not able to contribute to the trivial, and the productivity of the team is reduced.

However, if a reduces the time it takes to write code to 0.8, it will be different when the time saved is used to develop specifications, cut down unreasonable demands, enliven the team atmosphere, and so on. Suppose A has a series of arrangements that increase the write code speed of the other 3 programmers to 1.3 and the code quality to 1.3.

For technical leaders of many technical backgrounds, this state is often not satisfactory, because it is not easy to read the code written by other programmers. However, the productivity of the team became 0.8x1.5 + 1.3x1.3x3 = 6.27, which was higher than the original 6.0. The improvement of team productivity is the company's expectations and standards for leaders. So the technical leader may not be satisfied, but he is competent.

This is the truth I have said in the subject of leadership, people or tasks. The object of leadership is neither a simple person nor a simple task, but an artificial medium to drive team members to accomplish more complex tasks.

So if you are a programmer from a technical leader, be sure to differentiate between "yourself" and "team", you have to consider not how to write faster and better, but how to make everyone write faster and better. As long as you can continue to improve the productivity of the entire team, you are competent, even "can't see" Other people's code, you have to endure.

In the example above, if you can increase the speed of writing code to 1.5 for the remaining 3 programmers, the code quality is increased to 1.4, and the total productivity is 1.5x1.4x3 = 6.3. This time the technical leadership line of code is not written, and the level of the subordinate writing code is still not up to their own, the productivity of the team is a certainty of the fact-of course, you have other methods, such as the optimization of the combination of people with their own productivity and even higher than their own programmers, this is more efficient.

Of course, "a line of code is not written" is mostly ideal, many times the technical leadership still must write code, because the software development is the craft of the end, we agree is also the craft. So there is a good chance that the team lacks the experience or ability to develop a particular aspect of development, and that no one can deal with it except technical leadership, or that a programmer is unconvinced or does not understand a decision, cannot use a title and can only use the code to persuade and explain ...

In addition to these "must" situations, I also advocate that technical leadership "should" write code. Software development The industry is too young, the level of isolation can not be so good, just say not to write is not found feeling, and many technical decisions based on this feeling. So every time I take over new projects and teams, I usually have to look at the code all over the bottom of my heart, I submit a few functions to find the feeling.

Thus, there is no unified answer to the question of "technical leadership should not write code". So sometimes you have to resist the urge to "let me Write," and at times you have to resist the nausea.

Personally, I think technical leaders who write code and are reluctant to give up coding skills are cuter. Programmers are mostly simple, write code together, even if only a few functions, will also tell everyone, "I am not to give orders, but with you."

From: www.luanxiang.or

Do technical leaders want to write code?