Effective communication techniques for (remote) front-end developers

At Functionite, a front-end dev shop that specializes in JavaScript hybrid applications, our developers are free to choose a place they want to work from. Although we have our own office in Warsaw, Poland, a part of our team is distributed around the country, while locals love being flexible. In this environment, having effective communication skills becomes necessary to get things done in a timely fashion.

Communication

Recently, we have been honored to process almost 150 job applications for Junior Front-end Developer position. After selecting the final 10, we set up a round of meetings to see what it’d be like to work together. Unfortunately, we’ve met quite a lot of extremely talented developers who lacked an ability to express their thoughts correctly. They had difficulty to formulate exact questions or to tell us more about problems they were tackling.

Before each technical interview we always try to provide a comfortable atmosphere for the candidates. For instance, we tell them that it’s fine to seek for a solution in Google or ask us for help (that’s what their first months at the company would look like, so why not?) as this is normal in programming world. We openly admit it before we can start an interview.

Sadly, after having a series of interviews we find it a major problem in the industry i.e. a significant group of brilliant developers out there are unable to describe their problems with the code in an understandable manner.

However, working in a remote team means you need to be precise. It begins with the minor things. For example, if you’re a developer who needs to leave a virtual desk. it’s always better to notice your coworkers about how long it would take. At least 1h sounds a way better than for some time. It means your fellows can plan ahead and spend that hour productively. The state of unsureness is always the worst and paralyzes any further actions.

Silence

Many developers like silence more than anything, though. While it’s absolutely fine to let them work alone to focus on a problem that requires a special attention, it’s doesn’t necessarily help manage projects to be delivered on time.

Programmers can be classified in a few groups based on how they tackle problems. For instance, there are developers who get stacked and troubled with a task for hours without communicating it to the team. Although sooner or later a talented programmer you certainly are will find an answer, in a professional environment you can’t afford such trade-off. That kind of ego-driven-development destroys trust among team members. Most importantly though, it costs companies a lot of money (imagine what could be accomplished during 5 days spent on solving an algorithm issue in a solo mode, if you’d asked early enough…). If there is a way to deliver code on time or even faster — we must use any tool we have to accomplish that. Asking for advice is often the smartest choice.

Of course not every team’s setup is ready for incorporating such behaviors. If the smell of contention wafts in your offices, people may think they are part of a negative competition, where it’s not natural to admit their weakness. It’s important to establish the clear rules about that in the first place.

We need to realize that effective communication is as crucial as programming is for growing as a professional front-end developer. Especially for those of us, who work remotely.

Practice is the key

We may be born good communicators, however being one is a thing you can learn. You need to observe how people react and how they respond to your questions. It will definitely take you some time to realize which moments are not ideal to disrupt a colleague speaking to the group at a Hangout meeting or, on the contrary, when you’re welcome to be proactive (for sure having a technical problem counts in here). It’s not a binary skill and requires a lot of work with other people to develop practical communication strategies. It’s also important to receive proper feedback — you can rarely improve without an objective manager that can give you advice.

Fortunately, some of the communication rules are universal and repetitive. Given that, let’s take a look on the examples of good and bad communication patterns at work.

Presence or absence

As we wrote above, it’s vital to give predictions as precise as possible. If we’re taking a break for 50 minutes, let’s inform others about our 50-min absence. When we are at desk, let’s indicate that in our status on Slack or any other communicator you use for a group chat. Some people (actually, not a few) may not dare to trouble you, if they see you inactive. However, if we’re away from the keyboard, it’s unlikely to set a ‘do not disturb’ mode —let’s choose a status description explaining what we’re doing and why we’re busy. Then turn the ‘DnD’ status on.

Same goes for appointments we make in advance. We should inform our managers about day-offs as soon as possible (a week’s notice is always better than a day’s). It shows respect our coworkers as well as allows them find a temporary replacement for a project we’re in.

Another situation when effective communication matters is working in pairs. Every time we promise a meeting to someone else, we should reserve a safe time slot when we can fully focus on the job. It means feeding a cat in advance and not picking up the calls in the meanwhile. If your time is limited, it’s polite to inform your colleague about that.

Describing your issues

Another major case when communication matters is explaining the coding issues to other developers. At Functionite, our golden rule is to set a proper context first. For example, we find it unfortunate to blame CustomMaps being inefficient in storing data when we start presenting a problem. It’s very likely a developer we speak with is not familiar with the app or the exact place you refer to. It’s always better to work on a wider picture like hey, look, if you click here on that button, you wait a lot of time. I suspect our poor CustomMap implementation. It starts off with that event handler, let me show you. This way, we give them a better context that opens sort of a black box in their minds and help guide their thoughts to a proper place in the code.

Giving a meaningful context may be a trap though. Some developers tend to over describe the code they are working on. For example, “I used a special event handling system so I’m adding a click event which, when fired, in turn finds a target node in the list. It’s a valid target only when it happens to be a link” is way to long as we could replace it easily with “I added click events to any link in that list using event delegation”.

Why the former is that bad? It introduces a few levels of abstraction that can provoke extra questions from a reader:

• special event handling system — what makes it so special? Is it the first time we have used it? Does it differ from the native implementation like addEventListener?
• target node– what is a target node? ev.target or ev.currentTarget or maybe something else? How it finds that node — recursively, using querySelector or other API?
• valid target–what valid stands for? How you determine it’s valid?

As we can see, using a fussy language may lead into unnecessary discussions. If we’re not good in precisely describing our code, let’s try to refer to the concepts commonly known as design patterns.

Commits

Ability to express your actions clearly is also useful in writing commit messages. It has probably been written in many books on good programming practices that an extensive and profound commit message is the boldest evidence of good communication skills. Every time we’re about to commit some code, let’s make a pause and relax our brain, since we will need to thoughtfully inform other users about our work.

For instance, when we changed CSS code which impacts the whole layout, “changes CSS layout” is rather a poor commit message, if left alone. It’s worth adding more description to it: “It uses flexbox instead of floats as we dropped support for IE8 and flexbox will work for all of our customers now. Flexbox makes us capable of using more sophisticated cross-browser layouts with ease.”, which is much more informative. Such text contains three major parts that every commit description should mention: what was the problem, what has been changed and why the change was necessary. It will tell a reviewer more and it’s going to be easier to scan through the commit history. Well written messages and descriptions should tell you a story about how the application evolved over time. You can read on writing good commit messages here and there.

By the way — if you’re not satisfied with the commit history before making a Pull Request, you can always rebase your branch and rewrite some commit messages (or even merge them together). It’s always better to have a few meaningful commit messages than a hive of useless.

Code reviews

The purpose of code reviews mainly is to share the knowledge about new code with your reviewer, while they can give a feedback with suggestions about how to improve it. To make reviewer’s life easier, as we said, we can clean up the commit history. But it’s not enough. Certainly, a reviewer will have a lot of questions and they (usually) do not come out from the one’s obsession about blaming someone. As a reviewer you want to do your job right. This, they need to have as much information as possible. That’s why they ask questions. It’s not about offending other people or hurting their feelings. The purpose of code reviews is primarily to learn from each other. There is no room for sarcasm or letting your reviewer know you’re not interested in getting feedback. In fact, everyone should be interested.

One of the worst review scenarios may be:

• Why have you used it?
• I have been using it for years. It just works.

It actually tells nothing and leaves a status quo. No one learns from each other while the code gets changed based on personal preferences.

In the best-case scenario a reviewer should try to give a context of their questions. Almost always we can find something that would make a dialog more fruitful. In front-end programming, it may be our experiences with other techniques —it makes sense to write about them:

Why have you used it? Isn’t it because flexbox doesn’t work on IE9? There is a nice polyfill that actually would allow us to use flexbox everywhere.

Now, knowing our motivation, author can write a concise answer like:

Right, it’s because flexbox is out of the game in IE9. I knew that script, however I tested it carefully and it doesn’t perform well in Maxthon. The majority of our users are still on it.

It’s dramatically different than the first answer, giving the reviewer more insight into why we actually have done what we have done.

Final credits

Most people do not listen with the intent to understand; they listen with the intent to reply.— Stephen R. Covey

We presented only a few useful advices as a good start. There is much more to be said on the topic and we are certain you will find many comprehensive resources. Communication is hard and has roots in psychology, society you live in, culture and even your childhood (as habits get developed early in your life). It requires a lot of practice, though it doesn’t take much to start improving it right away. Ask your colleagues, if they experience same issues and organize a seminar about communication rules in your company. You may suddenly find that more developers in your team struggle with ineffective communication strategies. Being honest about that is the first step to get off the dime and make your workplace a better place.