What developers are NOT talking about or 7 favorite programmer expressions

Friends! We all love (or do not like) to talk about design patterns. Personally, I strongly dislike them, because most of them are fairly obvious to a more or less experienced developer, and stereotyped thinking has not helped anyone in life.

But we’ll talk today not about them, but about other patterns, namely patterns of behavior, our human patterns, but rather even antipatterns. To add fuel to the fire I would like to decipher the name of this post a little.

In everyday life, I try not to use the word "programmer". It has a negative connotation for me and I immediately recall the 90s, when no one was called programmers. They and the cartridges from the printers were changed and the accountants' grandmothers helped their first computer to master. Remember this imperishable "You're a programmer!"? In general, this word has discredited itself.
')
I somehow got used to calling my people developers (developers) and for me a programmer is a kind of antipode of a developer. Well, with years of experience, I learned a large number of anti-patterns for a good developer, which he should use as little as possible. The less I hear them, the happier I am. So, we proceed.

001. And on my computer works

This phrase is familiar to everyone who has worked in the industry for at least several months and simply should be excluded from the lexicon of any developer. Dude, if you send a code for testing that does not work on your computer, then you have no place in the profession! By definition, your code always works on your computer. How could it be otherwise? But it does not work for the tester, the client, but anyone, because you did not take into account some nuances, differences in the environment, data, weather on Mars, and your task is to find out what exactly to fix, and not to try to immediately retract and prove your innocence. There is nothing terrible in the fact that you did not take into account something. In my practice, there have been cases to take into account that could only ... Yes, no one could!

010. What asshole user does (c)?

Dude! Users are not assholes. These are the people who are forced or not to use the creation of your hands and that the most interesting pay for it. Where does your salary come from? Do not you know? And I know. The same Innokentiy Petrovich, whom you have already called an asshole 3 times, paid us for a one-year subscription.
Our favorite users are cooler than any testers and make such fintels that everyone comes to their head. But this is not their cant, and ours. Once done, then we let them and we are responsible for the consequences and deal with them. In the practice of the world software industry, there is more than one case where the conviction “Which asshole will do this?” Resulted in losses of hundreds of thousands of dollars. Well, who ended up being an asshole?

011. Testers nifiga not tested! What are they finally doing?

Dude! Remember once and for all that testers are not responsible for software quality. All that they do is measure its quality and tell you whether it is high, sufficient, or complete shnyaga. Responsible for the quality of software in the first place, its designers and developers. If you fouled up a govnobild and gave it to testers, and they got rid of the critical bug there and released it in production, then this is first of all your joint, not theirs. Although they, too, will fly for the fact that they did not notice. Your task is to develop the code as if you are the last frontier and for you only production and millions of users. No need to count on the fact that testers will catch all the bugs and you will have the opportunity to correct them. No one except you knows your code better. Write tests, ask questions, eliminate extreme cases and may the force be with you! There are many companies in the world where there are no testers in the usual sense. And nothing, live.

100. What idiot wrote it?

It’s not sad, but there is a significant, non-zero probability that the answer to this question will turn out to be: “Me? EPT! There are no ideal people, we all make mistakes, cut corners under severe constraints, and we learn to write perfect code all our life. Most normal developers are pulling away when they see their own code at the beginning of their careers. And that's fine. Remember this and think the next time before calling someone an idiot. Software development is a team game and you shouldn’t spoil relations in a team for petty bullshit. It is better to communicate with the brow and explain to him what is wrong in a private conversation. If it is adequate, it will only be grateful to you. Or you will begin to see clearly that is not at all possible.

101. Finish 99%

This is just a classic. It is impossible to win, but we must fight. Dude, remember, when I ask the status of your task, in most cases I am interested in the answer to the only question: “When will the task be completed?”. In an hour, 2 hours, tomorrow in the evening or on Friday. I am not very interested in the intimate details of your difficult relationship with another jQuery plugin. And even more so I do not need to talk about 99%. As my practice shows, 1% can last for an hour, for a day, and for a week. High-quality detailing, planning and estimating the timing of tasks is one of the most important characteristics of a mature developer. Therefore, when your team-leader next time asks you about the readiness of your task, you will answer him clearly “After 3 hours you will be ready” and, most importantly, you will keep this promise. If you are not ready to give such an assessment, then it is necessary to clearly and clearly explain why, and set the expectations correctly so that no one is let down.

110. This is impossible!

Dude. First, we both know that this is possible. There are no such tasks in the industry that could not be solved by a motivated team or a developer. When something really interesting and necessary for us, we move mountains and do it. Bill Gates wrote a FAT while flying a plane from New York to Seattle (I know that bike). If you tell me "This is impossible," then this is a well-known sign of pronounced frustration associated with this task. The most important thing in such a situation is not to try to invent contrived arguments and drive the problem situation even deeper. So it is possible to reach a serious conflict. Instead of saying “It's impossible!”, You just need to pause, think, cool down, and then sit down with your team leader or leader and talk through the problem. If you have an adequate one, then a solution to the problem will be found and will only strengthen your reputation.

111. I will not do such nonsense.

By and large, this is a variation of the previous problem. As a rule, this statement means that you, dude, simply do not want to and (or) are not interested in doing what they ask of you, or you have your own, very different opinion on how it should be done. If you are a professional, this means that you are paid money for the work performed. If you are not satisfied with the proposed work, then be a man, do not nudi and just change it. And one more important moment. You cannot know and understand everything. Sometimes you just need to take and do as they ask you. You may not like it a thousand times, but still be the right decision. Often, client managers, managers really know better because they communicate with customers much more often, face their problems and, as a rule, are ultimately responsible for their satisfaction.

Thank you for your attention, Happy New Year and I hope this post will make the world a little better!

PS Sorry for a bit of a sharp and familiar style of presentation. It is necessary.
PPS Offer your patterns in the comments. I'm sure I have not yet learned everything.