Original link: https://www.hwchiu.com/read-notes-59.html

Title: “Why Some Engineers Don’t Believe in Best Practices”
Category: others
Link:https://blog.devgenius.io/why-some-developers-dont-believe-in-best-practices-8c03ea4f7e88

Engineers must be familiar with the popular development principles of DRY, KISS (Keep It Simple, Stupid), YAGNI (You Ain’t Gonna Need It), these principles have been developed by many excellent engineers in the past through their own experience. Condensed development guidelines.

However, the author observed that many engineers take a distrustful attitude towards these development principles/naming standards/best experimental experience, and even feel that importing these things is a waste of time.
Therefore, this article is the author to explore what kind of engineers may be reluctant to learn and import these widely circulated development principles and experiences

Small projects and experience

The author said at the outset that the successful experience of small projects basically cannot be imported into the development of large projects. The characteristics of small projects, such as 1) few collaborators 2) short project time, can only lead to technical debt or lack of such characteristics. The designed program structure will not affect the entire project. After all, the project is too small and the time is too short, and subsequent people may not have the opportunity to actually observe these potential problems.

Another major feature of small projects is that the people who maintain the follow-up are likely to be different from the original developers, so it is very difficult for developers to feel the pain and needs of follow-up maintenance.

The above characteristics may make developers feel that their development experience is sufficient and usable, so they will resist other more popularized and respected development principles and best practical experience based on such experience.

Therefore, for some engineers who have only developed small projects and have no follow-up maintenance, they may not want to learn these principles and experience, after all, their own workflow has no chance to feel the benefits.

Reward and incentive

To put it simply, it is the concept of “bad money chases good money”. From the perspective of engineer development, writing a code that “may be easier to maintain, there will be no problems in the future, and high-quality code” will not bring about in practice. Any benefit, maybe even “underperforming”, so why should an engineer try to write high-quality code?

In addition to developers, the software team will also have related project managers, product managers and end users.
For non-technical personnel, their concerns are more likely to focus on “program development speed, product launch speed”, as for the follow-up maintenance of the project, development flexibility and other issues that will be seen for a long time are not their concern the point.

In this case, how to evaluate an engineer’s ability is likely to become “how quickly can the project requirements be met, not the quality of the code written”, so for engineers, the quick write function does not consider other subsequent maintenance. Long-term problems are more likely to be valued by the team because “features come out fast”.

Therefore, if the team cannot pay attention to the “development principles that consider long-term problems such as high-quality code”, it may lead to engineers not wanting to write good code, and these engineers may start to refuse in the long run. Learn the experience of various development principles and best practices. After all, importing these things will not help you in any way, but may slow down the launch speed of functions in the initial stage.

Ignorance

“Know the enemy and know yourself, and win a hundred battles.” Without taking the time to learn the context and applicable scenarios of these development principles, there is no way to smoothly introduce them into the development project, so in fact, these introductions require engineers to spend time to learn and understand , then try importing and using.

However, not every engineer is willing to take the time to learn. After all, the usual job is to write code and write files, and as a result, it is good to be able to move. Take the time to learn these things

The author believes that many engineers “actually don’t know what they don’t know”, which makes it difficult for them to learn new technologies and new concepts. As mentioned earlier, it is difficult for a person who is good at developing short-term projects and then abandoning them for maintenance to others to understand the problems of various long-term maintenance and technical debt.
practices.

Best practices, and poor practices get the same results initially

Another very common problem is that “importing development principles and good development experience” may not make any significant difference for initial development.
From the perspective of short-term goals, the results from the development perspective of the two will not be very different, but for small projects that only have a few months, the latter can even complete the requirements faster and then slap the butt and end the flash.

Architecture complexity, technical debt, and other follow-up problems that may arise from bad code all take time to ferment, so if the team owner can’t see the program development from a long-term perspective, the above problems cannot be taken seriously, just like the previous As mentioned above, developers will develop with the concept of “speed first, quality second”, and whether the follow-up maintenance is painful or not is the matter of the follow-up successor.

The rest of the arguments can be viewed in the original text

Professionalism

Short-term approach

personal information

I currently have Kubernetes-related courses on the Hiskio platform. Interested people are welcome to refer and share, which contains my various ideas about Kubernetes from the bottom to the actual combat.

For details, please refer to the online course details: https://course.hwchiu.com/

In addition, please click like to join my personal fan page, which will regularly share various articles, some are translated articles, and some are original articles, mainly focusing on the CNCF field
https://www.facebook.com/technologynoteniu

If you use Telegram, you can also subscribe to the following channels, where I will regularly push notifications of various articles
https://t.me/technologynote

Your donation will give me the motivation to grow my article

This article is reprinted from: https://www.hwchiu.com/read-notes-59.html
This site is for inclusion only, and the copyright belongs to the original author.