Help me write an e-commerce website, like Taobao, is 3000 budget not enough? But one more point can be added. "Help me write a search engine like Baidu. It shouldn't take much time for an input box?" My needs in this area are a bit complicated. Help me write a smart back cover that changes with the color of the mobile phone theme. Money is not a problem. . "
Whether you are a formal Internet company or a part-time developer, you will more or less encounter a variety of product needs, customer needs, boss needs, they all agree: this demand is very simple.
Is this true?
"With only two lines of code, why does it take two days?"
This question seems reasonable, but there are several absurd ideas behind it:
Number of lines of code = number of lines of work code = lines of value There is no difference between the lines of code, the equivalence is obvious, the above three are nonsense.
When developers face such accusations, they roll their eyes, but they can’t help but blame others. Software development is the magic of mapping the real world to the virtual world. Looking back at the changes we have made, there are too many reasons why two lines of code are spent. Two days.
The description of the reproduction method in the problem report is not clear enough.
Sometimes it takes us hours to reliably reproduce certain problems. In such a situation, some developers will immediately contact the person who reported the problem and ask them to provide more details. But some developers don't like to fix bugs, so lack of information is a good way to get rid of the pot.
Since the reported issue is about features, I am not familiar with these features.
This may involve some functions, some developers rarely use, so they are not very familiar with the relevant details. In this case, developers need to spend more time to understand how to use the function, especially the specific process of this kind of function bug and software interaction.
This is because I spent time researching the real cause of the problem, not just mere symptoms.
If some code generates an error, directly encapsulate it in a try... catch statement, which can effectively suppress the error. Nothing wrong, no problem, right? Certainly not. For the responsible developer, covering up the problem and solving the problem are two different things. Hiding mistakes can easily cause other unexpected side effects. At a critical juncture in the future, I don't want to worry about the same mistake again.
This is because, in addition to the reported replication steps, I also studied other situations that might cause the same problem.
Although the error can be easily reproduced, a set of repeated steps is often not enough to reveal the underlying cause of the error. While finding out this kind of root factor, studying all feasible solutions is the truly valuable analysis insight. It may involve the actual working of the code, there may be other problems that need to be resolved in other locations, or some code inconsistencies (causing an error in one code path, but no error in other paths), etc.
Since I spent some time verifying whether other code is affected by similar issues.
If the error is caused by a bug, then the same error should appear elsewhere in the code base. Now that you have the user report, it is best to check it thoroughly.
Since I have found the root cause of the error, I want to use the simplest method to solve the problem and ensure that the side effects are controlled to the lowest risk.
Since I completely tested this change and made sure it solved the same problem in a different code path.
I don't want others to feel troublesome about fixing tests. Before that, I don’t want similar errors to happen again, so I do my best to ensure that the problem is completely resolved. The environment transition is complicated and tedious, and I hope that my job will make full-time testers no longer need to make essentially "exactly the same" changes.
Is there anything more troublesome than fixing a bug? This means fixing the same bug repeatedly. What you see is only the two lines of code I added, but you did not see why I added these two lines of code and why these two lines of code are implemented in this way.
I only write a few lines of code every day. What is going on?
Many teams’ performance appraisal indicators have exposed the issue of “number of lines of code”. Some testers use the number of “bugs” as the basis for checking the number of “Bugs”. Major Internet companies have also used hundreds of millions of lines of code in the team as a product promotion point. .
It gives the outside world an illusion that the number of lines of code is the gold standard for measuring programmers' technical capabilities and work results. If you can write more, it means you can write well? Could it be that kind of thick if...else shock wave, which can be described in parallel sentences like when writing an article?
Links looked like he wanted to hit someone.
In fact, the programmer's work output has nothing to do with the number of lines of code, and the programmer's work time is not limited to writing code.
Last year, a foreign research organization ActiveStates conducted a survey, and the results showed that thousands of developers in more than 80 countries were from the United States and China.
On average, developers spend less than 4 hours per day writing programs.
38.8% of the 1250 survey samples only spend 2-4 hours a day programming. This result is similar to the 2018 survey, 37% of people spend 2-4 hours a day programming. In contrast, 27.92% of people spend 5-7 hours a day programming, and in the 2018 survey, 31% of people spend 5-7 hours a day programming.
Even more surprising is that in 2019, 61.52% of respondents spent 4 hours or less programming, while in 2018, only 51% spent 4 hours or less programming. Another 10.56% spent 8 hours or more on programming, a drop of nearly half from 19% in 2018.
Developers spend less and less time writing code, so where does the time go?
Forty-four percent said they must spend their time on various activities, including meetings, testing, maintenance, and even social interactions. One of the most time-consuming activities was software design/architecture, accounting for 11.36%, and then attending standups/conferences, accounting for 8.24%.
These developers may also spend a lot of time writing logs and writing weekly reports. In China:
These codes reflect my social sentiments, including my quintessence of technology and business thinking, to maximize customer value, meet user needs, leave valuable technical wealth for the team, and add a new dimension to the realization of the digital economy. This strength has connected the team, aligned the goals, solved the pain points, endowed the industry, and given life. This is a great programmer!
After spending two days, do you think I am very efficient?
Click for more information, more free open source projects and courses are waiting for you to watch!