Programming: a history of one disease

Probably, in this article there is not a single new or fresh thought; moreover, I am sure that you have already read something like this several times. The article does not claim to be true. Its content is the fruit of its own experience, trial, mistakes and at the same time squeezing out of the knowledge that it was possible to learn from colleagues, read on Habré and in other places. Probably, for each concrete individual, what is said in this text will be very different from reality, but, I am sure, many will be able to learn in describing themselves. The first stage, probably, is not very typical for programmers who did not study Olympiad programming when they were students or students, but the next ones are almost completely independent of this factor.

Stage one. Birth

"I am a programmer. I am an olympiad. I know what “o” is - small. I know, that such “About” - big. I understand the difference between “en-square” and “en-factorial” and why they both shyly hide at the sight of “en-logarithm-en”. Now I will come to the project and rewrite this brake porridge from the code so that it will work many times faster! Look, I know the Knut-Morris-Pratt algorithm! And here you can save one comparison of the lines for equality! And if this recursion is turned into a loop, then at the expense of saving calls to methods and allocating memory in the stack ... What, is the program slowing down? Now I will look at the code ... Here! Look, instead of two nested loops, you can write one and use binary search instead of internal one! ”

Meet this is the first stage. It, unlike the following ones, is especially characteristic of olympiad players. The patient is thinking about how to write a quick code. He is obsessed with fast code. Unfortunately, the presence of a fast code does not always make a quick software product as a whole.

The patient rewrote the best way a piece of code that runs once the web server starts, and this did not affect the overall performance. The patient rewrote a piece of code, which was then changed 10 times due to changes in the requirements of the project and its micro-optimization caused a cloud of elusive bugs. Its algorithm runs in linear time, while the old one was executed in quadratic time, but the old one did one database query, and the new one does it in each iteration. The patient does not realize that many users work with a web project at the same time and the use of static data is fraught ... You can continue for a long time.
The main problem of the patient is that he thinks in a couple of classes or methods and at the same time is not quite aware of what is happening around this part of the project. His thinking is limited to the code and algorithm of his work, that is, how the program works, and not what it should do. However, this stage rarely lasts long enough for the patient to harm himself or others. The understanding comes rather quickly that something of what he does, he does wrong, and he starts learning.
')

Stage Two. Idealism and self-confidence

“I am a developer. Yes, that's right, I'm a software developer, not a programmer. My task is to develop a product that will work stably and consist of the correct code. The code I write should work correctly first, and then quickly. The code should be structured and commented out - perhaps it will be supported by other developers. OOP is my main tool, I can analyze the subject area and highlight class hierarchies in it. Everything that can be described by templates or generics is described by templates or generics. I use declarative programming wherever possible, because this tool makes the code as readable and understandable as possible. I use code generation because it saves my time writing code. I use only new technologies. I spend a lot of time in disputes with colleagues, which pattern or technology is better suited to solve the problem and whether it is right to use this or that approach here ... "

And this is the second. The patient matured and filled many cones during the previous stage. Knut's maxim that premature optimization is the root of all misfortunes has been learned by memory and burned with a hot iron on the patient's body. More than anything else, he is concerned not with speed, but with the beauty of the code.
Giant class hierarchy trees cover the project with dense forest, special attributes, generics, and interfaces hang from their spreading crowns. In the midst of this forest, factories of objects rise in monolithic rocks, callback functions, observers, iterators, visitors, controllers and other members of the tribe of gang of four fans roam. Somewhere deep in the forest, a code is generated that in turn generates a code that generates a code that generates an XSLT template that generates a user interface. All code is richly covered with comments on how to use it correctly and what it does. Patient delight is caused by projects in which he is unable to figure out in less than a few days due to a nontrivial object-oriented structure.
Changes in requirements are often accompanied by large-scale refactoring, the introduction of another abstract level, the allocation of new entities and the use of new technologies and approaches that I just read about in Habré. After reading the article on defensive programming, he starts shoving asserts into all methods. After becoming acquainted with caching data in memory, he caches all the data in the project. Having become acquainted with TDD, he writes a bunch of tests for elementary logic before writing the logic itself. The fruit of his works is monumental and delights colleagues at the same stage. He sincerely believes that the language in which he writes is perfect, and the technology is the most modern. Often a patient starts a blog in which he writes about how to write code correctly or use a specific framework, describes the bugs found in his code and witty, as it seems to him, ways to eliminate and prevent them. He subscribes to the blogs of evangelists of his favorite technologies and hears their words as the truth of last resort.
When he is confronted with the fact that his brainchild is slowing down, he takes on the profiler and tries to figure it out in a thousand-floor call tree. Sometimes it succeeds and the problem is solved ... yes, by introducing another abstract level with additional caching. Or vice versa, part of the logic is transferred to the database server as stored procedures.
When approaching the deadlines for the project, the patient suddenly realizes that too much is not yet ready, and time is spent on constant refactorings and debates about which pattern to choose. He spends the night at work to be on time and sometimes he succeeds. However, after putting the project, it is still necessary to maintain, add new functionality for the next version, meet the requirements of new users and here, again, suddenly , it turns out that it is almost impossible to enter the project in the monolith, without destroying it to the ground. Since they do not allocate time for total destruction, because the product is already working on production and this bug had to be fixed last Friday, the code begins to grow into crutches, props, quick and dirty fixes with comments “todo: fix this later”. And the more monumental the construction, the more monumental the props and crutches for it.
The patient's problem is that he lost content by form. He writes code like an artist paints a picture: with delight, with admiration, he is in love with this code and often forgets that the main purpose of his work is to write not a beautiful code, but a product that will work will work quickly and be easy supported. He often forgets that a software product is a commodity that has to find its buyer, which ( no, you just think! ) Do n’t care about the concentration of patterns on a line in the program code. But this user is willing to pay money for the fact that a new feature will be added to the product, which no one ever guessed when writing the first version, and adding this feature should not fall off a single existing function of the project and this process should take a minimum. And yes, it is really important for the user that these buttons have round corners.

Stage Three. Enlightenment

“I seem to be mistaken. No, definitely, I am mistaken. ”

Yes, the third stage is the realization by the patient that he is in the second stage of the disease and an understanding of his own shortcomings and mistakes. Awareness of the disease leads to healing.
Class hierarchies in a project rarely exceed two or three levels of inheritance; methods contain no more than a couple dozen lines, and more often less than ten. The code contains almost no comments, except for external interfaces that can be used by third-party developers who do not have access to the code. Surprisingly, the absence of comments does not make the code unreadable - the correct names of variables and methods, a clear code-convention and a small amount of code work wonders. If the action can be described simply and without the use of complex design patterns, then it will be described in this way. If there is a possibility that a more complex decision will simplify life in the future, then it will be implemented just enough to provide this simplification.
Declarative programming is used in places where it does not harm performance. The code is generated, but only where it saves developers time, and as a result, the generation is as simple and debugging as possible, even if for this you have to generate ten times more code. Unit tests cover only part of the code, but this is the part that may suffer in case of an error when introducing new functionality or fixing a bug. Before adding caching of data from the database, the patient will necessarily think about how necessary it is and whether the scalability of the solution will not hurt, just as in the case of transferring logic to the stored procedure code on the database server. He understands that buying another server can end up costing much less than rewriting and testing part of a project. However, in those places where optimization can give a serious performance boost, it ... is not done for the time being, but the code is written in such a way that, if necessary, you can easily speed up its execution. If this, of course, will be necessary.
Puppyish delight from technology and languages ​​gives way to a more relaxed attitude - everything has its time and place. The patient understands that each instrument is good for a specific range of tasks, and therefore does not take part in holivors on the topic “dynamic languages ​​vs. static "," Java vs. .Net vs. C ++, etc. He is pleased to try new languages ​​and technologies for his own projects, but decides to use them in the working code only after carefully weighing all the pros and cons and testing the innovations on a prototype or a separate project branch. He is critical of everything new, trying to highlight both pluses and minuses in it and carefully listen to all sides of the dispute, if there is one. He knows several languages ​​and technologies well enough to solve any task set before him, but not enough to master them in the volume he needs. The sayings of the evangelists and gurus are not perceived by them as the truth of last resort - he tries to understand not so much what they said, but why and why it makes sense . If the patient understands that in a certain case his own bicycle can be more effective than existing technologies - he writes his own bicycle, but only when he proves to himself the need for it. If the bike gives him the pleasure of his aesthetics and ingenious solutions and it does not contradict the agreement with the employer - he does not hesitate to publish the code under an open-source license or at least in general terms to describe the solution in his blog. And yes, if these idiots really want to see rounded corners in buttons, then the patient will definitely make them. However, the patient?

Instead of epilogue

I myself have never met a patient - it is rather a composite spherical image living deep in the cosmic vacuum, written off from my friends, colleagues, my own experience and just stories without authorship and origin, which from time to time come up on various resources on the Web.

Thank.