Communication is often overlooked as one the most important skills a developer can have.

Being a developer is similar to being a player in a sports team. If two outfielders reach for the same fly ball and no one yells “Mine!”, since they assume they both know what the other is thinking, they’ll bump into each other and the ball will fall to the ground and make a very sad “bam” sound.

As a developer you are constantly collaborating with others: Developers, Product Managers, Designers, and others. In some cases, you may even work with Marketing or Salespeople. Being able to clearly and consistently communicate and align expectations is sure to make you an even better developer than you already are (I’m sure you’re the greatest).

A team with great communication is bound to succeed. It’s a fact. Over-communication is something a lot of people use but I don’t think there’s a need for it. You communicate, and if others get you, yay. If not, try again. If you have any doubts about being understood, you’re probably right to do so and should elaborate or repeat yourself.

Don’t Assume

If there’s one mantra to keep in mind, it would be “Don’t Assume”. What the actual hell? It means that the only way to make sure others know what you’re up to or what you think is to tell them. Don’t assume they know. Don’t assume it’s obvious. Don’t assume. Period.

Sure, in some cases, you’re going to assume and it’ll go great. You’re working with a team that’s been working together for ages, you’re all very familiar with each other and things seem to just roll. That happens, but it’s bound to fail at some point. That’s why making a habit out of not assuming is a great way to make sure that never happens. Words are free, use them.

To review a few examples of when and how communication can be better or worse, let’s go over some scenarios and how it would be best to proactively communicate in them. This post focuses on communicating in different platforms we often use as developers.

GitHub

When reviewing code, elaborate. Comments should have reasoning and explanations. Making a decisive “This is bad practice” comment without explaining why it is that way is sure to lead to frustration on the other side. Offering an alternative or “If I were to develop this, I would…” suggestions is a great way to get better results and have a better relationship with the person you’re reviewing.

Suppose a code review goes back and forth a couple of times. It probably means that something’s not working and this async comment and request review ritual is not cutting it. Hop on a call, get on a Slack chat or talk in person about the comments that are left. This makes more room for a discussion, which is probably necessary at this point and replaces the American Idol-feel code reviews sometimes have, where the reviewer sometimes Simon Cowells the person being reviewed.

When finishing up your review, add a comment at the end with your general impressions.

JIRA

Keep your board updated. Make a habit out of reviewing your board at the beginning of each day and at the end of it. That’s the best way of syncing everyone in your team on where you stand. When moving a ticket to a different status, comment and tag those who care about it. If the comments section starts looking like a chat, be the one to break it and move the conversation to Slack.

Slack

Create channels. Channels are great. You’re working on a feature, you’ve got questions, something’s not clear. Open a channel with everyone relevant and talk about it there. The channel is sure to be a great place to keep going and discussing anything else about that feature.

Add integrations. Make sure everyone knows when you deployed something, when it’s ready for testing, anything. If you see yourself writing the same message over and over again, there’s probably a slack integration for it.

If you’re getting tired of texting so much, go on a Huddle. It’s funny how putting that toggle at the bottom makes it a lot more legit to do a voice call. I don’t mind phone calls either.

Set an Example

Once you start communicating and posting updates, others will get into the same vibe and will do the same for you. If they don’t, no worries, now you can scold them for not doing it, since you’re so nice and you always do it. All it takes is one communication breakdown for it to become clear to everyone that “oh yeah, we need to communicate better”.

Although everything I wrote here is about talking or letting others know what you think, never forget communication is a two-way street. Listening and paying attention to what others are saying is just as important. Be proactive in both – let everyone know where your head’s at but ask them to tell you where theirs is.

At Wibbitz, we’re stronger together. Join our team of innovators today!