🛍️ 🤞🏾 👩‍💼 Bad advice to the employer. How to "properly" interact with the developer 💆 🐥 🚶🏿

I've been lucky lately - I work for companies where developers are truly respected. But this was not always the case; I had to deal with different approaches to interaction. I would like to say that “wild morals” are a thing of the past, but the stories of my colleagues about their previous places of work and my market observations disprove this statement.

Well, let's talk about how to "properly" interact with the developer, for example, personally with me ...

(If you went to the river with your whole family to swim,
do not stop dad and mom from sunbathing on the beach.
Do not make a scream, give adults a break.
Without bothering anyone, try to drown, - Grigory Oster) ...

When you plan my schedule ...

... remember that best of all I work in the emergency mode, sleeping 3 hours after yesterday's 40-hour coding session. It is at this moment that 2 monitors visually turn into 4, and the code begins to perform Native American dances to the uniform sound of a tambourine in the head. Only in this way will you receive from me non-standard, one might say, brilliant ideas. In this emergency state, the code begins to look like long noodles. It would have a file attribute of 'write only' if one existed. You can read such a code only by plunging into the same state of emergency that I wrote it in.

Unfortunately, team leaders are trying to lay more time when evaluating projects, and this prevents the formation of an emergency. Therefore, the best way is to spend half of the declared time coordinating the release date and discussing the project “on the table” (secretly, without leaving any traces). Remember, decoding TK is my favorite pastime, and it brings the rush.

Closer to the point, I recommend changing the essence of the task or transferring it to another team altogether - most of all I like those unexpectedly arriving projects that the previous contractors could not handle, and now I need to be in time no matter what. So, the last 5 days before the release will be the most productive!

By the way, here’s one “life hack” from one of your past works. A couple of days before the release, you can make it a rule to connect to me on Skype for 18 hours a day and listen to the clatter of keys and thoughtful mumble to be sure that I have not fallen asleep and write the “code”, and the next customer will not shoot you.

If you are unable to tighten the deadlines, then at least reduce the team. Remember: the emergency can be done in any project, if you quickly and quietly fire half of the developers. An even more promising idea is that having fired half, you can recruit others, inexperienced, and the more the better. But I can also teach children in the emergency situations, simultaneously correcting their code with the second hemisphere.

Do not forget that I need to be kept in good shape at all stages of work, including during planning. If I evaluate the task at four hours of work, feel free to call the customer two. It is clear that I have laid a reserve of time for idleness.

After assigning a task, remember that I need to be distracted at least once every 5 minutes. If I sit in the headphones, then I need to ask them to take off. After all, if you don’t check what I’m doing, I won’t work either or I will feel abandoned and lonely! I can also suspect that you are not doing anything, since you are not worried about the fate of the project.

The easiest way is to sign me up for all Jira mailings, all Slack public channels, and other notifications available (no appeal). Please provide me with a list of all the necessary communication channels. And do not forget to take the phone of my relatives, otherwise I sleep soundly.

Since you have the task of regularly “pinging” the entire team, get used to writing something like @chanel or any message in Slackallso that everyone receives a notification regardless of client settings. And demand an answer no later than 5 minutes later (who does not answer, you can call the phone)! Otherwise, how will the team live without reporting that the secretary’s cat has a birthday today?

By the way, you need to work with channels comprehensively. There are two optimal strategies: either do not share anything in the sense, discussing everything with everyone in one window, or use the fact that modern programs allow you to create thousands of channels, and try to put each issue separately. The main thing - do not delete then unused channels. And then suddenly their subscribers want to feel involved, but consciously enjoy the zen of silence?

If you don’t know how to motivate me ...

... make excuses for every bug found during testing.

This is obvious, if I was somewhere near the code, although I did not climb into it, then I broke it! Do not look in git blame, there you can find the author of a line of code. And then you will deprive me of the pleasure of reposting on Instagram another masterpiece with a joyful thought: "This is not me."

But the main thing here is not to go too far. If you suspect that I really messed up, try to keep silent on the contrary. Otherwise, how will I get a sense of the frailty of all things (including the futility of my own work)?

Yes, and forget the mantra “all project code is common”, it offends true authors and violates the right to private property.

To increase productivity, you can also bring me to some scandalous client, so that he would express in my face everything that he thinks about the latest release. The stratum of managers in this case will spoil the very feeling of vivacity that would not be possible without good abuse early in the morning. Ask the client in advance to transfer their charges to the individual. The main thing is to make sure that the customer review is not positive, otherwise I will relax and generally stop working.

If a client refuses to give feedback to developers, pass all the negativity yourself. At the same time, it is desirable to embellish a little. Remember - motivation was formed from the word “mat”. In an extreme case, you can call an emotional tester who sees only bugs in his work and is happy to tell the development how bad the application we are writing. And then (see above) I will relax.

I am writing perfect code for the perfect code. I'm not at all interested in how this code is then used and whether it is used at all. No need to distract me with a positive or, even more so, negative reaction to the functionality that we do. “I wrote and forgot” - my slogan. Why do I need thanks from users? Maybe even give them an autograph?

Hand out shortcuts to all employees. Let you have Petya, who “always works slowly”, and Vasya, who “always mows”. And there should also be Maxim who did this “module XXX”, and only he can make changes there. Otherwise, how will the new employees navigate the team?

More often remind you that Petya is slow, scold Petya in public, so that everyone clearly understands why. Remember: employees do not change and do not develop - it makes no sense to check whether the same Petya is corrected after a year of work in the company. If suddenly Petya does the task quickly, it’s better to praise him tête-à-tête. And then suddenly colleagues forget that Petya is still slow? Well, in general, scold publicly, and praise in PM.

Find a pet in the team and praise his dignity more, even if he does not fulfill even half of the tasks assigned to him. Let him get the most interesting tasks. Such a “right hand” should be in every boss. But how can you hold out on a leadership post without support?

Great shake - delayed pay. If the money does not arrive on time, I will definitely remember that I work for the money, I will pile up my thoughts and start working better. The effect will be greater if you carefully hide the news about the company. Let everyone around think that something is happening, but no one can understand what exactly. And support those who, with the help of their imagination, make the situation even worse. The more terrible rumors about the future of the project that go in teams, the calmer the developer works, who has a mortgage for eternity and a wife with young children behind him.

If the project ends, keep quiet about it until the last. Suddenly it will cost and the customer decides to repeat the same, rewriting on a fashionable framework again?

But in general, motivation is my challenge. Your task is either to fundamentally not notice me, or to withdraw from the comfort zone, as the Internet advises. How else will I develop? If you see that I don’t like mitaps and programming parties, make me go to them. And vice versa, as soon as I have a tendency to such a pastime, load with work so that there is no time left for parties. The comfort zone will not leave itself!

If you want to give me a task ...

... formulate TK as short as possible. Remember: brevity is the sister of talent, because I can guess all the details on three liters of coffee grounds left over from the last sleepless release. Ideal wording: “Everything should be fine!”

If the introductory came from the analyst too understandable, feel free to cut back! Only text, no screenshots. Even better - a video in Viber, in which you, while driving, talk for 20 minutes about the situation on the road, and in the last minute quickly report only the existence of the task.
If you suddenly have to attach links to some layouts or documentation to the task, try to relate to fundamentally different projects, at worst - to different versions of one project. Otherwise it will be too easy. And what kind of development without a quest at the start?

In TK, in no case should there be information about the exact version of the browser or operating system, no links to documents in which an error occurred.

There is nothing more valuable than human communication. You will cheer me up if you send it to the designer for the mock-ups, for the details of the task - to the analyst, for the specification of the API - to the client. Although he is not in our team, he is also bored and wants to talk.

By the way, it is better to prepare for this step in advance. In no case do not discuss the details of the task in a common channel, but what good things I will learn about it too much and will not go directly to colleagues with questions. Moreover, after seeing the communication of the task manager in the common channel, I might think that the PM is busy ... and is this possible? Always use only personal messages - so the fragmentation of knowledge about the project is higher!

For the same reason, you should not independently provide me with a stream of tasks for development. The task must be earned - find it from the same designers, analysts or testers. By the way, part of the tasks of these same analysts and testers can still be blamed on me. It’s generally accepted that it is the developer who writes and supports UI auto-tests! But the development can be removed from me. I love to start doing the task, and then give it to the “unfinished” as directed by the authorities!

Any task for me should be accompanied by a maximum of bureaucracy. How else will I be sure that it is really important?

Reporting on work performed should be as detailed as possible. If I don’t have to be noted in a couple of time tracking systems (team and corporate, for example), I will feel that no one appreciates my efforts. Only duplication of information will ensure the proper level of its safety! It is desirable that the reporting form is different.

It is worth agreeing that the duration of the tasks performed per week should not be less than 40 hours. Be sure to consider everything, even 2-minute breaks. If at this time the employee did not pause the tracker - disciplinary action!

Check the time reports at least once a week, arranging a general call to analyze each line. And finally, calculate the average speed of the encoders - everyone knows that the duration of the task is directly proportional to the number of lines of code written!

Set the condition for matching this speed as the KPI of the developer, so that the salary also depended on it. And then simple conversations that the task did longer than anticipated do not allow you to feel the importance of the process.

Speaking of phone calls and rallies ... there should be as many as possible! For any question, convene the whole team! And always at least a little, but be late. Honestly, I don’t know another way to emphasize my initial importance. Do not try to warn the person being added to the call, which will be discussed. Let him show how he knows how to jump from place to quarry. Let them procure links to any topic in advance and juggle them instantly. Or let him look for them in painful silence in private messages with the designer, the rest will wait. The rest can generally code during a call.

During the meeting, discuss all issues that come to mind. If even private inconsistencies, which are usually solved face-to-face, are brought up for discussion, the day will be more productive. So, for example, during the day you can ask all the questions about the current task of each employee. Thus, from 10 minutes daily time can be stretched to 2 hours.

And in order to have the opportunity to convene a meeting on the same issue again, never formulate any decisions in the end (what if they have to be implemented?) Meeting minutes? What for? The investigator has the protocols, and we are peaceful “trenduns”. If you still overlooked and someone formulated these actions before you, try to ignore them.

If you are planning a release ...

... remember that the best time to deploy is Friday night. All the same, everyone has free days off, so we will quickly fix all errors on production before the start of the next sprint.

And do not forget to leave the personal phone numbers of the entire team to the customer. Those who introduce the practice of duty are wrong. On the weekend after the release, the whole team will look forward to a customer call. The best time to chat is 23:59 on Friday, when I start to suffer that the work is over and there is a whole weekend ahead. Rest with family is a free thing, I will be glad to move it.

Everyone knows that it is necessary to release a solution in production on the same day as the release of some important API involved in this solution. The back should meet with the front closer to production, integration is an incomprehensible word. And do not listen to those who say that development is a team thing. Designers, analysts and testers in the project in the initial stages have nothing to do. Connect them at the end, better - a day or two before the release. And by the way, the next sprint, even for them, can’t be started cooking before we finish this one.

Build the process so that I need to switch context as often as possible. Let the testing queue be maximum so that my pool request is tested not earlier than a couple of weeks after I passed it. Corrections will be only better if I approach each bug, as for the first time.

In no case do not create separate stands for different development branches. How else do you check the mutual influence of different changes on the release? And be sure to use in the development of the database with production. Only in this way will the whole team feel a rallying level of adrenaline. Well, testers will be only happy to relax after the “killer commit” from the annoying and only stand.

If you accidentally get a senior level special ...

... in no case do not allow him to ordinary tasks. It’s much more effective to hire him 10 Jones as “apprentices” so that he turns them into middle men in a couple of months. He’s special, so he’ll succeed! Consider getting the whole team for about the same money. In every possible way, stop him from taking tasks and writing code himself, even if a kite flies over the architecture of the project and sees the project only with the help of a review. Delay the code review for a couple of weeks, do not rush the guys, there is no time to explain why.

The main thing - do not increase the salary of trained professionals. This is the right step to upgrade the team. Why not “squeeze” the already trained and not force the senior to learn a new party? Fresh blood in the team is always helpful. And other companies will know that you are a real forge of personnel. They appreciate it, believe me.

If there are no jones, so be it, give him all the interviews and the most interesting tasks. The rest of the team will be glad that they do not have to do it themselves. After all, everyone is delighted with the routine!

The modules that this senior will write should remain only with him - no one should have the right to touch them. Why review and refactor if you have the ideal in your hands? And do not show this code to beginners. And then suddenly they understand something there or offend the senior with the help of a review? Chick-chick - and to the master.

If you want to upgrade the technology stack ...

... think: the newer the technology, the more doubtful it is. There is no need to rush to switch to new versions and languages if at least half of the industry has not yet done so. Let others cones of migration stuff themselves. They say the truth - new technologies are easier than old ones. But we are professionals! We can work on the difficult! You did not gain the best in order to spend money and time on simplifications. If the developers have been working for a long time, tie them with the fact that old and well-known technologies are not in demand in the market. Bingo!

And if you choose modern technology for a new project, how will the customer understand that we are a pro team? And if you have your own framework and a bunch of code libraries, a universal constructor constructor, then you can never be updated at all.

If a developer is trying to learn something about new technologies behind your back, developing pet projects, try loading his main task harder. I’m developing in the technical direction only in order to get away from you for a lot of money (and faster).

By the way, forget about refactoring the project. We, the developers, came up with this wording to amuse our pride. And do not look for a fresh look at the code from other team members or from neighboring teams. As I said, we write perfect code for the sake of perfect code. There is no need for a review. Even if the developer works alone and does not see someone else's code, his own will be perfect. If the review is nevertheless required by the customer, make this procedure purely formal. Let the reviewer have the opportunity to simply click the green checkmark without reading the gist. Do not try to create tasks for closing technical debts and refactoring, this is a waste of resources.

If you took me to the office ...

... do not spend extra money on furniture. I can sit on a chair for 500 rubles. VHI is - then we’ll back up our back.

And do not put any horizontal bars and treadmills in the office. And then the developers will become runners instead of productive smoking. What is the perfect code when they have been sneaking for days on end?

Thinking through the schedule, try to make it as tight as possible. Do developers like to sleep in the morning? Nothing to relax! Let everyone come by 8:00. Did you find those who like it? Change the schedule. Now let everyone come by 10:00 - through the very traffic jams. The main thing is that everyone should feel equally bad - it rallies the team! We have already said that I should be as uncomfortable as possible. The graph in this sense leaves a wide field for maneuvers. Penalty for being late, racing in front of the door to the office - what could be more fun? Provide a day for remote work to an office worker? Fuh, a bad dream, do not remember.

If you hired me to work remotely ...

... try to get in touch with me as little as possible! Remote work was created in order not to talk with other Homo Sapiens.

By the way, I went to udalenka precisely in order not to communicate with that part of the team that remained in the office. Let them make their design decisions in a smoking room and preferably without me. Why should I participate in this?

Do not let me determine the working hours myself. If all office colleagues come at 12, then the remote worker must leave workplace at 12. And then what kind of udalenka is it, if you do not shift the schedule for the night?

The main thing is to give the remoter less freedom in choosing a watch. I can hardly appreciate the seriousness of the employer if he cannot insist on his conditions. And remember, the remoter is the one who is always at the computer. This is convenient, do not look at working hours, they do not comply with them. If you don’t bother the remote workers in the evenings, they may have something to start. For example, family or children.

Article author: Eugene Wetzel ( @imater )

PS My story has only ghostly coincidences with reality. Honestly, I have experienced them for quite some time in homeopathic doses, especially since I have not been an ordinary developer for some time. But I perfectly remember my feelings and thoughts.

And the moral here is simple: if we think about it and try to take these “tips” (with the right sign, of course) into consideration when planning work, everyone will feel a little more comfortable. And then, to look at all this from a different perspective, we will give harmful advice to the programmers from the company ... in the next article.

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.

Bad advice to the employer. How to "properly" interact with the developer