Why is a good developer happy with defects?
Not so long ago I read this article and realized that I am really grateful to the defects. Yes, no one loves them. Yes, everyone thinks that without them, things will not do anyway. Yes, time to fix a defect is almost impossible to estimate and difficult to control. And with all this, I really believe that defects have brought me a lot of good.
To begin with, every defect is a kind of mystery. Sometimes in the form of “what a dibil could write like that,” but more often it is much more difficult, especially if the project is developed by a good team. These puzzles are very interesting to solve. I can argue that at the sight of some defects you had an idea: “this simply cannot be!”. Solving these kinds of puzzles stimulates the brain and trains it to find unusual and interesting solutions.
')
Defects are usually "vile" and hide in the most secluded corners. The more you find and fix them, the more you know about the system, its work and features. After all, you often have to shovel a bunch of code along the way. This has a very positive effect on your future tasks, because the knowledge of the system allows you to solve them more effectively.
Defects help you get to know the tools and libraries that are used on your project. After all, there are defects in them too, because of which something stops working for you. If it were not for defects, it is very unlikely that I would pay so much attention to the internal workings of popular libraries. Defects stimulate the ability to understand, read and understand someone else's code, and this is one of the main skills of a good developer.
Finally, we learn from our mistakes or others. Having understood the reason for the defect, you get a lesson and in the future do not step on the same rake. The more lessons you get, the better your code will be and the fewer defects you will make in the future.
And, as a bonus, you always have something to tell. After all, many defects exist in a single copy, and it was you who “fished” them. This is about the same as that of fishermen.
But not all defects have these advantages. There are trivial, homogeneous and stupid defects. Nobody likes to correct them, they are boring and uninteresting. But this is a big plus. A competent developer of such defects are pushed to changes in team processes and approaches to writing code that will avoid unnecessary boring work. It is because of this that work with testers changes, more automated tests are written by developers, TDD, code review and static code analysis are used. We strive to avoid stupid mistakes.
That is why I am grateful for every defect found. I do not need its detailed description, additional artifacts and other popular things. I am ready to rummage around in the code and find the reason, because this is a chance for me to learn, which will bring joy to the customer. Consider how easy it is to please someone and that’s great! I wish you only interesting and instructive defects!
To begin with, every defect is a kind of mystery. Sometimes in the form of “what a dibil could write like that,” but more often it is much more difficult, especially if the project is developed by a good team. These puzzles are very interesting to solve. I can argue that at the sight of some defects you had an idea: “this simply cannot be!”. Solving these kinds of puzzles stimulates the brain and trains it to find unusual and interesting solutions.
')
Defects are usually "vile" and hide in the most secluded corners. The more you find and fix them, the more you know about the system, its work and features. After all, you often have to shovel a bunch of code along the way. This has a very positive effect on your future tasks, because the knowledge of the system allows you to solve them more effectively.
Defects help you get to know the tools and libraries that are used on your project. After all, there are defects in them too, because of which something stops working for you. If it were not for defects, it is very unlikely that I would pay so much attention to the internal workings of popular libraries. Defects stimulate the ability to understand, read and understand someone else's code, and this is one of the main skills of a good developer.
Finally, we learn from our mistakes or others. Having understood the reason for the defect, you get a lesson and in the future do not step on the same rake. The more lessons you get, the better your code will be and the fewer defects you will make in the future.
And, as a bonus, you always have something to tell. After all, many defects exist in a single copy, and it was you who “fished” them. This is about the same as that of fishermen.
But not all defects have these advantages. There are trivial, homogeneous and stupid defects. Nobody likes to correct them, they are boring and uninteresting. But this is a big plus. A competent developer of such defects are pushed to changes in team processes and approaches to writing code that will avoid unnecessary boring work. It is because of this that work with testers changes, more automated tests are written by developers, TDD, code review and static code analysis are used. We strive to avoid stupid mistakes.
That is why I am grateful for every defect found. I do not need its detailed description, additional artifacts and other popular things. I am ready to rummage around in the code and find the reason, because this is a chance for me to learn, which will bring joy to the customer. Consider how easy it is to please someone and that’s great! I wish you only interesting and instructive defects!
Source: https://habr.com/ru/post/175601/
All Articles