“Silence is gold”: 13 things that developers and testers should not say

/ photo Sistema Bibliotecario Vimercatese CC

Virtually every large organization hires software development staff. At the same time, only a third of them are directly involved in the IT-related business. But no matter where they work: in a pharmaceutical company, in an educational or advertising field, they remain programmers.
')
Teamwork is a responsible occupation, because in this case people are responsible not only for themselves, but also for those around them, they communicate and help each other. No matter how trite it is, politeness and mutual respect are always the key to productive communication between people. However, there is still a certain list of phrases that - even when they sound politely and correctly - should not be used in conversation with developers and testers, if you are their colleague, customer, “owner” or project manager.

1. "Can you finish testing as soon as possible?"

Testing should be conducted thoughtfully and carefully, so as not to miss critical flaws. Good testing is the key to a quality product. Of course, there are tools to speed up the process (here are a few tutorials on test automation proposed by the Stack Exchange residents), however, even automated tests have to be maintained and constantly modified.

Ideally, testing begins at the design stage of a product and continues until the release itself, while designers and developers interact closely with testers. If your company is different, then, congratulations, you have learned the recipe for delays, mistakes and budget deficiencies (here are a few things testers don't like to hear).

2. "I do not have time to read the bug report, describe the problem in a nutshell"

Testers (at least, good ones) spend a lot of time and effort compiling bug reports, thoroughly writing down all the steps necessary to reproduce the error. Such a careless attitude of a manager or developer leads not only to the wasting of time of a testing engineer, but also to other serious problems. Always read bug reports!

Do not underestimate this advice: once I had the imprudence to say something like that. At that time I was a young specialist and did not have much weight in the team. Naturally, I heard the cherished two words, but not about the essence of the bugs, but about my beloved one ... It took at least a week to restore normal relations with the tester.

3. “Promise me that there are no bugs”

The role of the tester is not “quality control”, but “assistance in achieving quality”. The task of the tester is not to verify that the product is implemented without errors, but to make sure that it meets (or does not satisfy) the specific requirements of the company.

There is a saying in business: “Promise less, do more”, therefore you should not chase 100% coverage of the code, you need to focus on the quality of the tests performed.

Leave extravagant promises to the sales and marketing department - let them do it. Test products with reality. By the way, there are several podcasts on QA that you should pay attention to.

4. “Leave it, I'll finish it myself later”

This error occurs all the time. Sometimes, to complete the task quickly, you take everything into your own hands, without waiting for the developer to figure out the problem on his own. We advise you to stop doing so. Try to act as a mentor and train specialists to grow their skills with the company. Sometimes it may seem terribly inconvenient, but in the future this approach will help you a lot.

A good leader is distinguished, first of all, by the fact that he is able to grow a replacement for himself. If you do everything for your employees, they will never learn anything. As the owner of the project, you must calculate the situation in advance. What if I get sick tomorrow? If the team can independently solve problems, nothing terrible will happen.

However, it is important to avoid situations where senior developers act as mentors for a large number of juniors, due to which they do not have time for other tasks. In such cases, it is worthwhile to appoint a certain mediator who would be engaged in mentoring and addressing senior colleagues only on complex issues. Also a good solution would be to write your own documentation and training courses (here you will find a couple of practical tips ).



Important : try to share "tasty" and interesting tasks with subordinates. For this, they will love you.

5. "I have a small question ..."

The phrase is not the most successful. Even if the question is really short, the answer to it may not be. Try to ask for a start if your colleague has the time (now or in the future) to answer you in detail. Give the other person the opportunity to refuse an immediate response and set aside free time for you in the future.

If it is an urgent matter, then this rule can be neglected, but try not to do this too often. You do not want to become a manager who shouted: "Wolves!".

6. “I went home” (refers to the project manager)

In short, the main task of the project manager is to monitor the implementation of work. When the process is stopped, employees give up or transfer the arrows at each other for errors, PM enters the work, who understands the situation and finds a way to move forward.

It is important to be in solidarity with your team. Spend time with them. Developers delayed to quickly complete an important project? You too should be in place - do not demoralize your people. Team strength in unity, support and respect. Do not leave the developers to their fate at a difficult time.

7. "Here he will do it faster than you."

Each works with its own speed and has its own strengths and weaknesses. Someone performs tasks quickly , and someone needs time to think. However, it should be understood that speed is often the opposite of quality and cost.

Pay attention not to the speed of work, but to the ability to " predict " how long it will take to complete the task. The main thing is how objectively a colleague assesses his capabilities.

8. “I see you haven’t written code for a long time”

Programming has not declared the amount of time required to create a line of code. A function that has just been written may sometimes require time to rethink, so if a developer hasn’t done anything for several hours, then he doesn’t necessarily fall asleep (there is such a probability, but it is extremely small), he can search for information on forums and reference books or think what Changes should be made to the code.

9. “What are you doing all day?”

Subject arising from the preceding paragraph. A good programmer gets used to asking himself the question “How do I make X well?” Instead of “How do I make X?”. At the same time, 95% of the developer’s time is spent thinking about how to reliably implement the solution and align it with the current architecture. The rest of the workday is writing code. Well, sometimes, still ping-pong and reading news sites, such as Reddit or Habr.

If a person has not written code for several hours, this does not mean that he does nothing, most likely, he is looking for a beautiful and competent solution. We recommend reading this article , which explains why you should not evaluate the work of the programmer only on the "appearance".

10. “This task is possible even for a student, just take a template”

By giving the “student” important tasks, you risk paying twice as much if you have to redo everything. In our experience, in 1cloud we can say that developers are very annoyed when a customer or a manager gives an assessment of the complexity of the task and the labor costs for development, based on his subjective experience. In this case, quite often the manager does not have specialized knowledge in the development, but tries to impose his assessment on the developer.

In general, you should avoid any inaccurate phrases when assessing the timing and complexity of the development. For example, the phrase "This is a damn task, a couple of hours maximum ...", expressed by the developer himself, says that the task is likely to be really done quickly.

If such a judgment comes from a manager or a customer, an unpleasant effect arises: the developer may well think that, calling the task “trifling,” the customer devalues ​​his work in advance. So be sure to involve developers and testers in the assessment of labor costs, do not try to decide for them how quickly they can do this or that work.

11. "Look at this, it is urgent to do ..."

The work of the programmer is comparable to the work of people of art. The programmer focuses on the task, as an artist, and holds a very complex picture in mind. When you interrupt his thinking with “urgent” matters, he “drops out” from the stream. According to research, to return to a state of concentration, a person needs at least 15 minutes (read the article on how to work in a stream), so distraction is extremely annoying.

Managers should try to build work in such a way as to issue tasks in the morning, and in the evening to accept the finished result, without once again distracting the team in the middle of the day and allowing everyone to work at their own pace. It is necessary to provide colleagues with silence during the working day [and the speech, rather, not about the deathly silence and / or the ban on listening to music with headphones, but about the absence of annoying conversations] - the effectiveness of their work will be much higher.

12. “No refactoring, the product is needed today!”

The more “crutches” in the code, the less programmers like it, and the less it wants to work with it, especially when it is not allowed to be rewritten. If you do not follow the state of the code base, there is so much “ dirt ” that any changes have to be made using hacks. This leads to decay of the project.

The work on the code resembles the game “Djenga”, when players take turns in taking blocks from the base of the tower and put them on top, making the tower higher and less stable. So, in order for the tower not to fall, it takes time to make changes. Give the team one day a week to refactor, otherwise one day the project will have to be rewritten from scratch. Refactoring can increase not only the readability of the code, but also its performance, which will make your customers happier.

13. “How did you become a developer? I would find some summer job for my nephew / acquaintance / etc. ”

This question is most often asked by people who have a remote understanding of the creation of software products. They believe that modern technology allows you to write a program in just a couple of mouse clicks. Yes, ancillary services simplify the work of the programmer, but for an inexperienced person, a popular framework may seem [and inevitably seems] a dark forest.

For these reasons, it is unlikely that it will be possible to find a part-time job for the summer. But in 6–7 months, with due diligence, it’s quite realistic to acquire basic skills (with the help of online courses, learning from open projects, etc.) that are sufficient for work. However, this depends on the target programming language and the vacancy.

The main thing is to remember that the work of a programmer is not so much a profession as a lifestyle. University education, self-education, hobbies and, importantly, passion are key components of success in this area.

In our work, we, perhaps, faced almost all of the above situations. And any of them can easily knock a developer / tester out of a rut. Of course, it makes no sense to "establish a ban" on some words - it is important to simply understand what you want to convey to a colleague, and what consequences such a decision or deed will lead to.

Therefore, in the process of developing the IaaS provider 1cloud, we strive to ensure that all professionals, including developers, have a fairly large degree of freedom in the project and are responsible for the result of the decisions made. This allows managers and developers to feel one team and quickly resolve any controversial or slippery moments in personal communication - when all employees understand that their work means, their opinion is taken into account, misunderstandings in the development process are avoided - even if the “forbidden phrase” is pronounced .

PS We try to share not only our own experience on the service of providing virtual infrastructure 1cloud , but also to talk about related areas of knowledge in our blog on Habré. Do not forget to subscribe to updates, friends!