"Letter to the studio": 5 rules of communication remote developers from CSSSR
A Letter to the Studio is a guest column that will occasionally tell the audience of Megamind about the problems and ways of solving them that various companies and experts face in their work.
The following “letter” came to us from the CSSSR company, which shared with our readers the “5th rules of communication for remote developers”. CSSSR is a small company engaged in the front of web applications and complex sites, founded April 12, 2012 (Cosmonautics Day). Therefore, the guys working remotely in the CSSSR (the company does not have an office), according to their own statement, are “as precise as the astronauts”. The distributed structure of the organization does not prevent it from creating high-level products, and common development and healthy perfectionism are the main driving forces for development.
From the introduction - to the content. A word to Felix Exter, the leading developer of the company who prepared the rules for communicating with remote employees. It is useful not only to remote employees.
Nothing like? How many times have you had such a dialogue? Very effective, isn't it? So, son, if you read it and recognize yourself, then this post is for you. From now on, save it to your bookmarks or to your favorite service. Let insist and then sometime be sure to read. Everything is as usual.
')
The entire CSSSR team works completely remotely, and over time we realized that in order to effectively communicate online, we need rules. Just imagine the situation in the office: you approach an employee who is in a stream of consciousness and is concentrating on something. Greet and ask: "Are you there?" Not busy?". Funny, isn't it?
We decided to create basic rules for effective remote communication and work.
Do not write "Hello!" And do not expect mutual greeting. Believe me, when you write to a colleague in a personal, you are already glad to see and hear. Somehow disrespectful, you say? But for remote work, this is normal: just warn colleagues that it’s better to get down to business right away in the chat.
"You're here?". Yes, he is there waiting for your question. In the meantime, you are waiting for his answer. And you are playing a game of "who will wait out for whom."
"Not busy?". Busy! He always has business, time is precious to him. And you?
"Do not distract?" Turned to the man - you already distracted him. Deal with it. Plus, you are not the only one - and besides you at the same time other guys can write to him. Remember this.
Is it really important for you to get answers that you already know to all these sample questions, or do you still want to solve your problem?
Dialogue must have value. Preludes are unnecessary, because for the essence of the conversation they are not important. If a conversation needs to be copied and shown to someone, then there will be a bunch of garbage in it that has to be filtered.
2. Let's talk
No need to wait and act exactly by the minute. Initiate the discussion as soon as you have a reason to talk. From the fact that on yours on the clock in minutes there will be zeros, the question will not be solved faster. If all participants in the conversation can right now, why not start right away? If they can't, they will say so.
This, of course, is a terrible nonsense, but it occurs surprisingly often. Probably, it remains after office work with the need to book a corporate negotiation in advance.
"I have again like last time, some nightmare ...".
"Again, nothing works and errors appear ...".
Can you give me a phone number to register for telepathy courses?
Your interlocutor should not guess what problems you have. Consistently tell about them yourself! Words must have meaning. Stories about your personal attitude to the problem save for your psychologist.
Try to keep within one message. If there are many offers, transfer them to a new line. Long lines are hard to read. You should be familiar with this from the code editor.
Learn to identify your problem. Maximum specifics: where it appears, how to reproduce it - look in the console, watch the terminal, don't forget about third-party modules, etc. If the problem is complicated, break into components.
... and try to solve the problem yourself!
Seriously. No kidding. Debug your code (and in general - in any profession - to find and correct its own jambs) everyone should be able to, plenty of ways and tools for this.
If the one who helps the newcomer will allow it to do this all the time, then the newcomer will not go far. Remote work only reveals the problem: endless dialogues are worse than self-solution. Yes, you need to ask, but do not abuse it.
It would seem without comments, but most newbies do not use search and immediately run to the PM. Bring this habit to yourself.
... and use the search correctly!
A well-written question contains the key to the solution.
... so use the Duckling Method !
The chance of success increases several times when you ask a question to the community. We in Slack have a special channel for reviews and questions arising during development, in which the collective mind is ready to help you. This is very convenient, and much better than pestering a busy colleague in PM.
The rules for addressing the community are the same as for personal communication (see paragraph 1). If the question concerns something specific, you can contact a narrow circle of specialists through the groups in Slack .
Solving a problem does not mean that you can close the task. It is important to test what you put on. Take test cases. If you can write tests - well, use them, run them more often and keep them up to date. Do not let the bugs go past you to your colleagues and users. Do not rely on the tester and timlid. Best of all your offspring test only yourself.
The ability to communicate is constructively very important, and it needs to be worked out. Learn to save time of colleagues and do not turn personal correspondence into a sheet for several dozen pages.
Total:
Following the tips from this post, you will become a master of remote communication.
The following “letter” came to us from the CSSSR company, which shared with our readers the “5th rules of communication for remote developers”. CSSSR is a small company engaged in the front of web applications and complex sites, founded April 12, 2012 (Cosmonautics Day). Therefore, the guys working remotely in the CSSSR (the company does not have an office), according to their own statement, are “as precise as the astronauts”. The distributed structure of the organization does not prevent it from creating high-level products, and common development and healthy perfectionism are the main driving forces for development.
From the introduction - to the content. A word to Felix Exter, the leading developer of the company who prepared the rules for communicating with remote employees. It is useful not only to remote employees.
xxx [16:00:00]: hi!
xxx [16:01:01]: are you there?
yyy [16:01:17]: hi
xxx [16:04:56]: do not distract?
yyy [16:05:13]: no
xxx [16:07:28]: excellent
xxx [16:08:01]: I need your help.
xxx [16:09:29]: something doesn't work for me here ...
xxx [16:10:09]: sec
xxx [16:13:12]: litter, departed
xxx [16:14:25]: are you there?
yyy [16:14:30]: yes
Nothing like? How many times have you had such a dialogue? Very effective, isn't it? So, son, if you read it and recognize yourself, then this post is for you. From now on, save it to your bookmarks or to your favorite service. Let insist and then sometime be sure to read. Everything is as usual.
')
The entire CSSSR team works completely remotely, and over time we realized that in order to effectively communicate online, we need rules. Just imagine the situation in the office: you approach an employee who is in a stream of consciousness and is concentrating on something. Greet and ask: "Are you there?" Not busy?". Funny, isn't it?
We decided to create basic rules for effective remote communication and work.
1. Do not clutter the air on duty phrases
Do not write "Hello!" And do not expect mutual greeting. Believe me, when you write to a colleague in a personal, you are already glad to see and hear. Somehow disrespectful, you say? But for remote work, this is normal: just warn colleagues that it’s better to get down to business right away in the chat.
"You're here?". Yes, he is there waiting for your question. In the meantime, you are waiting for his answer. And you are playing a game of "who will wait out for whom."
"Not busy?". Busy! He always has business, time is precious to him. And you?
"Do not distract?" Turned to the man - you already distracted him. Deal with it. Plus, you are not the only one - and besides you at the same time other guys can write to him. Remember this.
Is it really important for you to get answers that you already know to all these sample questions, or do you still want to solve your problem?
Dialogue must have value. Preludes are unnecessary, because for the essence of the conversation they are not important. If a conversation needs to be copied and shown to someone, then there will be a bunch of garbage in it that has to be filtered.
2. Let's talk at three o'clock
No need to wait and act exactly by the minute. Initiate the discussion as soon as you have a reason to talk. From the fact that on yours on the clock in minutes there will be zeros, the question will not be solved faster. If all participants in the conversation can right now, why not start right away? If they can't, they will say so.
This, of course, is a terrible nonsense, but it occurs surprisingly often. Probably, it remains after office work with the need to book a corporate negotiation in advance.
3. First formulate, then write
"I have again like last time, some nightmare ...".
"Again, nothing works and errors appear ...".
Can you give me a phone number to register for telepathy courses?
Your interlocutor should not guess what problems you have. Consistently tell about them yourself! Words must have meaning. Stories about your personal attitude to the problem save for your psychologist.
Try to keep within one message. If there are many offers, transfer them to a new line. Long lines are hard to read. You should be familiar with this from the code editor.
Learn to identify your problem. Maximum specifics: where it appears, how to reproduce it - look in the console, watch the terminal, don't forget about third-party modules, etc. If the problem is complicated, break into components.
... and try to solve the problem yourself!
Seriously. No kidding. Debug your code (and in general - in any profession - to find and correct its own jambs) everyone should be able to, plenty of ways and tools for this.
If the one who helps the newcomer will allow it to do this all the time, then the newcomer will not go far. Remote work only reveals the problem: endless dialogues are worse than self-solution. Yes, you need to ask, but do not abuse it.
4. Use the search
It would seem without comments, but most newbies do not use search and immediately run to the PM. Bring this habit to yourself.
... and use the search correctly!
xxx: searched everything, found nothing ...Most often, doing the same thing for the juna, you find the answer in the first paragraph of the search results. A newbie craves long questions for which the search engine will only give more junk results. And that means:
- Suzu search terms: leave only keywords. An exception may be errors from, for example, the console, containing messages with constants and error codes.
- If the problem is in any library, try to immediately search your library's repository.
5. Tell your duck about your misfortune.
A well-written question contains the key to the solution.
... so use the Duckling Method !
xxx: how to do this?The method is as follows: put a toy duck on the table, to whom you will ask questions as a living person. The correct formulation of the question contains at least half of the answer, but also gives an impetus to the thoughts, directing them in the right direction. It will definitely work. By the way, do not forget to inform immediately, as soon as you solve the problem, if you have already managed to write your own question. You understand why.
...
xxx: solved the problem)
6. Desperate? Ask everyone at once
The chance of success increases several times when you ask a question to the community. We in Slack have a special channel for reviews and questions arising during development, in which the collective mind is ready to help you. This is very convenient, and much better than pestering a busy colleague in PM.
The rules for addressing the community are the same as for personal communication (see paragraph 1). If the question concerns something specific, you can contact a narrow circle of specialists through the groups in Slack .
Bonus: test
Solving a problem does not mean that you can close the task. It is important to test what you put on. Take test cases. If you can write tests - well, use them, run them more often and keep them up to date. Do not let the bugs go past you to your colleagues and users. Do not rely on the tester and timlid. Best of all your offspring test only yourself.
Conclusion
The ability to communicate is constructively very important, and it needs to be worked out. Learn to save time of colleagues and do not turn personal correspondence into a sheet for several dozen pages.
Total:
- First google;
- Turning to the PM, immediately avoid the preludes;
- Formulate and ask substantive questions;
- Describe the formulation and context of the task (how it should be and how it is now);
- List what you have already tried to do;
- Describe the result (errors, unpredictable behavior, etc.);
- It is advisable to attach a snippet and a screenshot;
- If there is, where to test, show where and how to play;
- Contact the community.
Following the tips from this post, you will become a master of remote communication.
If you have an expertise that you want to share on the "Megamind" - write us a "letter to the studio" at editor@megamozg.ru
Source: https://habr.com/ru/post/298928/
All Articles