Enable and do-not-disturb Modes

Today, I want to talk about my recent experiences in the Failover and do-not-disturb modes.

Enable Mode

At first, I wrote this as a hero mode because it came from English hero mode [1]. But later, I thought "hero" could better represent this mode. The developer's behavior in this mode is not a hero, but a hero. During development, developers need to add more functions to show their development capabilities or meet customers' needs to extend their working hours. However, this model may increase the burden on the team, cause poor quality, delivery delays, and other negative situations. To achieve more performance, developers start to work overtime until late at night or even until dawn. However, the physical and mental conditions are deteriorated due to staying up late, this reduces the efficiency. This kind of behavior will also lead to a group effect, that is, everyone must work overtime together with this "hero" to reduce efficiency. For a long time, this eventually leads to the formation of an inefficient overtime culture in the enterprise, which brings significant harm to members in the organization and organization. The enable mode is actually a manifestation of personalization. After entering the failover mode, developers do not think about projects, customers, teams, and self-centered. That is, I want to prove that I am very good. However, such a person thinks that I am contributing to the company, and I have paid a lot. I am thinking about the customer, and I have sacrificed my personal time ....... However, all these seem rational. In fact, the final core is to prove that you are doing well. To prove that they are doing well, developers who enter the trusted mode require others to bring off their work, and require others to accompany them to work overtime to reduce efficiency. Repeated entry into the energy sharing model is a lack of team spirit and a reflection of self-centered ideas.

 

The failover mode is a mentality that needs to be avoided. Greedy and big pictures are a bad mood. In addition to affecting the overall morale of the team, they will also lead to software function expansion, making it difficult for users to use, so that the initial expectations of "satisfying the customer" are also lost.

 

 

Do-not-Disturb Mode

The developer's thinking needs to be coherent. After Thinking of the practice, writing the program quietly is the most efficient way for programmers. However, programmers will inevitably be disturbed by such things during their work, project managers, colleagues, and administrative departments are disturbing the programmer's time. The thinking is no longer coherent and the efficiency becomes low. If the programmer can set the Do-not-Disturb Mode, the programmer enters an efficient development state, which is of great benefit to the company and the individual.

How do I set the Do-not-Disturb Mode?

 

1. Use a non-disturbing communication method

Despite the benefits of the Do-not-disturb mode, we still emphasize the importance of communication. However, in the do-not-Disturb Mode, development programs have a high priority. That is to say, in this case, unless a fatal problem occurs, all communication should enter the Do-not-Disturb Mode. This is just like we need to mute our cell phones during a meeting. When a meeting is processed as a high-priority transaction, the phone number is processed as a low-priority transaction. In the same way, when development has a higher priority, notifications such as reimbursement of fare fees before this Friday are best published only by email.

 

2. Mutual compliance

When the Do-not-Disturb Mode is established in the initial stage, some Members may not be able to comply with it. Therefore, we need to establish a common agreement on the Do-not-disturb mode so that everyone can abide by such a discipline. For example: Turn off the phone, do not activate outlook, unplug the phone line, and suspend the Do-not-Disturb sign.

 

3. Long-term persistence to form habits

It became a habit to stick to one thing for more than 21 days. Persistence.

 

If possible, set up a do-not-disturb period to enable the programmer to enter the Do-not-Disturb Mode to improve work efficiency.

 

 

 

 

For terms, see rework 37 signals LLC.