Finishing | Like smoke
Produced by | 51CTO Technology Stack (WeChat ID: blog51cto)
"Code farmers must not write beautiful and clear code as previously stated in the book, they must program defensively, make sure that they are laid off, and the rest of the code is not maintainable."
Recently, a news about using "defensive coding" to deal with the wave of layoffs in large factories rushed to the hot search of workplace social platforms. The logic behind this strategy is to improve one's "irreplaceability" to some extent by ensuring that once you leave your job, the code you leave behind is difficult to replace.
Image
But can this really be a "moat" for programmers to keep their jobs, or is it just a psychological comfort, or is it just a joke to release stress?
1. The storm of layoffs in large factories forced out "strange tricks"
Speaking of keywords throughout the global technology field in 2023, "layoffs" may not be able to escape the top three.
According to an inventory of layoffs in overseas technology companies in 2023 by a number of foreign media and data agencies, as of mid-November 2023, the technology industry has laid off more than 240,000 jobs, a year-on-year increase of 50%. Among the top 7 technology companies with the most layoffs, Google, Amazon, Microsoft, Meta and other large companies are impressively listed.
Looking at the domestic situation, according to public reports, Tencent Ali and Kuaishou lost a total of more than 16,000 employees in the first half of this year. In addition, companies including Bilibili, Meituan, Baidu, Pinduoduo, JD.com and other companies have also carried out some layoffs.
In the face of the wave of "reducing costs and increasing efficiency" and "opening apes and reducing expenditures" of various large factories, many programmers feel uneasy, and put forward various "strange tricks" to keep their jobs.
"Defensive Programming" is one of them. There may be two reasons behind it:
First, the fierce competition in the industry inevitably makes programmers worry that if the code they write is clear and readable, it may be easily understood and replaced by others. Making code obscure can be a "shortcut" to maintaining your competitive edge over your team.
Image
Second, through the "self-preservation" means of "defensive coding", even if you are laid off, the code left behind will become a "time bomb" that the enterprise cannot maintain, and there is a sense of revenge that you have to fight for a "net break" even if the fish is dead.
2. Is the use of "defensive code" self-preservation, or death?
As soon as the strategy of using "defensive code" to protect itself came out, the comment area exploded, and netizens had different opinions. The main opinions can be broadly divided into three categories:
One shows support, you are not benevolent and blame me for being unjust, and the main one hurts each other.
Image
There are also employees of large factories who give a few introductory tips for defensive coding straightforwardly:
Image
The second is explicitly opposed, arguing that layoffs are mainly related to work ability and company strategy, which is difficult to protect oneself and is easy to be perceived as having problems with values.
Image
The third is that this situation is basically not happening in large factories because there is a code review mechanism.
Image
Some people seem to see through the old programmers digging holes for novice rookies, and bluntly point out that this statement is just a joke and does not need to be taken seriously: "If you believe the 'defensive programming' ridiculed by the old programmers, then you are not far from being eliminated".
Image
Image
Objectively speaking, adopting "defensive programming" means that once the programmer leaves, the team faces a huge technical debt, and other team members spend a lot of time understanding and refactoring the code. Some practitioners have made it clear that it is not advisable to trade "defensive code" for a sense of security in keeping their jobs, no matter what the point is.
- First of all, from the perspective of personal improvement, deliberately writing obscure "bad" code is not conducive to improving one's programming skills.
- Second, from the perspective of team collaboration, if you write code that is too complex or difficult to understand, it can seriously affect the efficiency of the project, and in addition, modern development environments and company cultures often emphasize code quality and teamwork, and many companies and teams have code review mechanisms to ensure the quality and maintainability of the code.
- Finally, deliberately bad code can have a negative impact on one's professional development.
3. "Defensive Programming" = Shishan Code? Don't confuse the concept
At this point in the discussion, have you noticed that the "defensive programming" mentioned above refers to "rotten" code, isn't this the "mountain code" often mentioned in the industry?
At the beginning of the discussion, some discerning people discovered that the so-called use of "defensive code" for self-protection is actually a bit of a stealth concept.
Image
In fact, defensive programming itself is indeed a technical term in the field of programming, and it is meant to be a meticulous, careful approach to programming. It requires programmers to anticipate possible problems when writing code and to take steps in advance to circumvent them. This programming Xi places more emphasis on error prevention and control to reduce potentially catastrophic consequences in the future.
It's important to note that defensive programming, sometimes referred to by computer scientists, is often used where high availability, security, or security are required. It is a way to improve software and source code by:
- Overall Quality – Reduces the number of software bugs and issues.
- Make the source code easy to understand – The source code should be readable and easy to understand in order to be approved in a code audit.
- Make the software run in a predictable manner, despite unexpected input or user actions.
To put it bluntly, it is to strive for "even if the user is a crazy monkey who messes with the keys, he can't play my system".
Therefore, this "defense" (to prevent code errors) is not the other "defense" (to guard against layoffs), but under the wave of "open source and reduce expenditure", defensive programming has been given a new meaning. The real value of defensive programming is that it helps us write more robust and reliable code, rather than becoming a strategy for survival in the workplace.
4. Is "defensive programming" for self-protection illegal?
When it comes to the use of "defensive programming" (Shishan code) by programmers to prevent layoffs, one can't help but think of previous cases where programmers were sentenced to prison for "deleting the library and running away" in order to vent their dissatisfaction.
The same programmer "hands and feet" in computer programming in order to protect his own interests, so is it illegal to deliberately write "mountain" code?
It is understood that the crime of sabotage of computer information systems has been clearly defined in the Criminal Law. According to article 286 of the Criminal Law, anyone who violates state regulations by deleting, modifying, adding, or interfering with the functions of a computer information system, causing the computer information system to fail to operate normally, and the consequences are serious, shall be sentenced to fixed-term imprisonment of not more than five years or short-term detention, and if the consequences are especially serious, shall be sentenced to fixed-term imprisonment of not less than five years.
From the perspective of labor relations, if the code written by the programmer can run through, does not affect the operation of the system, and can ensure the normal use of functions, then it seems understandable that he has completed the delivery of his job responsibilities, and if he vents his emotions through "defensive programming", and is therefore responsible for causing heavy losses to the company's business, I am afraid it will be difficult to escape the punishment of the law.
Image
5. Either don't write it, or you write elegant code
Although I can understand the feelings of programmers who are forced to put forward self-protection strategies due to the pressure of layoffs, in the world of programming, writing poetic code should be the goal of every programmer.
The reasons for writing elegant code are clear, first of all, the logic is clear, simple and intuitive, so that you can spend more energy on feature development, secondly, the code written with fresh thinking can reduce bugs, which will reduce the time to fix bugs, and finally think from your own point of view, the quality of your code should depend on you, not any other person or organization, you should be responsible for yourself, and you should not let other factors be the reason for you to lower your requirements.
When it comes to writing elegant code, the bigwigs in the computer field have also reached a consensus:
Bjarne Stroustrup, the father of C++: I like elegant and efficient code, where the logic should be straightforward, so that defects are difficult to hide, that dependencies are minimized to make them easy to maintain, and that there is a layering strategy to improve the error handling code. The performance modulation is optimal, so you don't have to induce others to do unruly optimizations and create a lot of chaos. Clean code does only one thing.
Wiki inventor Ward Cunningham: If every routine feels like something you feel comfortable with, it's clean code. Code that makes it look like a programming language exists specifically to solve that problem is beautiful code.
Robert C. Martin, a world-class programmer and pioneer in design patterns and agile development: How often you swear in code reading is the only measure of code quality.
In addition to foreign bigwigs, Lei Jun, the founder of Xiaomi Technology, also advocates the simplicity and readability of the code, and the code written 30 years ago is on fire, and it is praised as elegant as poetry.
6. Write at the end
Whether it is a momentary vent of unhappiness or a serious desire to "protect oneself" through this strategy, it reflects the anxiety and anxiety of programmers in the current environment.
From the perspective of enterprises, it is necessary to pay attention to the dilemmas and pressures faced by programmers in large factories, and encourage an open and collaborative programming culture, so that each programmer can give full play to his or her maximum value in the team, so as to improve the overall efficiency of the team.
As far as the programmer is concerned, there is no need to make small moves for the company to comply with labor laws, comply with laws and regulations, and give sufficient compensation, otherwise it is indeed a lose-lose situation. If the company does not comply with the labor law and evades compensation, it should protect its rights according to the labor law, not through informal means.
In addition, in this fast-changing industry, programmers should focus more on upgrading their skills and knowledge to adapt to new technologies and challenges, rather than relying on writing obscure code to keep their jobs.
Reference Links:
https://www.zhihu.com/question/633103265/answer/3315370701
https://zhuanlan.zhihu.com/p/671314487
https://www.51cto.com/article/710674.html
Source: 51CTO Technology Stack