Guide language:
Recently saw a geek time above 10 x programmers execution of work column, as a programmer just hired soon, some deep feelings, including work efficiently or not has a great relationship and consciousness, the consciousness and the technical skills to separate, the former is more of work strategy, including work order, vision, and how to communicate, and so on, The latter is just professional competence. Today, I will talk about what needs to be done before a project starts, that is, before writing the code, and why to do it, and what kind of change can be brought to work efficiency by doing these things. This article will talk about my feelings and summary after reading the column based on my real situation.
Most of the time, we start a project with a mindset of eager to achieve success. We often tell ourselves that problems will only be discovered during the project. If we do not do it, we will never find the problem. There’s nothing wrong with that, but are all the mistakes or problems you have to make to avoid making them again? Is there any reference to the experience of others? Can planning in advance avoid some of the problems you might encounter? Are there any good practices in the industry? These are questions worth pondering.
In the past year of working, I found that many problems in work are not related to professional ability, but problems in working strategies. In 2017 at the end of the year after graduation, due to geographical reasons, to work in a small company, position is a software development engineers, the company is not very good management system, many conventional things in large companies, here need to ponder, to discuss, and colleagues and leaders often consider things beyond their own job, like operations, products and so on. Sometimes I am really confused and do not know how to do well. Without the accumulation of experience and the guidance of senior software engineers, I have no bottom in my heart. But now I think that the painful experience is worth cherishing and thinking about, which is also the only way to grow up. At the same time, I will sigh, if ONLY I had known earlier.
Here are a few things that I think you need to know before you take on a project, before you start a project, because otherwise you’re going to find holes all around you.
Is beginning to the end
This title is actually a module of Teacher Zheng Ye’s column, which means that the final result should be considered before starting. If you find that the project goes on, even if you finish it at last, the users will not be satisfied, then the project is not necessary, or there must be some adjustments in the design. For example, if you find that you are unfamiliar with the technology required for the project, you need to consider whether there is an alternative technology, or whether you have enough time and ability to learn it. Also, who is involved in the project, what teams are involved, what parts are they responsible for, problems or meetings to discuss who you should go to. Generally speaking, when we do a project, we should not follow our thinking, but think backwards, and deduce strategies and methods from the results. This is because we need to make sure that our work is guaranteed, that there is a solution to problems, and that our work is valuable.
Ask more why
In the company sometimes it is true that the crying child has milk to eat, many times the opportunity is there, because of a variety of reasons you do not fight for, the opportunity will be missed, the work will be a lot of difficult. Most of the time, when others put forward unreasonable requirements, you should speak your true thoughts, do not be afraid to be ashamed, for example, my leader asked me to use the technology I am not familiar with to do a project, then I have to ask him why he must use this technology? What about other technologies? I am not familiar with this technology and may not be qualified for this project. Is there anyone else qualified? If I have to do it, I will tell him that I need to spend XXXX time because I need to learn this technology. Of course, I will split it more carefully, so that it will be more convincing.
There is a classic rule 5 Whys, where 5 is just a reference number, and the actual situation can be more or less, but the main purpose of this principle is to find the root cause, the root cause. Before starting a project, asking why can help you understand the ideas of your superiors and others. In this way, you will have a clear and accurate position on the project, and also eliminate many unnecessary worries. The sooner problems are discovered, the better. By default, don’t do any of the requirements until you figure out why you’re doing it, save time, help others, and grow yourself.
Break it down and define the parts to do
The more you do something, the easier it is to do it, and the better you are, the smaller the time, for example, every 15 minutes, or even every 5 minutes. The average person might say what to do today, what to do tomorrow; People with no goals and no plans will even talk about what to do during this time. If you are able to write a program to the code into a pile of tasks, each task with a few words of simple code can be completed, and will not affect other tasks, then the decomposition is good, but these things really do need the usual deliberate practice, the difficulty is how to forever, how to plan, rather than how to do it. Now I write very long functions, but every time I come back, I will calm down and change, do some refactoring, remove the bad taste of the code, each time I write more concise than before, watching the changes in the code is actually to encourage myself.
The other question is how to define these tasks and what is accomplished? What are the acceptance criteria? If you disagree with others on these issues and start building the project, sooner or later, problems will arise. You think it is ok, but he thinks it is not, and he will not say that he has not done it, and he will have a lot of anger. It is better to define them in advance. A better strategy is to start from the user’s point of view and write User Stories, which are the whole process of users using the product, to help analyze how users are using the product, so that you can better find design problems and find design flaws without writing any code.
Define some numbers to reflect some objective facts
The numbers speak louder than anything else. For example, if a product is required to launch on January 1st, every extra day is a delay. Test coverage must be 100%, so 99.99% is bad code. If before doing the project, add some numbers to the requirements of the project, the final review may be relatively easy, not to reach, the heart will also have a scale, but also a reasonable allocation of energy and time.
Having said that, I believe that this is not all, these are the problem of consciousness, that is, the difference between knowing and not knowing, but sometimes it is not so easy to do, but I believe that the pain is at the beginning, learning, growth, after the long-term benefit.