Skip to content

Latest commit

 

History

History
81 lines (51 loc) · 5.66 KB

effective-communication.md

File metadata and controls

81 lines (51 loc) · 5.66 KB

Effective communication

Always try to do asynchronous communication than synchronous meetings. Asynchronous communications allow one to collect and write down all their thoughts and helps the other person reading your message to understand the whole picture and provide you with a specific response. Tools such as Discourse forum, Asana tasks, and emails are examples of asynchronous communications. Synchronous meetings (video calls, Slack and in-person meetings) are useful for extremely urgent tasks / for more personalized feedback.

Asking questions

Posting a detailed question on an asynchronous channel (Discourse / Asana / StackOverflow / Google docs) is the best way to get a response.

How do I ask a good question?

We’d love to help you. To improve your chances of getting an answer, here are some tips:

Search, and research and keep track of what you find. Even if you don't find a useful answer elsewhere on the site, including links to related questions that haven't helped can help others in understanding how your question is different from the rest.

Write a title that summarizes the specific problem

The title is the first thing potential answerers will see, and if your title isn't interesting and descriptive, they won't read the rest. So make it count:

  • Avoid back-and-forth and ask specific questions and be as descriptive as possible. This improves your chance of receiving a specific and relevant answer. Consider what details can you include that will help someone identify and solve your problem? Include any error messages, background materials, log files (use texts instead of screenshots if possible), your system environment, anything you think is relevant that will make your question as specific and descriptive as possible. Assume the reader has no idea about the problem you are facing.

  • Spelling, grammar, and punctuation are important!

If you're having trouble summarizing the problem, write the title last - sometimes writing the rest of the question first can make it easier to describe the problem.

Examples:

  • Bad: MPM Math Confusion

  • Good: Why does using float instead of int give me different results when all of my inputs are integers?

  • Bad: LBM-DEM formulation doubt

  • Good: What is the mechanism behind the lubrication force in LBM?

  • Bad: Problems with plotting

  • Good: “module ‘pandas’ has no attribute 'tslib” error in using ggplot2 with pandas

Introduce the problem before you post any code

In the body of your question, start by expanding on the summary you put in the title. Explain how you encountered the problem you're trying to solve, and any difficulties that have prevented you from solving it yourself. The first paragraph in your question is the second thing most readers will see, so make it as engaging and informative as possible.

Help others reproduce the problem

Not all questions benefit from including code. But if your problem is with code you've written, you should include some. But don't just copy in your entire program! it likely includes a lot of irrelevant details that readers will need to ignore when trying to reproduce the problem. Here are some guidelines:

  • Include just enough code to allow others to reproduce the problem. For help with this, read How to create a Minimal, Complete, and Verifiable example.

  • DO NOT post images of code, data, error messages, etc. - copy or type the text into the question. Please reserve the use of images for diagrams or demonstrating rendering bugs, things that are impossible to describe accurately via text.

  • If you have a JSON file with 1000s of arguments, think if it is relevant to have all 1000 arguments. Keep your code snippet to 10 - 15 lines maximum.

Synchronous communications

Avoid synchronous communications whenever possible. There are specific use cases like discussing personal goals, receiving personalized feedback, long-term planning, and urgent response.

Never keep synchronous channels (Slack/Emails) active throughout your day. Check them at most 3 times a day, and use them sparingly. Dedicate a block of time for responding to communications and only respond during this dedicated time of the day.

Meetings

Meetings are useful for personalized feedbacks, and for long-term planning.

It’s easy to find your calendar full of meetings that might not help you achieve what’s most pressing. Here are some criteria you might use to decide whether a meeting is worth organizing or attending:

  1. Have clear goals been set for the meeting?
  2. Does the meeting have a defined agenda?
  3. Is the meeting being set for an appropriate amount of time?
  4. Is the meeting being set in a time that doesn’t affect your productivity?
  5. Have relevant documents been sent with the meeting invite, so you and your colleagues can come prepared?
  6. Can discussion or updates be managed asynchronously (e.g. via email, Slack, Trello, or Asana)?

Slack

  • Don’t send a Slack question, if you need a detailed response, use an asynchronous channel
  • Use Slack to keep in touch with your friends and colleagues
  • Always call or send a text message if it is urgent!

Emails

  • Don’t send an email if you can get a simple question answered elsewhere;
  • Make your subject line informative;
  • Try to write five sentences or less (makes it easier to read);
  • Use bullet points to write and reply to emails;
  • Put the most important stuff at the top; and
  • Use "CC" and "Reply All" sparingly

Giving a talk at a conference

Read A Long Guide to Giving a Short Academic Talk