Dark programming

I propose to go to the side of evil, to the dark side of programming. Sith is stronger than Jedi. And there are enough cookies for everyone. I warn you before you read further. The nature of the transition to the dark side deteriorates.
I ask under the cat

Inverted scale of values

There is a legend that every time a programmer writes a bad code - God kills a kitten. It's time to admit that we are all killer kittens. Some have elbow blood. The first step towards strength is to recognize it in yourself. Any code is bringing chaos into the Universe. Any symbol - the growth of entropy. If we recognize this, then the mask of emotion and joy of coding will subside. Everything we do is bad. And nothing can be done about it. You can only try to do it in smaller quantities.

We are like samurai. We are trained to kill. But the point is not to kill. Or kill as little as possible. The best fight is not the start of the fight. The best code is not written code. Any code is evil.

The inverted scale of values ​​is the scores in the negative part - bad, worse, worse. There is no good, no better. Sith believe that the Jedi are mistaken in terms of: there is a good code, it can be better. Can not be. The negative scale is all around evil. And the Sith are forced to choose the lesser evil. Jedi choose the most good. Those. if they see two solutions, they see positive qualities and, based on their preferences, choose what is best.
')
A negative scale gives more gradations for action. Sith does not suffer from affection from the code. Jedi often "hangs" from the tenderness and joy of learning new things. He sees many ways to solve the problem and each of them "has a right to exist and advantages." Jedi has a problem of choice. Everything is so tasty for him. It costs the lives of new kittens. A Jedi, for example, can get carried away by something good and interesting and put an unnecessary framework into the project. Just because it's cool and new to him. If a Jedi sees some good decisions, then the choice often becomes an accident.

Sith does not suffer from the problem of choice. He does not hesitate in choosing. For him, it is obvious that everything is bad, therefore, it is less bad that it allows you to reduce activity.

There is a side effect of this approach - the character is completely spoiled. Sith any code calls govnokodom. What can destroy relationships in a Jedi team? A Jedi thinks something like this: “Each approach and tool has its own pros and cons, and the Sith is categorical for some reason, calling their applications govnokodom.” Pro cons Jedi cunning, because never concentrating on them, seeing only pluses in everything. Sith also calls everything govnokodom, such a scale. Depending on the task, he tries to reduce it, and not to admire another way to solve the problem. For Sith any bad decision. But some are worse.

Express the thought of the customer

The pinnacle of activity reduction is a direct expression of thought. Moreover, thoughts from the subject area. In this regard, a programming language is considered as a language of communication. It is a language in which to express thoughts. The popularity of the PLO is connected precisely with this: our natural languages ​​require the subject and the predicate. Subjects are objects, predicates are methods. This is not the world consists of objects, this perception and natural language like that. Sometimes incidents occur, such as “the wind blows”, “the light shines”. Rave. There is no object and its action. The same nonsense is sometimes found in the enterprise. But this has already happened, so OOP is often a natural form of expression of thoughts, translation from the language of the customer.

This is not an OOP ad. More stringent descriptions (see Stiffness) are welcome.

A programming language is not a constructor for programs. Just as in natural language there is grammar - knowledge of grammar does not mean that you can express thoughts, clearly, precisely, concisely. If you are still fond of patterns, optimizations, different possibilities - you are still a beginner. The ability to express a thought is the main thing. And not many times in the sentence met the letter "M".

Do not admire the possibilities that are provided with the language, such as working with multithreading and the like. All this does not apply to tasks, not to the thoughts of the customer. We are only interested in how much it allows us to concisely and clearly express the thought of the customer.

If the customer asks us to translate into the programming language “the dog has crossed the road,” then this is exactly what should be done. Not a cow, not a kitty. Many programmers are so keen on the process that they write: “A white lap dog in a gilded collar crossed the road at the corner near the tree, under which she had just needled.” Create not only the breed and collar. And they also build a bowl for her and a hostess. The entire infrastructure of the city. Because they perceive language as a constructor. What for? Yes, so that suddenly the customer wants to feed the dog afterwards, expresses such a demand - the bowl was already there, the city was.

Admittedly, sometimes programming languages ​​require you to create some kind of infrastructure. But then it is necessary to minimize this activity, because the programmer's efficiency will be calculated by the formula:

(Useful work) / (Spent work)

And do not deceive yourself that some WCF channel is entering useful work, and the customer is dreaming about it, just does not know about it.

Kill the humanities

Once in a private conversation, a friend, a psychologist, drew a big daw:
And asks:
- What do you see on the sheet?
- Galka - I answered, not understanding what this question was for.
- Nothing will come of you. You are not a creative person, not capable of creativity. This is a simple test for creativity. And the more creative a person is, the more bizarre he sees forms. Some hearts, clouds, some even horses.
Then he adds with a sigh:
- But for some reason mathematicians almost always see a daw ... Rarely - a sign of infinity.
I:
- They see a daw, because it looks like a daw.

It was then that I formed the opinion on how the analytical mind, the exact sciences, differed from the humanities and arts. Man interacts with the outside world and creates artifacts. The only difference is where the flow of information comes from when creating an artifact - from yourself or from the world. In the exact sciences, they are engaged in the knowledge of the world and try to make fewer assumptions from themselves. It would be ridiculous to hear a nonsense with the words “I see this” when solving a problem in physics.

Creative people easily say so. And creative in the code. Every time when I hear from programmers "we have a creative profession," "everyone can be right, everyone has their own opinion", "there are a lot of ways to solve" - ​​I remember horses instead of jackdaws. Each time, usually, with those words, programmers have already conceived something - some kind of flexibility (about which later).

In the exact sciences, there are several ways to solve a problem correctly. But to solve it is wrong - an infinite number of ways. The correct decisions are usually based on mechanical rules.

We, the programmers, have a source of external information - the customer. There are not as many ways to translate his requirements as accurately as possible. In addition, each programming language offers its own natural way.

What else distinguishes people with an exact mentality is that language is used to express thoughts external to the language.

Children's riddle:
What is in the middle of the Earth?
Answer: the letter "M".
This is an example when an object is confused with a part of a language - a word.

People with an exact cast of mind operate on objects, not words or language constructs. Conversely, people with fuel and lubricants sometimes find beauty in sounds, in combinations of words, hidden meaning in the roots of words, and the like.

Siths need to kill the humanities in themselves. We are not creative people, we are engineers. Yes, now it is not fashionable.
To operate with meaning in the code is to express the thoughts of the customer. But the Jedi are so addicted to the language, its properties and constructions that they go over all facets in their work. It looks ridiculous from the side, just like horses in jackdaws.

Rigidity

Programs must be rigid, not flexible. Recognized in a Jedi? The Sith have an inverted scale.
Universities and books teach that bad code is an inflexible code, hardcode. This is a worldwide conspiracy and deception. It's exactly the opposite. The program must meet the requirements of the customer. And at the moment. And the point. And to satisfy the most rigid way, the most limited. Program limits are like rails for a train. The program must fulfill its purpose and not deviate a centimeter. In this regard, a sure ally - static typing. The programmer specifically creates types that cannot be allowed by the program to be in forbidden places altogether, and this is checked by the compiler before launch.

Program flexibility is not a priority at all. How can the program be both flexible and tough at the same time? The trick is not learning; they forget that the only important thing for a program is to be correct. The fact that because of the hardcode there will be problems in the future for the programmer, if the requirements change - should this concern the customer? This is a Native American problem. But they all concentrated so much on flexibility and patterns that stiffness began to be censured. When as soon as she and ensures the correctness of the program. Of course, a bad hardcode will bring problems, which goes against the Sith minimization of activity. But at the pinnacle of our worldview stands the brevity and clarity of presentation of thoughts in the program. So, the program is easy to rewrite, change the code. If there is flexibility, then it is “forced”. In the evaluation of the effectiveness of the development should include not only the language itself, but also the IDE. You can not lay the flexibility for fear of change. Not working in a notebook.

Killing program and bugs

Sith love bugs. They are waiting, they are respected. As soon as a bug occurs, the Sith throws everything and pays attention only to him. Bugs have such a nature: until they figure out the reason, the importance and damage of the bug are not known. If there is a bug in the program, the program loses confidence. It is better for her not to work. A program that does not work generally takes priority over something that works. A program that continues to work simply eats resources, and does not produce a beneficial effect. At least, it is not proven that she is doing something useful. Moreover, a running program often hides a bug. Who are waiting for the Sith.

Since the Sith are waiting for a bug, the priority is that the bug be very noticeable. The more persistent he shows himself, the better. And what is not the best way to grab attention, how to drop the program? I saw a couple of times the application where errors are added to the log. And as you can guess, this log does not read long periods.

A worse option is not to drop the entire program, the whole process, but to intercept an exception at the top of the stack and pass it to the support. Such options are acceptable for many solutions where independent operations are performed. For example, often when working with a database. Each operation is relatively independent and the program continues to work if it has not completed or cannot perform any one. But in general, it is impossible to make such assumptions.

I (as a Sith) do not urge to write software that falls with every breath completely. Here, it is necessary to choose the lesser evil and take responsibility, which is more dangerous than the simple one, when everything fell and the error is corrected, or the continuation of work, when only a single operation falls. The second solution is often more acceptable.

The worst option is when the programmer believes that the program must survive, including every local piece. Each method is written as if it is on the battlefield surrounded by some enemies, not having allies. And he tries to solve the task entrusted to him, if he cannot, then find a workaround, if he cannot, then he will just survive. This is atsky govnokod. Even search for a workaround. If something happens that the method has to be bypassed, it means either a bug in the external code, and the method covers its activity, or the programmer does not know something about the code external to the method. What is fraught with. Writing using the “random” method is not a sign of a beginner, but a nulevich.

Conclusion

I think at least these items are enough for today. It does not pretend to be a manifesto or a full review of how to evaluate the code and develop it. But the general situation - an inverted scale, provides some advantages.
I hope the day was not boring.