Edit

Communication

A big part of our day to day work is communicating effectively with others. The overall process of building a product requires harmony between people and a clear understanding of everyone's role.

Here are some reasons why effective communication is essential:

• Building great software is hard
• It avoids confusion
• It provides purpose
• It creates accountability
• It saves time and eventually money
• It builds trust

Often, engineers focus only on learning about new technologies and neglect improving their ability to communicate. Achieving the proper balance between technical knowledge and strong communication skills is the difference between good developers and great ones.

Communicating Issues To Teammates

Don't get stuck! Reaching a teammate is your top priority after doing your due diligence to seek a solution on your own.

There are several benefits to reaching out to your teammates, including:

• Other developers may have run into this issue before and have a solution
• A fresh pair of eyes may see your problem from a new light and offer an alternative solution you didn't think about
• Your teammates are kept informed of your status on your task, and this setback can be planned for accordingly
• Can boost a team's collaboration and teamwork proficiency
• When your teammates come together and solve an issue, there is an increase in the team's collective knowledge

Every developer runs into blockers, but great developers humble themselves and seek help from their colleagues to overcome challenging issues.

Communicating Bugs

As engineers, we occasionally will run into bugs while trying to develop solutions to our assigned tasks. These bugs should not be ignored but communicated to your team and project manager via agreed-upon communication tools, such as email, instant messaging, etc.

You should also begin the process of clearly documenting the bug by, at the very least, providing the following information:

• The expected behavior/result and what is happening
• All of the steps needed to reproduce it, including things like the OS and browser used
• The impact of the issue on your current development task
• Possible solutions with their relation between cost vs. benefit

This well-documented bug can then be added to the tracking tool your team/organization is using (e.g. Trello, Github, Jira, Google doc).

Communicating Task Delivery Delays

Let your manager know as soon as possible if you expect any delays in your deliverables. Do not wait until the due date to reveal the delay. Figure out:

• Why?
• What you're going to do to prevent that from happening in the future?
• Come up with a new due date.
• Seek out ways to reduce the impact of the delay.
• Can you get more staff involved to avoid the delay?
• Can you use different tools to avoid the delay?
• Can you add hardware to avoid the delay?
• Schedule a meeting with your project manager to present your ideas.

For example, if you are working with a team with weekly sprint meetings every Monday to assign the tasks you will be working on during the week, don't wait until Thursday or Friday to communicate to your team that you won't complete your task. I'm repeating myself but can't emphasize this enough, communicate with them as soon as you know you won't deliver the task on time. Then provide the best information you can about the cause of the delay, the expected impact, the probability it will occur, your thoughts about mitigating it, and your worries concerning it.

Communicating Changes

Be transparent about any changes related to completing specific tasks if they can affect aspects of the codebase and others' work—for example, an integration or some part of the product's architecture. Before changing components that could have a broad impact, make sure that you let others know about the changes, their potential impact, and why you need to make these changes. Others have the opportunity to provide feedback, alternative solutions, and ensure that it's the right time to make these changes.

There is a great deal of risk associated with making significant changes to an application. These changes to introduce bugs and cause unexpected areas of the application to break. Create Unit Tests to mitigate some of that risk.

Some examples of when I should communicate changes:

• When the scope of a task needs to be modified
• When the approach or methodology to complete a task is changing
• When I'm going to delay a task I'm working on
• When I am working on a part of the product that affects many components (Ex. If you change an API or some aspect of the codebase's architecture)

Communicating Updates

On projects and individual tasks, other team members must be aware of what you are working on. They may be other developers, testers, project managers, project owners, or anyone with a direct interest in the project's status.

When should I provide updates:

• When taking ownership or starting a task
• When I finish a task earlier than I expected
• For larger tasks, providing a daily update with an estimated "percentage completed"
• When I'm stuck on something I'm doing, and I see that there's a potential delay
• When I need to run a build or deployment to an environment
• When I complete a task, and my changes are ready for code review
• In a leadership/decision-making role. A previous decision needs to be changed. Such as an API your development team is relying on
• When your availability is changing, including:
  • Short term changes: a doctor appointment in the afternoon or taking a Friday off
  • Long term changes: a leave of absence or vacation
  • Scheduling changes: splitting time with a separate client

Asking Questions

One of the most important skills an engineer can have is the ability to ask the right questions. It shows that you have humility, care, and are genuinely interested in delivering a successful product to the client.

Asking Clarifying Questions

When there is a lack of clarity with requirements, it is essential not to make assumptions. If you are not sure that what you are building will 100% fulfill the task's requirements, don't be afraid to ask. Great developers build with the end goal in mind and ask questions about requirements when it is not clear.

For example, your project/product manager comes up with a new feature that they want to add in the next sprint. In the requirements, they specify third-party integrations and tools you should use. Be sure to ask questions on why they made those choices. If you have a better solution, tell them. Great engineers ask questions and constructively provide their feedback.

You could encounter a situation where you receive design files from a designer but have an alternative solution in mind for building a particular screen that takes into consideration certain factors the designer wasn't aware of, such as performance or ease of use. Do not be afraid to bring up your thoughts, questions, or concerns to designers or project managers when it comes to the UI/UX of a feature or the project as a whole.

Ask questions when:

• You are not 100% sure about the task or a feature you will build
• If you disagree with the requirements and have better suggestions
• When requirements between two different tasks are contradictory
• When the timeline or deadline doesn't seem achievable
• If you aren't sure you have sufficient resources (people, tools, equipment) to complete a task

Communication Tools

There are quite a few different tools that can be used to communicate with other team members and clients. Knowing which communication tool will work best in different situations is as important as knowing which IDE works best with different programming languages. Each tool comes with its own advantages and disadvantages, which can help you make an informed decision on which tool to use.

Email

The old standard! Email revolutionized the way and speed people communicate at work. Here are some best practices and recommendations on when and how to communicate via email.

When to use:

• When you don't need an immediate answer. Email is asynchronous, so the expectation is that you will get a response soon but not immediately.
• When you are asking a more complicated question and need a more detailed answer.
• When you wish to provide some detailed information.
• When you want to begin a dialog with multiple people.
• When communicating with a client outside of your organization who may not have access to the same communication tools.
• When seeking an official decision that could be problematic later on.

What not to do:

• CC people that aren't going to provide any value to the conversation.
• Email signatures with big, goofy images in them (employer required signatures being the exception).
• Don't send a follow-up too quickly. Take the time to provide a clear, concise, and accurate response.

Advantages:

• Easily searchable
• Archive of project information (assuming your email account remains active and deleted emails are archived and not purged)
• Universal - Everyone has an email!

Disadvantages:

• Slow response time
• Emails can be lost. People may get hundreds in a day and may miss the email you sent.
  • If you need to ensure your email gets noticed, consider requiring a return receipt, so you will be notified when someone reads your email.
• Spam - Your email can sometimes get flagged incorrectly, which is incredibly frustrating.

Chat/Instant Message Tools

Instant Messaging tools have been around for a while. ICQ and AOL Instant Messenger paved the way for many services used throughout the industry today. Several newer tools have been designed specifically for business, such as Slack and Microsoft Teams, and others that support instant messaging, such as Skype, WeChat, Google Hangouts, etc.

When to use:

• When you need a quick response
• When you want to post a question to a group of people (depending on service)
• When you want to begin a conversation among a group of people.

What not to do:

• Don't start a conversation with "hello" and then say nothing until you get a response.
• Don't send
  • A bunch
  • Of short
  • Messages.

Advantages:

• Quick
• Archivable and searchable (depending on the service)
• Informal
• Great for team communication (depending on the service).
• Some support connectivity with external services (like Github, Jira, Trello, etc.).
• Many support voice and screen sharing functionality.

Disadvantages:

• Potentially distracting
• Depending on the service, a subscription may be required to access all features.

Audio/Video Conferencing

A widespread way for people to carry out meetings, primarily when participants are spread across many locations. Video conferencing services have been around for quite a while, and using them has become pretty common in many organizations.

When to use:

• Great for remote team meetings and customer meetings.
• Anytime you need to gather people together
• When decisions need to be made, and issues need to be discussed.
• When seeking multiple opinions on how to resolve an issue.

Advantages:

• Many services support both audio and video conferencing.
• Remote team members can join and contribute.
• Many support screen sharing.
• Users typically can connect through the phone.
• People can be away from their computers and still join.
• People are very familiar with meeting this way.

Disadvantages:

• Requires a pretty reliable internet connection for video.
• Prone to disruptions when members connect from home (pets, children, traffic, construction, etc.).
• Shy individuals may not speak up during the call.

Meeting

Meetings can be a great way to connect with your team members, but they must also have a purpose that makes the time spent worthwhile.

Basic rules that you should follow:

• When calling a meeting, have an agenda and stick to it
• When leading a meeting, spend time beforehand preparing what you'll be saying or presenting
• Be on time
• Be presentable
• While in a meeting, wait until someone finishes speaking before talking
• Ask questions if you have them.
• Pay attention to what others are saying
• Make sure everything is working, audio, microphone, and your internet
• Be respectful

Sprint Planning

In Agile, Sprint Planning meetings provide structure, set expectations, and define the backlog for upcoming sprints. Engineering teams utilize sprint planning to organize better and ensure the success of the sprint. This meeting occurs once per sprint and is used to address action items, roadblocks, and questions for the upcoming sprints and seek resolution to blockers from the current or past sprints.

Stand-up

In an Agile approach, you will have to participate in daily Stand-up meetings. Stand-ups should be short (no more than 15 minutes) and highly focused meetings where developers provide their current task status. The idea behind the "Stand Up" is that no one wants to stand more than they need, so the quicker everyone gets through their list, the quicker everyone can sit back down.

Questions to answer during the stand-up

• What have you worked on since the last Stand-Up?
• What are you currently working on?
• What will you be working on next (before the next Stand-Up)?
• Is there anything blocking you from completing your task (Optional)
• Request any additional support for your current task (Optional)
  • Request time with another attendee after the stand-up completes or at a specified time during the day. Do not hijack the Stand-Up.