“A letter to the studio”: 5 rules for communicating remote developers from CSSSR

    “Letter to the studio” is a guest column that will from time to time tell the audience of Megamind about the problems and methods of solving them that various companies and specialists encounter in their work.

    The following "letter" came to us from CSSSR , which shared with our readers the "5th rules of communication of remote developers." CSSSR is a small company dedicated to front-end web applications and complex sites, founded April 12, 2012 (Cosmonautics Day). Therefore, the guys working remotely in CSSSR (the company does not have an office), according to their own statement, "are as clear as the astronauts." The distributed structure of the organization does not prevent it from creating high-level products, and common sense and healthy perfectionism are the main drivers of 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. Useful not only to remote employees.

    xxx [16:00:00]: hello!
    xxx [16:01:01]: are you here?
    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]: you here?
    yyy [16:14:30]: yes

    Doesn’t resemble anything? How many times have you had such a dialogue? Very effective, right? So, son, if you read it and recognize yourself, then this post is for you. From now on, save it to your bookmarks or your favorite service. Let it brew and then someday be sure to read it. Everything is as usual.

    The whole CSSSR team works completely remotely, and over time, we realized: to communicate effectively 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 typing something. You greet and ask: “Are you here? Not busy?". Funny, isn't it?

    We decided to draw up basic rules for effective remote communication and work.

    1. Do not litter the air with catch phrases


    Do not write “Hello!” And do not wait for 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 chatting is better to get down to business immediately.
    "You're here?". Yes, he is there and waiting for your question. Meanwhile, you are waiting for his answer. And you play the game "who will wait for someone."
    "Not busy?". Busy! He always has business, time is precious to him. And you?
    “Not distracting?” Turned to a man - you already distracted him. Deal with it. Plus, you're not the only one - and besides you, other guys can write to him at the same time. Remember this.
    Is it really important for you to get the answers that you already know about all these template questions, or do you still want to solve your problem?
    Dialogue must have value. Preludes are superfluous, because for the essence of the conversation they are not important. If someone needs to copy-paste the conversation and show it, then there will be a bunch of garbage in it that has to be filtered.

    2. Let's chat at three o’clock


    No need to wait and act exactly in minutes. Initiate the discussion as soon as the occasion for conversation appeared. From the fact that there will be zeros on your watch in minutes, the question will not be resolved faster. If all the conversation participants can right now, why not start right away? If they can’t, they will talk about it.

    This, of course, is terrible stupidity, but it is surprisingly common. Probably, it remains after office work with the need to book a corporate meeting room in advance.

    3. First formulate, then write


    "I have it again as last time, some kind of nightmare ...".
    "Again, nothing works and errors appear ...".


    Can you tell me the phone number for registering 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 strings are hard to read. It should be familiar to you from the code editor.

    Learn to identify your problem. Maximum specifics: in what place does it appear, how to reproduce it - look in the console, watch the terminal, do not forget about third-party modules, etc. If the problem is complex, break it down.
    ... and try to solve the problem yourself!
    Seriously. No kidding. Debug your code (and in general - in any profession - to find and fix their own jambs) should be able to everyone, there are plenty of ways and tools for this.
    If the one who helps the beginner will allow him to do this all the time, then the beginner will not go far. Remote work only reveals the problem: endless dialogs are worse than an independent solution. Yes, you need to ask, but do not abuse it.

    4. Use the search


    It would seem without comment, but most beginners do not use search and immediately run in PM. Take this habit for yourself.
    ... and use the search correctly!
    xxx: searched everything, found nothing ...
    Most often, after doing the same for the June, you will find the answer in the first paragraph of the search results. A beginner craves long questions that the search engine will give only more junk results. Which means:
    • Narrow your search: leave only keywords. Errors from, for example, the console containing messages with constants and error codes can be an exception.
    • If the problem is in any library, try to search immediately in your repository of this library.

    5. Tell the duckling about your trouble


    A well-composed question contains the key to a solution.
    ... so use the Duckling Method !
    xxx: how to do this?
    ...
    xxx: solved the problem)
    The method is this: put on the table a toy duckling to whom you will ask questions as a living person. The correct wording of the question contains at least half the answer, and also gives impetus to thoughts, directing them in the right direction. It will definitely work. By the way, do not forget to inform as soon as you have solved the problem, if you have already managed to write your question. You understand why.

    6. Desperate? Ask everyone at once


    The chance of success increases several times when you ask a question to the community. We at 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 annoying a busy colleague in PM.
    The rules for contacting the community are the same as for personal communication (see 1 point). If the question is about something specific, you can contact a narrow circle of specialists through groups in Slack .

    Bonus: test


    Solving the problem does not mean that you can close the task. It is important to test what you have done. Carry out test cases. If you know how to write tests - great, use them, run more often and keep up to date. Do not let bugs pass you by your colleagues and users. Do not rely on the tester and team lead. Best of all, only you yourself will test your brainchild.

    Conclusion


    The ability to communicate constructively is very important, and it needs to be developed. Learn to economically spend the time of colleagues and do not turn personal correspondence into a sheet of several tens of pages.

    Total:
    • First google;
    • Turning in PM, immediately avoid foreplay;
    • Formulate and ask substantive questions;
    • Describe the wording and context of the task (as it should be and as it is now);
    • List what you have already tried;
    • Describe the result (errors, unpredictable behavior, etc.);
    • Attach a snippet and a screenshot;
    • If there is, where to test, show where and how to reproduce;
    • Contact the community.

    Following the advice from this post, you will become a master of remote communication.
    If you have an expertise that you want to share at Megamind, write us a “letter to the studio” at editor@megamozg.ru

    Also popular now: