September 1, 2008 at 04:19TOP 10 most annoying factors for a programmer
- Transfer
More recently, I stumbled on the Internet on a fun "hit parade" of the most annoying things for a programmer. Since he was in English, he decided to translate the text and adapt it to our realities somewhat ...
Even at the institute, on a programming course, we were taught that the code needs to 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 paranoia - the programmer comments on every line of the code . For instance:
Do you have any idea what this code is doing? Me not. Even after 100 grams. This code is a great demonstration of the problem when comments describe what the code does, but do not describe why it does it.
For contrast, I will give an example of the same code, but with normal comments:
With such comments, it’s 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 of how the loop, division, or other language constructs work.
A very small number of programmers can write code from scratch with the little finger of their right hand, while talking on the phone, shaving and chewing another sandwich. In general, a programmer is more like a locomotive than a Ferrari - it takes some time for it to “accelerate” and “get into” work, but after “overclocking” the programmer can quickly and efficiently work.
But, unfortunately, it’s very difficult to join the “workflow” when your “train of thoughts” is derailed by a crowd of clients, managers or fellow programmers.
The reason is banal - to work on a task, we need to keep a huge amount of data in our head so as not to miss something important.
Distraction from work simply derails our "locomotive", which has already accelerated, and putting it back on the rails takes a very long time, is very annoying, and, worst of all, contributes to the appearance of new errors.
In English, this problem sounds like Scope creep . Changes in the project can turn a simple task into the worst nightmare. A few completely innocent words entered into the project by the customer are enough to turn the task into a mess. For instance:
Horror! A 30-minute simple task turns into a complex integrated system, which can spend more than one hundred man-hours. But the worst thing is when changes to the project are made during development , which entails rewriting, refactoring, and sometimes just throwing out code that the developer spent a lot of time on.
Management is not such an easy job. Maintaining a large group of people as a close-knit team is just the tip of the iceberg. But the complexity of the manager’s work does not relieve him of the need to have at least a basic idea of what their subordinates do, especially in the IT industry. When managers are not able to understand the basic concepts of programmers, we get the next changes in the project, unrealistic deadlines, annoyances and disappointments on both sides of the development process. This is a fairly common complaint from programmers and a source of many problems.
Yes, of course there are many applications that generate documentation in automatic mode, but they are only good for creating API documentation that only other programmers need. If you are working on an application for ordinary people, you must write some kind of documentation 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? Right, write the documentation.
Programmers often use third-party libraries and programs in their work. To do this, of course, they need documentation. But, as stated in paragraph 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 continuous work by the pseudo-scientific poke method.
Any programmer who at least once debugged an absolutely incomprehensible crash in a database or was faced with a RAID array out of sync knows perfectly well what kind of headache iron problems cause. The biggest misconception in the IT field is that since the programmer works with computers, he must fix them. Of course, for some programmers this is not a problem, but it makes it difficult to focus on higher-priority tasks. For such purposes, there must be special people who will do this.
"The site is down!". "Functional X does not work as it should!" Uncertain bug reports are like a pain in the ass.
Especially when angry non-programmers respond to a request to provide information on reproducing a bug - "you're a programmer! Take it and fix it!" and they don’t understand that there is not enough information to take and repair.
Programmers are far from always getting along with other programmers. Shocking, but true. The most characteristic irritating factors are:
Have you ever looked into your old code? I wrote this ?? ?? 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 world of programming is constantly changing. What we consider the latest trends today, tomorrow may simply be out of date. It is corny impossible to write perfect code, because programming standards and methodologies are reviewed and evolve daily! Of course, it’s 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 a 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 needs to 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 paranoia - the programmer comments on every line of the code . For instance:
$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 is doing? Me not. Even after 100 grams. This code is a great demonstration of the problem when comments describe what the code does, but do not 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’s 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 of how the loop, 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 their right hand, while talking on the phone, shaving and chewing another sandwich. In general, a programmer is more like a locomotive than a Ferrari - it takes some time for it to “accelerate” and “get into” work, but after “overclocking” the programmer can quickly and efficiently work.
But, unfortunately, it’s very difficult to join the “workflow” when your “train of thoughts” is derailed by a crowd of clients, managers or fellow programmers.
The reason is banal - to work on a task, we need to keep a huge amount of data in our head so as not to miss something important.
Distraction from work simply derails our "locomotive", which has already accelerated, and putting it back on the rails takes a very long time, is very annoying, and, worst of all, contributes to the appearance of new errors.
8. Design changes
In English, this problem sounds like Scope creep . Changes in the project can turn a simple task into the worst nightmare. A few completely innocent words entered into the project by the customer are enough to turn the task into a mess. For instance:
- Version 1. Show a map of the area
- Version 2. Show 3D area map
- Version 3. Show a 3D map of the area where users can virtually navigate
Horror! A 30-minute simple task turns into a complex integrated system, which can spend more than one hundred man-hours. But the worst thing is when changes to the project are made during development , which entails rewriting, refactoring, and sometimes just throwing out code that the developer spent a lot of time on.
7. Managers who know nothing about programming
Management is not such an easy job. Maintaining a large group of people as a close-knit team is just the tip of the iceberg. But the complexity of the manager’s work does not relieve him of the need to have at least a basic idea of what their subordinates do, especially in the IT industry. When managers are not able to understand the basic concepts of programmers, we get the next changes in the project, unrealistic deadlines, annoyances and disappointments on both sides of the development process. This is a fairly common complaint from programmers and a source of many problems.
6. Documenting applications
Yes, of course there are many applications that generate documentation in automatic mode, but they are only good for creating API documentation that only other programmers need. If you are working on an application for ordinary people, you must write some kind of documentation 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? Right, write the documentation.
5. Applications without documentation
Programmers often use third-party libraries and programs in their work. To do this, of course, they need documentation. But, as stated in paragraph 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 continuous work by the pseudo-scientific poke method.
4. Iron
Any programmer who at least once debugged an absolutely incomprehensible crash in a database or was faced with a RAID array out of sync knows perfectly well what kind of headache iron problems cause. The biggest misconception in the IT field is that since the programmer works with computers, he must fix them. Of course, for some programmers this is not a problem, but it makes it difficult to focus on higher-priority tasks. For such purposes, there must be special people who will do this.
3. Uncertainty
"The site is down!". "Functional X does not work as it should!" Uncertain bug reports are like a pain in the ass.
Especially when angry non-programmers respond to a request to provide information on reproducing a bug - "you're a programmer! Take it and fix it!" and they don’t understand that there is not enough information to take and repair.
2. Other programmers
Programmers are far from always getting along with other programmers. Shocking, but true. The most characteristic irritating factors are:
- Intemperance towards opponents-programmers
- Misunderstanding of the fact that there is time for discussing the architecture of the system and there is time for its implementation
- The impossibility of adequate communication with colleagues and the customer and differences in understanding terminology
- Inability to work as it should and when 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? I wrote this ?? ?? 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 world of programming is constantly changing. What we consider the latest trends today, tomorrow may simply be out of date. It is corny impossible to write perfect code, because programming standards and methodologies are reviewed and evolve daily! Of course, it’s 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.