Top 10 most annoying factors for the programmer
Most recently I came across an amusing “hit-parade” on the Internet for the most annoying things for a programmer. Since he was in English, he decided to translate the text and somewhat adapt to our realities ...
Even at the institute, on a programming course, we were taught that the code should be commented, and as fully as possible. It is always better to have too many comments than too few. Unfortunately, this recommendation sometimes turns into quite paranoia - the programmer comments on each line of code . For example:
Do you have any idea what this code does? Me not. Even after 100 grams. This code is an excellent demonstration of the problem, when comments describe what the code does, but they don’t describe why it does it.
')
For contrast, I will give an example of the same code, but with normal comments:
With such comments it is already clear what this code is for.
In fact, the comments in the code are intended to help the programmer, who will read this code after you, they should explain what exactly happens in this piece, and not describe the syntax of the code. In any case, the one who will read this code always has at least some idea how the cycle, division or other language constructs work.
A very small number of programmers can write code from scratch with the little finger of the right hand, while talking on the phone, shaving and chewing on another sandwich. In general, a programmer is more like a locomotive than a Ferrari - it takes some time for him to “accelerate” and “join” the work, but after “overclocking” the programmer can quickly and efficiently work.
But, unfortunately, it is very difficult to join the "workflow" when your "train of thoughts" derail a crowd of customers, managers or fellow programmers.
The reason is simple - to work on the task we need to keep in mind a huge amount of data in order not to miss something important.
Distraction from work simply “derailed” our “locomotive”, which has already accelerated, and it takes a lot of time to put it back on the rails, it is very annoying and, worst of all, contributes to the appearance of new errors.
In English, this problem sounds like Scope creep . Changes in a project can turn a simple task into the most terrible nightmare. A few completely innocent words entered into the project by the customer are enough to turn the task into a mess. For example:
Horror! A 30 minute simple task turns into a complex complex system for which you can spend more than one hundred man-hours. But the most terrible thing is when changes are made to the project during development , which entails rewriting, refactoring, and sometimes just throwing out the code on which the developer has spent a lot of time.
Management is not such an easy job. Maintaining a large group of people as a cohesive team is just the tip of the iceberg. But the complexity of the work of the manager does not save him from having to have at least a basic understanding of what their subordinates do, especially in the IT industry. When managers are not able to understand the basic concepts of the work of programmers, we get the next changes in the project, unrealistic deadlines, irritation and frustration on both sides of the development process. This is a fairly common complaint from programmers and the source of many problems.
Yes, of course there are many applications that generate documentation in automatic mode, but they are good only for creating API documentation, which only other programmers need. If you are working on an application for ordinary people, you should write some documentation yourself that an ordinary person can understand (for example, the basic principles of your application, possible problems and their solutions, etc.).
It is not difficult to guess that this is the most unloved occupation of programmers. Just look at the many open-source projects. What is the most common request for help from the open-source community? Correctly, write documentation.
Programmers often use libraries and third-party programs in their work. To do this, they, of course, need documentation. But, as stated in clause 6, programmers hate writing documentation.
There is nothing more annoying than trying to use a third-party library when you don't understand what half of the functions in the API do.
What is the difference between poorlyNamedFunctionA () and poorlyButSimilarlyNamedFunctionB ()? Do I need to do additional attribute checks? It turns out a continuous work by the method of pseudo-scientific spear.
Any programmer who at least once debugged an absolutely incomprehensible database crash or encountered rassync RAID arrays knows perfectly well what kind of headache causes problems with hardware. The biggest misconception in the field of IT is that since the programmer works with computers, he also has to fix them. Of course, for some programmers this is not a problem, but it prevents them from focusing on higher-priority tasks. For such purposes there must be special people who will be engaged in it.
"The site does not work!". "Functional X does not work as it should!" Indefinite bug reports are like a pain in the ass.
Especially when angry non-programmers, when asked to provide information on how to reproduce the bug, respond - "you are a programmer! Just take it and fix it!" and do not understand that there is not enough information to take and repair.
Programmers do not always get along with other programmers. Shocking, but true. The most characteristic irritating factors are:
Have you ever looked into your old code? This I wrote it ?? !!! You start to look like an idiot in your own eyes.
Yes, the problem ... But there is good news - you are not the only one;).
The essence of this problem is that the programming world is constantly changing. What we consider to be the newest trends today may simply become obsolete tomorrow. It’s trite to write perfect code, because programming standards and methodologies are reviewed and evolved daily! Of course, it is cruel to realize that beautiful code written today can be ridiculous and ridiculous tomorrow. For most programmers, this is the most annoying factor in their work ...
Translation and adaptation by Fenix.
Top 10 most annoying factors for the programmer
10. Comments that explain "how", but do not explain "why"
Even at the institute, on a programming course, we were taught that the code should be commented, and as fully as possible. It is always better to have too many comments than too few. Unfortunately, this recommendation sometimes turns into quite paranoia - the programmer comments on each line of code . For example:
$r = $n/2; // $r $n // $r - ($n/$r) $t while (abs($r - ($n/$r)) > $t) { $r = 0.5 * ($r + ($n/$r)); // $r $r + ($n/$r) } Do you have any idea what this code does? Me not. Even after 100 grams. This code is an excellent demonstration of the problem, when comments describe what the code does, but they don’t describe why it does it.
')
For contrast, I will give an example of the same code, but with normal comments:
// n - $r = $n/2; while (abs($r - ($n/$r)) > $t) { $r = 0.5 * ($r + ($n/$r)); } With such comments it is already clear what this code is for.
In fact, the comments in the code are intended to help the programmer, who will read this code after you, they should explain what exactly happens in this piece, and not describe the syntax of the code. In any case, the one who will read this code always has at least some idea how the cycle, division or other language constructs work.
9. Distraction from work
A very small number of programmers can write code from scratch with the little finger of the right hand, while talking on the phone, shaving and chewing on another sandwich. In general, a programmer is more like a locomotive than a Ferrari - it takes some time for him to “accelerate” and “join” the work, but after “overclocking” the programmer can quickly and efficiently work.
But, unfortunately, it is very difficult to join the "workflow" when your "train of thoughts" derail a crowd of customers, managers or fellow programmers.
The reason is simple - to work on the task we need to keep in mind a huge amount of data in order not to miss something important.
Distraction from work simply “derailed” our “locomotive”, which has already accelerated, and it takes a lot of time to put it back on the rails, it is very annoying and, worst of all, contributes to the appearance of new errors.
8. Changes in the project
In English, this problem sounds like Scope creep . Changes in a project can turn a simple task into the most terrible nightmare. A few completely innocent words entered into the project by the customer are enough to turn the task into a mess. For example:
- Version 1. Display a map of the area
- Version 2. Display 3D terrain map
- Version 3. Display a 3D map of the area where users can virtually navigate
Horror! A 30 minute simple task turns into a complex complex system for which you can spend more than one hundred man-hours. But the most terrible thing is when changes are made to the project during development , which entails rewriting, refactoring, and sometimes just throwing out the code on which the developer has spent a lot of time.
7. Managers who do not understand anything about programming.
Management is not such an easy job. Maintaining a large group of people as a cohesive team is just the tip of the iceberg. But the complexity of the work of the manager does not save him from having to have at least a basic understanding of what their subordinates do, especially in the IT industry. When managers are not able to understand the basic concepts of the work of programmers, we get the next changes in the project, unrealistic deadlines, irritation and frustration on both sides of the development process. This is a fairly common complaint from programmers and the source of many problems.
6. Documenting Applications
Yes, of course there are many applications that generate documentation in automatic mode, but they are good only for creating API documentation, which only other programmers need. If you are working on an application for ordinary people, you should write some documentation yourself that an ordinary person can understand (for example, the basic principles of your application, possible problems and their solutions, etc.).
It is not difficult to guess that this is the most unloved occupation of programmers. Just look at the many open-source projects. What is the most common request for help from the open-source community? Correctly, write documentation.
5. Applications without documentation
Programmers often use libraries and third-party programs in their work. To do this, they, of course, need documentation. But, as stated in clause 6, programmers hate writing documentation.
There is nothing more annoying than trying to use a third-party library when you don't understand what half of the functions in the API do.
What is the difference between poorlyNamedFunctionA () and poorlyButSimilarlyNamedFunctionB ()? Do I need to do additional attribute checks? It turns out a continuous work by the method of pseudo-scientific spear.
4. Iron
Any programmer who at least once debugged an absolutely incomprehensible database crash or encountered rassync RAID arrays knows perfectly well what kind of headache causes problems with hardware. The biggest misconception in the field of IT is that since the programmer works with computers, he also has to fix them. Of course, for some programmers this is not a problem, but it prevents them from focusing on higher-priority tasks. For such purposes there must be special people who will be engaged in it.
3. Uncertainty
"The site does not work!". "Functional X does not work as it should!" Indefinite bug reports are like a pain in the ass.
Especially when angry non-programmers, when asked to provide information on how to reproduce the bug, respond - "you are a programmer! Just take it and fix it!" and do not understand that there is not enough information to take and repair.
2. Other programmers
Programmers do not always get along with other programmers. Shocking, but true. The most characteristic irritating factors are:
- Inconsistency toward programmer opponents
- Misunderstanding of the fact that there is a time for discussing the system architecture and there is a time for its implementation
- The impossibility of adequate communication with colleagues and customers and differences in the understanding of terminology
- Impossibility to work as it should and when it is necessary
- Indifference to the code and, in fact, to the project
1. Own code, 6 months later
Have you ever looked into your old code? This I wrote it ?? !!! You start to look like an idiot in your own eyes.
Yes, the problem ... But there is good news - you are not the only one;).
The essence of this problem is that the programming world is constantly changing. What we consider to be the newest trends today may simply become obsolete tomorrow. It’s trite to write perfect code, because programming standards and methodologies are reviewed and evolved daily! Of course, it is cruel to realize that beautiful code written today can be ridiculous and ridiculous tomorrow. For most programmers, this is the most annoying factor in their work ...
Translation and adaptation by Fenix.
Source: https://habr.com/ru/post/38556/
All Articles