Edit | Xue Liang
Teacher Zhang Miao has accumulated many years of experience in software engineering ability, and he has shared this topic many times before, and the overall content has been modified and adjusted.
After graduating from Dr. Zhang, he stayed in Tsinghua for 12 years, mainly doing network research, leaving Tsinghua in 2006, entering the industrial world, first doing six years of user product research and development, and then joining Baidu in 2012, has been doing network infrastructure related development work, mainly internal services, in the operation and maintenance department and system department, do BFE platform research and development. In June 2020, it moved to external services and is now doing BFE commercial promotion. From January 2018 to October 2021, he also served as the chairman of Baidu's corporate code specification committee.
The next content is mainly divided into three parts, all of which revolve around engineering capabilities. First, explain why we should pay attention to engineering capabilities; second, explain what engineering capabilities are; third, talk about how to improve engineering capabilities.
Why improve engineering capabilities
This topic has received a lot of attention in the past two years, and the current situation changes have a lot to do with it, the first important situation is that the competition in the industry has intensified, many so-called blue oceans or very blank fields have ceased to exist, everyone is competing in the same field, the competition is very fierce; the cost has risen dramatically, and now the cost of Chinese software engineers is not so big compared with the United States, according to previous exchanges, the cost of Chinese software engineers has exceeded the United Kingdom, and there is not much gap with the United States Industrial upgrading, before most of the Internet companies did is the ToC Internet, now many companies are turning to ToB, turning to ToB's requirements for software research and development or engineering capabilities, there have been very big changes.
In addition, some phenomena have also been found, and many Internet companies are now working overtime. In the past year, there was also a 996.ICU, outsiders do not know what it means, insiders know that every day at 9 o'clock to work, 9 o'clock to work, 6 days a week, and finally tired to enter the ICU intensive care unit. This year we also found some changes, many companies began to respond to the call of the state to reduce working hours and try to avoid the 6-day working day. But after reducing the time, how do we ensure the output of work? It really depends on our engineering capabilities.
I have also observed the phenomenon that many practitioners write code for a long time, even 8-10 years, but a lot of the methods are wrong, in other words, software engineers are a so-called youth meal, why? In fact, it is related to the quality of practitioners. Therefore, the above form requires our Chinese software engineers to also need to update and iterate.
The book "New Economic Momentum" discusses how China's economy can be transformed and upgraded. Under this general trend, IT practitioners or Chinese software engineers should also consider this problem, which is the four words "transformation and upgrading".
What is engineering capability
Many people recognize the need to improve engineering capabilities, but what capabilities to improve? Without the right understanding, there may be no way to start. Some people think of engineering as all about writing good code. It's true that many of our software engineers focus on or learn every day, and all they do is write code.
But the idea I want to express today is that engineering ability is not just as simple as writing good code, nor is it as simple as one person writing good code, it reflects the comprehensive quality of the team. Most of the software engineers are science and engineering graduates, and I feel that the humanities do not seem to be of much help to software work, but after more than 20 years of software research and development, I have deeply realized that doing engineering is not only a natural science, but also a humanities and social sciences. So for practitioners, you need to pay attention to all aspects of those non-technical aspects, and you will find that a lot of time you work, not spent on thinking about technology, a lot of time may involve non-technical factors such as communication, which has a very, very large impact on us, including project management, which does not seem to be directly related to technology, but the impact on research and development projects, or engineering capabilities is huge.
The definition of engineering capability comes from the Baidu Software Engineering Capability Definition, which is Baidu's internal document, written at the end of 2019, when to improve engineering capability, a document is required to explain what engineering capability is. Finally, we wrote the following sentence: using a systematic approach, under the premise of ensuring quality, the ability to continuously deliver valuable software or services to customers and users. This sentence can be disassembled into the following five points, the first is that the purpose of research and development is to provide value, the second is quality first, the third is to achieve continuous delivery of value, the fourth is to use systematic and scientific methods, and the fifth is to continuously improve the efficiency of research and development.
The purpose of software development is to provide value
The phenomenon in the industry is that many students engaged in software research and development are more accustomed to considering problems from a technical point of view, prefer to study complex technologies, and the technology is simple and uninteresting, and there is no interest in engaging. This has caused us to spend a lot of energy on very complex technology, but it has no value to society. So I also write about my point of view, the means we use in our work, including technical design, writing code and other technologies are only means, not ends. So we should not forget our purpose because we use too many means in the process of doing it.
In the software project planning phase, you need to think about it from the perspective of customer needs or business value, not after you write it completely. In addition, to establish cost awareness, we must consider the input-output ratio, to do a project should be a benefit, rather than the final gain is smaller than the cost, it is a loss. This is the first point just made, software to be able to provide value.
Quality first
This is also often overlooked, when the project is urgent, there are trade-offs and trade-offs between time and quality, sacrificing quality and reducing quality requirements. Then in the "201 Principles of Software Development" there is also a discussion of quality, the first one talks about quality first. The author puts it this way, no matter how quality is defined, customers will not tolerate low-quality products. Delivering products on time, even with poor quality, may seem like politically correct behavior, but it's short-sighted. In the medium to long term, doing so is suicide. Quality must come first, there is no room for trade-offs, and the words are very clear. If we take this article to measure our actual work, we will find that many teams are actually doing this kind of thing.
So what do we do? First, for all projects, it is first necessary to clearly define the quality requirements, quality is not absolute, and the quality requirements may vary in each scenario. So what kind of quality we achieve, this needs to be clearly defined at the beginning of the project. Second, there can be no compromises in terms of quality. As mentioned earlier, our software is to deliver value, and if low-quality software cannot provide value, the whole R&D activity becomes meaningless. Third, we also need to balance the relationship between quality and delivery time, not to reduce quality, to improve the level of technology, through technical means to be more efficient, lower cost to ensure quality, for example, we can use automatic regression methods, and even ai methods, with these high technologies to ensure quality. Fourth, high-quality software must be designed, not back-up testing, operation and maintenance assurance, which is already very late. Therefore, in the design stage, we should ensure the quality of the software design, which is very critical.
Achieve continuous delivery of software value
Observed a lot of phenomena, that is, the front of the project execution process in the front tight and loose state, the front is very invested, spent a lot of resources, and so after the software is developed, the back software no one pays attention to, will find that the design document is rotten, the code is not maintained. The reason is that we don't have a clear understanding of the entire software life cycle and value output, we only made short-term preparations, and we felt that the software development was over. So the first point is to raise awareness that software development and maintenance are long-term cycles, and a piece of software can even run for 10 or 20 years. On the basis of this understanding, it is necessary to comprehensively consider the cost of full-cycle research and development, rather than just considering the beginning of the fast, and the final cost is very high. To be prepared for long-term maintenance, and to continuously improve, a software is gradually produced through long-term iteration and long-term optimization.
This is also very, very important. What phenomena can we see? Many software practitioners in China lack in-depth learning of software development methods. I have done research, many practitioners have seen the real software engineering books, no more than two, and even some people have not read, for example, I see some lists, the use of a certain language, such as some network knowledge, these are not professional software engineering books, we can see that in China the proportion of software reuse is very low. So this point we must first realize that software engineering itself is a very professional direction, software has been born for more than half a century, these methods have even appeared in the 90s of the last century has appeared a lot of mature methods, but it is very unfortunate that many practitioners in China, these methods have not yet fully mastered. In addition, we also have to iterate at a high speed based on the excellent infrastructure we have now, and there are now cloud-native ideas, including many facilities that have been cloudized, which is very helpful to us. There is also the ability to reuse software, to establish reusable software.
Use a systematic and scientific approach
Whether to use the scientific method, the efficiency gap is very large, may be 10 times, 100 times, or even from zero to one, you use these formal methods, some software can be done, if you do not master the method of system science, such a complexity of the software you may not be able to do at all. Therefore, mastering the scientific method is very important for us to control large software.
When it comes to the systems science method, I extend that we need to adhere to the principles of software development, and many practitioners in reality find it easy to succumb to various external forces, such as how a leader says, or how his demand side says, or how people around him say, it is easy to make very distorted behavior. What is the reason for this? I think about it, because many practitioners do not know the basic principles of software development, and it is easy for a person to succumb to external pressure when he does not have principles in his heart, so we need to adhere to the principles of software development.
Here we talk about what principles are, principles are the norms of work, and they represent a lot of collective wisdom. In the "201 Principles of Software" mentioned a lot of important principles, we listed here, such as quality first, first identify the problem, and then write the requirements, no documentation design is not design. Principles like this are very important, but if you think about it, in the real world, many teams, many people in the work, constantly breaking these principles, which is why our work is very inefficient and important. Here I wrote: without principles, there will be arbitrary compromises, and the result is inefficient, low-quality work.
This is also why Baidu students have worked hard in the past two years to promote the book "201 Principles of Software Development", which is a very classic software engineering book published in 1995, which mentions a lot of important principles, this book has been officially published last month, we found that many developers have a very high evaluation of this book. But I also see that many people scorn these principles, or even do not understand them, and some people have a very low evaluation of this book, which is very sad, obviously do not know these principles, when I tell him these principles do not feel anything, which I am very sorry for.
Continuously improve R&D efficiency
R&D efficiency is definitely not something that can be seen in a day, or even never-ending. It was found that many managers were very concerned about business goals, but not constantly focused on the ability to develop software. This is a very big misconception. Therefore, improving efficiency and improving human effectiveness should be the goal that a software research and development team has always needed to pursue, and we should think about how we do software today, and after a year or two, how can we do better software and what changes will occur.
Software engineering capabilities to improve, what to do?
In Baidu's definition of software engineering capabilities, the individual competencies in the qualities of engineering capabilities include the abilities and qualities of the team and the company's abilities. Personal competencies include the grasp of needs and system design, which are mainly about the previous design stages. Coding capabilities, project management, and operation and maintenance capabilities, which are the operation and maintenance of the software in the later stage, as well as product awareness, customer service awareness, security awareness, quality awareness, and communication skills. These are very important engineering skills for an individual.
I would like to emphasize here that for engineering capabilities, people are fundamental. I think the human element is the most critical. There's a saying about why people who use the same tools are only one-in-one in their efficiency at one-nth of someone else's. And for a good person, he only uses ordinary tools, and the output of his work will far exceed the average person's use of excellent tools. What is another important trend? Small-scale excellent engineer teams are far more than large-scale general engineer teams. Why? Because for a large team, the cost of communication is very high, and the cost of communication within the team rises exponentially with the number of people. So in this regard, due to the improvement of software tools, including the emergence of various cloud platforms, the performance has actually become greater, and a small team can do very, very many things.
For an excellent product, it must come from excellent people and teams, and it must not come from a general team. I have also said that software is the crystallization of human wisdom, and excellent wisdom must come from excellent people and teams. So my advice is to be a software R&D executive or leader, and invest more effort in developing team members.
In terms of personal qualities, I often simplify to three points: code, documentation, and project management. In the order of these three, I personally think that project management is higher than the document, higher than the code, which may be different from many people's understanding, many engineers think that code is the most important, 90% or even more than 95% of software engineers are ignoring project management, and have not mastered the formal method.
First of all, starting from the code, the requirements are very clear, to be able to write code that is easy for others to understand, this requirement seems to be very low, but in fact, many people can't do it. Here I quote a very good quote from Python, the first sentence is that beauty is better than ugly, and your display is better than implicit. In fact, the Python language, many people do not pay attention to what is said here, so our code should be written as simple as possible, as beautiful as possible, and try to use simple methods.
So the way to write good code is also very simple, I have listed five points here:
First, reasonable module division. Many students have serious problems with module division, which makes it very difficult to maintain software in the future and is also very difficult to reuse. Second, clear function definitions. Don't look at functions so simple, I found that many students do not know the semantic definition of functions. Third, short, clear code paragraphs. If we think about how many students write hundreds of lines of code without a single line of empty lines, comments. Fourth, accurate naming, emphasize that beautiful code should have a certain language foundation, writing code is the same as writing articles. Fifth, clear comments, indeed should talk about many people in the code, almost can not see any line of comments.
In addition, a careful code review is the best way to improve the quality of your code, and it is also the best way to disseminate programming methods. But unfortunately, there are still many teams in the Chinese Internet industry that do not really perform code reviews.
The pursuit of real software engineers in software: not a single space. We are still far from that goal.
The second point of engineering ability improvement: documentation
We need everyone to pay attention to the documentation, and the neglect of documentation is indeed affected by the so-called "Agile" movement, because many people have a wrong understanding of Agile, and it seems that many people have a concept that Agile is not writing documents. But I did do some research on Agile this year, and the origin of the Agile movement at that time was to deal with the fact that in the 80s or 90s of the last century, there was a lot of documentation to write, and to do a project to write a very, very many documents, and the documentation had become a load of work. So Agile thinking proposes to write less documentation, which means to write less, rather than not write, and I don't know how to become Agile in China is not to write project documents.
In the book "Software Development 2.0", it is clearly stated that design without documentation is not design. So in reality, many software engineers do not do design, directly jump on to write code, this thing is very absurd, in other industries will write design documents, and then put into production, and in our industry, did not write any documents, just finished, began to code, so this thing is very absurd.
Another perspective is to recognize why we should write a good project document, because more than 50% of our time in the whole project process is used for communication, so the efficiency of communication will greatly affect the efficiency of research and development. What is the purpose of the documentation? I think the first point is to improve the efficiency of communication, and through a clear document, you can greatly improve the efficiency of communication. The second is to improve the management of the thinking process. Throughout your design process, we use documentation as a design tool to organize ideas.
So from this point of view, many of us are very wrong about the understanding that documentation is used as a last-ditch way of archiving. I wrote two sentences in this, first, if you don't write documents, it means you can't do design. Second, you can't become a senior engineer without writing documents. So a lot of people have a very clear ceiling, maybe 8-10 years of code, but you can't write documentation, so you still can't jump to become a senior software engineer.
How can I write a good document? First, user thinking. For example, when writing a requirements document, you should think about the problem from the user's point of view, not from the perspective of internal practice. Second, an accurate conceptual definition. This is a bit similar to the code naming just now, naming represents the concept, and it also faces the conceptual problem in the documentation. Third, it is also very important to have clear and accurate logic. Fourth, perhaps everyone generally does not pay attention to it, that is, the normative way of expression. Whether it's in words or charts, I do say at work, so-and-so asks you not to use your dialect again. Many people really don't use the normative way, he expresses it in a way that he understands, and it is difficult for others to understand. Fifth, we must have the ability to study and think, we are unconsciously doing research in our work, research is to define problems, analyze problems, and solve problems. Sixth, rigorous scientific attitude, many students write a lot of question marks, unclear places are left, so that after retention into the next stage, the system of doing so is not able to withstand the test of history and time. Seventh, to be serious and full of design review, many teams do not do well in code review, should do worse in document review, many documents may not be read, directly passed. So it's 7 o'clock now, and it seems simple, and if we can do that, we can definitely produce very high-quality project documentation.
I also recommend two books that are helpful for everyone to improve the documentation, the first is "Everyone is a Product Manager 2.0", if you want to learn how to do requirements analysis, I recommend checking this book, even if you are not a product manager. The second book is "Pyramid Principles : The Logic of Thinking, Theory, and Problem Solving", which is also very good, you can check out these two books.
The third point to emphasize is also the highest priority of project management. From my time in industry for almost 15 years, I think a lot of teams neglect project management, and in Software Development 2.0 there's a point of view, Principle 127: Good management is more important than good technology. No matter how good the technology is, if you don't manage it well, the project will fail. There's a question that people often ask, I'm not a manager, I'm not a leader, why do I do project management? From Drucker's point of view, he mentioned that the people we are now engaged in these industries, in fact, are all knowledge workers, and every knowledge worker is a manager, and we have to look at the problem from this perspective. So every engineer is actually a manager, and he must do his own management. And in real work, you will find that many projects are managed by engineers, his manager, the Leader, these details can not be managed. And from the perspective of the overall industry trend, a small team with a high degree of self-organization is the trend. As you may recall earlier, small software engineering teams made up of good people are much higher than large-scale teams of ordinary people.
Good project management comes from: first, understand the common sense and principles of project management; second, a realistic attitude. I have found that many people take an evasive or concealed attitude when faced with project problems, which is not conducive to the normal progress of the project. Therefore, there is a great emphasis on us to tell the truth and dare to disclose it to the outside world.
Third, there is a need for a correct understanding of a knowledge society. What are the characteristics of the knowledge society, from the rights-centered to the knowledge-centered, we must respect the professional, self-management, these are not by people can see, even if you can watch people superficially working, but do not look at the brain. There is also the idea of people-centered, to abandon large-scale industrial production, everyone is a screw, everyone will be replaced, such a thought will be replaced.
There are two books recommended here, one is Drucker's "Knowledge Society", without which we would not have been able to build the knowledge team that is now very efficient. The second book is Tsinghua's Rapid Development, which was published very early, but it is a very good book.
Summary
Our society is more and more driven by information, in the information society software drives the information society, software research and development is very important. Secondly, the promotion of software engineers has great significance for China, and we should not ignore our responsibilities.
Event recommendations