📨 🕟 👑 Bad advice to the developer: what to do to “please” the management 💃🏻 🕴🏻 🏓

As promised in the previous article , we are turning the situation in the opposite direction. I happened to be not only a developer, but also a leader at different levels. I have already mentioned that lately I have been lucky for teams and colleagues. But for all the time everything happened.

(Grigory Oster)

Let's talk about which developers the management dreams of. This time I will act as an abstract manager ...

At the start of any project ...

Did you know that the highest skill of a manager is to make decisions with minimal initial information. Do not stop us, leaders, from training this skill. Follow these tactics:

Name the foggy dates, but rather do not talk about them at all.
When we ask if the proposed improvements will not break the existing modules, be silent, in a pinch, make a mysterious facial expression!
Talking about the upcoming problems of the project, never offer your solutions, remember, we need people-questions, not people-options-solutions.
— , , ? 48- , 10 , .
— , .

If at the stage of setting the task you were admitted to the client to ask him clarifying questions, learn from DDoS attacks - give all your best. The client expects from you at least 50 messages with questions, preferably in detail - he will appreciate your performance in the epistolary genre. You don’t need to attach any screenshots or videos - let them decrypt your message, even if it contains only “Hello!” and a long “typing ...”.

Remember: the client and the end user are different people. Never communicate with end users and do not try to imagine them! If Aunt Masha at the checkout should see 25 lines of text on the monitor, calmly place them without looking at the screen size. Let the magnifier take if she does not like.

Never tell us what specific tasks will be solved within the project. Talk only about solution methods. And it is desirable in all details - how else would CTO sleep peacefully tonight?

In your story, by no means mention money, time, or other metrics that others understand. After all, even the director’s secretary can translate stories about the abstract structures used into user scenarios and the exact amount of profit that we get. So when evaluating tasks, use the most abstract system of quantities. Remember, 1 boa constrictor is 38 parrots!

Harvest as many surprises as possible. Let besides time to solve the problem, it will also require paid subscriptions or tools, which we will not know about until the last moment. We love the pitfalls and will be happy to look for a way out of the deadlock before the release. My client and I love to increase the allocated budget weekly, constantly coordinating it through all instances. Drive Ivan Tsarevich through a new iteration from the beginning of the tale after each update of information about where Koshcheev’s death is stored.

Perfect code ...

Try to write only perfect code for the perfect code. It is not necessary to do this the first time. If in a hurry, write in a quick way, then redo and then again. Remember: repetition is the mother of learning. If the code has been rewritten three times and at least slightly different from the ideal, urgently start refactoring as part of a small task that does not apply to this. Better yet, transfer your code to another library or framework. Let the code be fashionable and youthful. The main thing is that in no case can all these processes be formulated as separate tasks. And then suddenly we guess that something was not ideal on the project? Things like this are best done just before the release. At this moment, the whole team is working much faster!

Speaking of refactoring. It will work more efficiently if you simultaneously change the mechanisms in the code - so as not to climb there twice. Remember, such processes should affect as many components as possible. Why spend time picking in individual modules? Only in this way will you end up looking like a hero who saved everyone! Other developers will be happy to discover the surprises of the new mechanisms when they shoot them in the foot.

The perfect code should be properly formatted. Try to create files of maximum size, occupying many screens and containing several components at once. Following this style of design, you can heroically overcome merge conflicts and for a long time agree with colleagues whose edits were more important. The code should resemble the longest noodles, no need to waste time creating small, insignificant files. For the sake of one function, invent a file name - what could be more painful?

The perfect code you created is not necessary to cover with tests. You can only talk about the need to bring coverage to 100%, but in reality 10% is enough. To keep up with you, add a couple of tests that in fact do not check anything, then they will not have to be updated.

If it suddenly turns out that a quickly written solution does not work or does not work as expected, feel free to blame the system architect, API, server administrator, etc. for everything. It is clear that your ideal code cannot but work. Remember the main thing: we, like you, know that an ideal programmer can only work in a vacuum in ideal conditions. And if you are distracted, do not give information on time, write incomprehensible TK, then you generally cannot be responsible for the fact that the implemented module does not fulfill the business task. Well, right, business is our responsibility. It is advisable to keep all the names of the guilty factors until the deadline, they will be needed later, now do not distract the leaders.

When we talk about the need to quickly release MVP, feel free to ignore our attempts to speed up the project to the detriment of quality and speed. Nevertheless, they know that with a good idea, you can start on the market at any time. Time does not play any role. Let the competitors shit, and when you write the perfect code, our MVP will soar in 5 years. And all these years, investors will be happy to pay for creating a masterpiece with their money.

The order in the project ...

Your task is your personality. Creative mess will add weight to our eyes. The ability to build a mess and maintain it in a rather chaotic state is so valuable that we even transfer projects from hand to hand in order to increase the degree of disorder. As soon as the chaos reaches its maximum, we will reward you with a new project!

If you understand that a full-fledged mess has formed on the project, but you have not yet been relocated, either start digging in your technical debts with your paws, or ask for another project yourself. Perhaps we just did not track the situation.

Everything that happens inside the team must go through us. Even if you decide to go out for a smoke with the tester, be sure to agree with him through the project manager, but it is better to involve CTO in this. We feel unnecessary if no one complains about our colleagues, doesn’t turn to solve disputes within the working group or introduce some work rules.

On design issues, it is advisable for us to write only in PM. This will hide all traces of our activity from the higher management, and at the same time will force us to retell the worked out solutions to other participants in the process. We love it so much!

Problem solving ...

Once you have solved the problem or fixed the bug, in no case do not check your solution. Shout “Hurray” and run away from the workplace as quickly and further as possible! So you will hand over the task faster and find the team a lesson for the first half of the next sprint - you will correct the jambs of the task just delivered. What is important, you also do not deprive the work of your fellow testers. A set of bugs caused by the new crutch in the solution is the best gift on Friday evening! Check in your code only one successful case, you are an optimist.

The correct sequence of actions when solving a problem:

read TK, ignoring notes,
have a smoke to forget the details,
quickly and without hesitation implement only the basic functions,
pass the task just as quickly
Get revisions with clear decryption of unread TK notes,
so be it, fix the problem in 3-4 iterations.

No refactoring in the wake, no combing of code. Let the variables be called as your left leg wanted at the moment of insight, and the code remains poorly read. It’s not for you to understand this later! Well, train to take your code for review right away - you're a good, but touchy guy.

At this stage, it is impossible to create any evidence that the task has been completed (or they will sometimes come up with a video to write on the project how the module starts ...). Perhaps the tester will not notice any discrepancies with the TOR, or else the task will be sent to another one, while for now you can relax on a new task.

If there are ambiguous moments in the task, for example, it is not known whether the input field should accept only English or Russian letters at the same time, feel free to answer the questions yourself, in accordance with your tastes and life experience. Since it is not written in the statement of work, this should be obvious to everyone!

And never test any hypotheses on a small part of the task, otherwise your colleagues will think that you are in doubt!

If you are in a hurry with a task for release and understand that some functionality will need to be completed later, you don’t have to spend time setting a task in the project management system. It’s better to make a note directly in the comments to the code and do not tell anyone about it. So it will be even more interesting to catch technical debts. There will be a feeling that there are a lot of them and you are still very needed on the project.

Keep no more than half of the files in the project repository! No wonder so many different storage locations have been invented in the world. It is important to place the remaining files evenly between the personal repositories of employees and, for example, the documentation (not even necessarily for the current project). So “secret knowledge” about the project will be divided equally in the team and everyone will be irreplaceable. And then some newcomer to the project will come and figure it out quickly in the already implemented one. Something you can’t resist in their places - everyone will instantly be replaced with cheaper jones.

Every project should have secret knowledge that is passed from mouth to mouth. Only in this way can you take a sigh of a picture and, spitting, say: “Oh, these junes have been working for a week, but they don’t know anything about the project. Stand back, do it yourself! ”

If you undertook to carry out any task from Jira, it is absolutely not obligatory to mark it. We are mediums - we’ll guess what you’re doing now, but at the same time we’ll guess the current state of the project. By the way, we can do this with the time spent - we don’t have to write anything anywhere, we will find out the number of hours worked and calculate your salary.

Communication on the project ...

Have you heard about omnichannel? Communication without dividing into different channels is the latest trend. Be in trend! For any questions, write PM to some messenger, it’s better personal, not a worker - so that he knows that you are not behind the latest trends of this world. But project teams in Slack and other messengers are best used to send funny pictures with cats and personal conversations.

Be late for regular meetings 15-20 minutes. Better yet, have a Soviet-era microphone and Wi-Fi away from the workplace. Let everyone listen to your croaking, it is like abstract paintings - everyone hears what he wants to hear. And at the Daily, you can ask all the questions that you have on the project. If there are not enough design issues, add more offtopic. At worst, you can always ask something abstract. Such a good example best reflects why you do not like phoning and why you better not attend them.

Well, do not forget, every person has high-speed bluetooth in his head. Therefore, if you have already imagined everything in your head, then just transfer this picture. Words can explain only small details that were not visible in the picture. Let them try to understand you, this is their job.

By the way, it’s worth to be late to the office if you work in our territory. This is the only way to create an impression of your importance. And never warn about being late. This will show that you were in a hurry, i.e. spoil your image of a calm guru.

If you leave your workplace, you don’t have to bother with the arrangement of statuses in Slack or other instant messengers. Anyone who writes in your absence (and initiates a notification) will give a reason for a long and thoughtful curse that you are being distracted in your personal time. Where else would you find such a reason? And let managers and colleagues learn to accumulate their quick questions before the start of your official working day (there will be something to discuss in the day).

Exchange of experience is superfluous. Therefore, if you still post any link to an article or framework to the Education channel in Slack, you do not need to make any description for it. Let it be a quest for colleagues. They want new knowledge - let them strain and understand what you threw to them. And it doesn’t matter that this may not be their area. And in no case do not share your project observations, interesting decisions, bugs and instructive conclusions. Developer to developer wolf. You must compete, and not grow a common team experience! And yes, I almost forgot! If you find a lengthy article, then do not read it yourself, just lay it out to your colleagues, maybe they will be interested.

The work of fellow developers can and should be criticized. You have to find fault with every little thing. Just do not confuse criticism and review. It is necessary to criticize extensively and with taste (and preferably as abstract as possible, for example: “Your code is terrible”), but conduct the review as quickly as possible - click the green checkmark without looking at the code and leaving no comments. And then some constructive reasons for dissatisfaction will have to be formulated.

Transfer to us all responsibility for your motivation and advanced training. We are already resting for you, even helmet photos from different resorts. Let us also come up with a motivation for you ourselves. It’s clear that on the project all the tasks are interesting and only out of harm do we find a routine for you. And we arrange rush-offs on purpose, because you work better in this mode. However, we do not enroll you in courses either out of harm. You transfer all your needs to us via bluetooth, which is built into your brain, we receive them, but ignore them. No need to turn them into words, we feel them anyway.

Toward the end of the project ...

When we ask you to show the project to the customer, in no case do not prepare for the demonstration in advance. It’s clear to everyone: if the project started on your laptop, it means that it is 100% working and will start anywhere. We are all lucky!

If, according to the results of the demonstration, the customer is unhappy, you will feel an impending conflict, you must send the customer to hell. He just doesn’t understand anything. And there is no need to inform the manager. By the way, a conflict with a client is the best reason to ask us for more money. We will gladly agree!

The release date is a fiction. We just love to mark these dates on the calendar. In fact, managers, especially on the remote, really lack communication. And postponing the release dates is the best way to quickly convene 3-5 meetings that people will not refuse to attend.

When the situation on the project is heating up, it's time to dissolve rumors that everything will soon collapse. Devote as many colleagues as possible to your assumptions, spread more negativity. If the rumors are justified, their distribution motivates us to correct the situation with the wave of a magic wand. And if not justified, we are glad that you are still in good shape.

By the way, if the rumors do not help, start to panic in chorus. This is the most constructive solution. At this point, you can begin to talk nasty things about the company, not only inside, but also outside (for example, at interviews). This will definitely help to equalize the financial situation and get yourself strong colleagues in your colleagues!

Toward the end of the project, you can leave it loudly and effectively, articulating the reason for leaving as a too low salary, despite the fact that you have been on the project for so many years and for the sake of us do not touch new technologies. Feel free to go to the competitors - they will appreciate it. Our favorite quest is to search for new specialists a week before the release. When you leave for another company, do not forget about us.

Tell everyone about one side of the problem. Be silent about your “exploits”, tell us about which managers are unfair. Do not try to understand us, tell outsiders. NDA came up with cowards!

All pitfalls should be reported only as a last resort - if the project cannot be put into production. This is the best team building when the team jointly “puts out the fire” on the night before an important release or already on production. Do not deprive yourself and the team of this pleasure!

If you still experienced a release in the team and something went wrong, you can safely put bugs on production at the end of the queue. They should have the same priority as everyone else. Let them get in line!

Well, and know that on the night after the developer is appointed to the position of service station, deep metamorphoses occur with him. He forgets all the needs of developers, becomes short-sighted, authoritarian, stupid and inaccessible. Therefore, we - managers, managers and service stations - so poorly understand you, the developers.

Article author: Eugene Wetsel (imater)

PS Like last time , my story has only ghostly coincidences with reality. And the moral is this: let's take into account all this sarcasm, building relationships in the team.

PPS We publish our articles on several Runet sites. Subscribe to our pages on VK, FB, Instagram or the Telegram channel to learn about all of our publications and other Maxilect news.