In the programmer industry, overtime seems to have become a consensus.
Many people join the industry in the mood of "getting hot.
In any industry, it is impossible not to work overtime. Can programmers work less overtime?
The answer is sometimes possible, but it is also difficult.
Before looking at specific measures, let's take a look at the causes of overtime. The core causes of overtime can be divided into three types:
- Artificial administrative reasons. This can be further divided into two types of scenarios: one is that in some companies, not working overtime is equivalent to not working hard. So no matter whether you need it or not, I am afraid that the foreign workers will be added first. One is that in some companies, profits are proportional to working hours, so potential companies will push for extra overtime.
- Business reasons. In this case, programmers often receive a calendar directly, but the schedule itself is not reasonable, so they can only work overtime. The schedule is usually determined based on commercial factors such as product time-to-market. When determining product time-to-market, the planners may not know how much work is required for development, the deviation can only be compensated by the overtime of programmers.
- Technical reasons. The technology here is about Estimation Technology and demand development technology. Sometimes, even if the project team makes estimation on its own and decides the schedule, but the demand is unclear or the estimation method is inappropriate, there will also be situations where the commitment schedule cannot be handled-and overtime is required.
After this analysis, we will find that although programmers are the victims of many decisions, they do not have much say.
Overtime due to administrative reasons is more derived from the business layer.
Business-related overtime work is more due to market personnel.
To solve these two types of problems, programmers need a conversation channel as a group at a specific time and location. However, this is too complicated and is not a technical problem at all.
Programmers have a say only when they work overtime due to technical reasons, but the existence of such a say is more dependent on the project manager. Estimation itself, not to mention any advanced technology, as long as enough decomposition, collection of historical data, and allow programmers to participate in estimation, the results will become more reliable. Generally, the farther away from the Program site, the less reliable the estimation.
Finally, let's add an interesting thing:
From the perspective of voice, most of the time: administrative reasons> commercial reasons> technical reasons.
The image points are: the right to speak at the business layer> market personnel> technicians.
However, once the decision is unreasonable and revenge is taken, the order will be reversed: the program is too technical, and market personnel cannot help. Market personnel cannot do it, and the business layer cannot.
Certificate ------------------------------------------------------------------------------------------------------------------------------------
Ideal stream + software = perfect software development: Methods and logic
Ideal stream + life = ??
Ideal stream + Management = ??
Ideal stream = the essence of deduction by concept and logic, and the pursuit of truth.