DEV Community: James Munro

Tips for effective remote communication

James Munro — Mon, 22 Mar 2021 16:55:49 +0000

Being a remote worker, or working with remote teams forces us to be more intentional about when and how we communicate. Over the last few years I’ve either been working as a fully remote employee or with remote teams. This has been a humbling experience and I’ve learned a lot about what does and doesn’t work when it comes to communication.

In this article, we’ll take a look at some simple guidelines and practical advice which can be useful for remote teams, or teams who have remote workers, to enable both to communicate more effectively. By the end of the article, I hope that you will be encouraged to consider writing a shared team document that describes your team’s communication principles — or at least to be curious about how your team currently communicates and whether there are improvements you could make. Let’s dive in!

One of the biggest paradigm shifts in remote work is that natural opportunities for synchronous communication between your peers becomes harder, and asynchronous communication becomes the norm. In your remote team setup, no doubt you are using tools such as Slack. At DataCamp, we use Slack, and whilst it’s become an essential tool, it also requires us to adapt the way we think about communicating in order to make it work for us.

⏲️ Don’t expect immediate responses

When messaging people via such tools, you should not expect to receive immediate replies to your messages as you would with in-person communication. Unfortunately, typing a quick message to a colleague is not the same as walking over to their desk and having a quick chat in person.

There are numerous reasons your colleagues may not respond immediately. At DataCamp, we encourage engineers to block out sections of their calendar for Deep Work in order to foster focus, and it would be unreasonable to expect people to be constantly monitoring Slack during that time. Similarly, someone might be away from their keyboard, in a meeting, or simply in another time zone.

As the recipient of a message, it is courteous to acknowledge that you have seen or handled a request with a response or an emoji reaction such as 👍, especially as the original sender may be in a different time zone and might not revisit the message until the following working day.

If you find yourself needing immediate responses from people, most likely your request is urgent (is it really?), and you might not have a suitable process for escalation in place. In these situations, typing a message in Slack may not be the best approach.

🗣️ Be highly effective with synchronous communication

For those urgent situations (are you still sure it’s urgent?), or for situations where a discussion with real-time interactions might be more effective, then synchronous communication is required.

Within our teams at DataCamp, we typically have at least a 30 minute slot each day where high context topics can be discussed in a video call. We encourage anyone in the team to bring topics for discussion during this time, especially those which are more urgent and cannot be resolved in an asynchronous manner.

To help facilitate this, some teams have a Slack channel which serves as the agenda for the meeting. Sometimes during an asynchronous conversation it may become clear that it would be more effective to bring the topic to a meeting for further discussion — we use a predetermined emoji reaction that shares the topic into our meeting channel using the Reacji Channeler extension — and the topic can then be picked up at the next daily meeting.

Sometimes, these topics end up being too large for the regular meeting. In these situations, it can be more effective to spin the discussion out into a separate meeting of its own.

We also have scheduled meetings on specific topics where interaction is much more dynamic, such as a collaborative brainstorming session. In these circumstances, the session should be booked with both sufficient notice and a clearly defined agenda with desired outcomes, plus any upfront preparation required by the participants.

On very rare occasions, some things are simply too urgent to wait and we encourage people to break out into video calls on-demand — however, this should be the exception and not the norm. Ideally, there will be a shared understanding within your teams on how to handle such situations — for example, having a handy /zoom shortcut to trigger a zoom call within a message thread.

The key take-away is that synchronous discussion is highly valuable and that team members should strive to be intentional and highly efficient with the time — you might just find that you need less meetings than you expect.

🎬 Default to action

Another useful technique in remote teams is to default to action, or exhibit a bias to action. For example, if as an engineer, you feel unable to proceed due to a lack of clarity on a functional requirement, use your knowledge of the product strategy to make a best effort attempt to resolve the issue until further input can be received using one of the other methods.

Use your discretion: if there is significant engineering or other cost at stake, err on the side of caution. This may occasionally mean a wrong -call is made, however this may be indicative of an underlying team alignment issue more so than the individual’s judgement.

While this approach does require a certain degree of trust between team members, it also encourages strong alignment on direction and is a tradeoff to reduce potential dependencies and bottlenecks. Ultimately, the vast majority of decisions are reversible and it’s unlikely to cause significant setbacks. However, you should always retrospect on situations where this occurs to distinguish whether or not the right call was made.

📝 Leave a paper trail

As so much of our communication has shifted over to asynchronous communication with Slack, it can be hard to keep track of all of the decisions that have been made. To counter this, it is essential to keep a paper trail of decisions and outcomes.

As a remote team member, it can be frustrating to stumble upon Slack threads and discussion where something important was discussed, and yet the resolution is missing. However, there are simple techniques to counter this.

One simple trick is to make sure to revisit threads and make sure that when a decision or outcome is reached, that it is stated in the thread. On top of this, you can mark the thread as resolved by adding a predetermined reaction emoji such as ✅. This way, anybody reading over a discussion will clearly be able to see that the thread is resolved, and more importantly, the action that was taken.

You can also combine this approach with the Reacji Channeler extension to keep a team decision log: mark decisions and outcomes with a specific emoji that will be automatically shared into a decision log channel to create a centralized location for all decisions.

🚨 Have a plan for handling emergencies

The best way to handle an emergency is not to have one in the first place! However, sometimes Murphy’s law applies. Be prepared for these situations, and have a clear protocol for handling emergencies.

For instance, you might use a tool such as PagerDuty to ensure that somebody is always on call for a given service in your stack. By using multiple levels of support, you can ensure that emergencies and incidents can be escalated and that somebody is always on hand to help resolve the problem — don’t rely on trying to nudge people on Slack.

All of these guidelines require diligence and a shared understanding between team members, which leads on nicely to the next point — writing down your communication principles.

🧠 Foster a shared understanding

At this point, all of these guidelines are becoming difficult to remember. Additionally, none of this is much use if only one team member is following the advice. The best way you can encourage efficient communication is to build a shared understanding of what works for you and your team.

A simple way of achieving this is to agree on and write down your communication principles in a team-owned shared document. In fact, this article was inspired by and paraphrases sections of the communication principles documentation of one of the engineering teams at DataCamp.

Ideally, everyone in the team needs to understand this document as it will serve as their guideline on how to work together effectively. Not only is it a useful resource for existing team members, it serves as a great onboarding resource for new team members to quickly get them up to speed.

Now that you have your shared communication principles, everything is perfect and set in stone, right? Wrong!

➰ Learn and adapt

If there’s one key message to take away from this article, it’s that you should introspect and be curious as a team about how to work effectively remotely. No doubt, most teams will have experienced some teething troubles and you should not accept the status quo as being the way things will always be.

In your team, you most likely already have a process for continuous improvement (such as an Agile methodology). A simple way to learn and adapt is to include any communication mishaps or triumphs as part of your retrospective ceremony — what went well and what didn’t go so well with regards to communication — and how can you factor this into your next working iteration?

Embrace that this way of working does not come naturally to some, and will be a new experience for many people. There is always more to learn. Take a look at what does and doesn’t work for your situation and adapt as necessary, and be sure to keep your shared communication principles document up-to-date.

To conclude, the advice in this article can be distilled into a few key points:

Use the right tool for the job (synchronous vs asynchronous discussion)
Build strong team alignment and encourage a default-to-action approach
Keep a record of important decisions and outcomes
Have a plan for escalating in emergency situations
Learn from your mistakes and adapt your approach
Foster a shared understanding of how to communicate effectively

By the way, DataCamp are hiring! There are a lot of open positions across many departments including Data Science and Engineering. Come and see, we’re eager to meet you!

5 things I wish I’d known as a junior developer

James Munro — Mon, 04 Nov 2019 12:08:00 +0000

As a junior developer, I was often fraught with insecurity and imposter syndrome with regards to my technical ability. I actually postponed the beginning of my career by at least a year due to these feelings.

Over the years these feelings have diminished somewhat, although not completely. Whilst not all of these points are related to confidence, if I had a time machine, I’d go back in time and tell myself these things. Ah, the power of hindsight!

1. You Don’t Need To Know Everything

Companies that are looking for junior developers are not looking for experts. If they were, the job advert would be for a mid or senior level developer. As I was starting out in my career, I managed to convince myself that I didn’t know enough or have enough experience.

In reality, it’s all about your attitude. A junior developer should be motivated, curious and capable of learning new things. As long as you have a reasonable thirst for knowledge, everything else will fall into place.

If a company expects more from a junior developer, they might not be worth working for in the first place.

2. Interviewers Aren’t There To Catch You Out

Due to my inexperience at the time, I always had it at the back of my mind that any interviews for developer jobs would go terribly for me. I would imagine these scenarios over and over in my head. It would often involve some kind of whiteboard test where I’d cave in under the pressure. I would forget everything I knew. The unfriendly interviewer would flip over the table and shout, with an air of superiority: “Aha! I knew you didn’t know how to reverse a string, fool!”.

In reality, most interviews are nothing like this. The interviewers are not there to catch you out, or to prove you wrong. They’re simply there to find the best candidate for the position they’re recruiting for. Any company that has the unfriendly above attitude toward interviewing is almost certainly not worth working for in the first place.

3. Don’t Be Afraid To Make Mistakes

As I started my career, I somehow convinced myself that I must not make any mistakes, and would be hard on myself if I did. I fully expected the company I was working for to punish me and banish me to a life of unemployment.

As a junior developer, you will make many mistakes. You should make mistakes — as long as you learn from them — and they are not always due to carelessness. It’s human to make mistakes. Senior developers make mistakes all the time. Although they are much more likely to anticipate and diagnose problems due to their experience.

If you find yourself working for a company that has unrealistic expectations about making mistakes — or has a blame culture — consider whether this is the best place for you to be working.

4. Embrace Change

Early in my career, I became a diehard native iOS developer. I would preach the benefits of native development over web technologies, iOS over Android, Objective-C over Java. I felt threatened by a suggestion that there was any other way to develop apps.

How things change! These days, whilst still primarily an app developer, the face of the technological landscape has changed substantially. I no longer preach Objective-C over Java, or iOS over Android. In fact, I’m no longer a diehard native advocate either. My preferred stack for the last few years is Javascript based (React/React Native) simply because it is the best tool for the kind of problems I’m working on.

I embrace that this will one day change. I’m comfortable with the fact that I can and will need to learn new technologies to best solve the problems at hand.

5. Figure Out What Inspires You

As I started my career, I didn’t really have much of an idea of the kinds of things that inspired and motivated me. Your first few industry jobs will likely be a journey of discovery that will help you calibrate your motivational compass.

Some people enjoy focussing on technical problems. Others like to focus on building software that adds value to people’s lives (where technical problems are just things that need to be solved). Somebody else might just enjoy learning new things or managing a team. Indeed, it’s quite possible to enjoy all of these things!

Whatever the case is for you, it’s completely okay not to know this at the start of your career as a junior developer. These things will likely change for you over time anyway. Don’t be afraid to try new jobs, work on new projects within a company or with new teams to discover what inspires you.

Summary

These are a few things I wish I could have told myself at the tentative beginning of my career. Of course, the journey of the junior developer never actually ends. Rather, it’s the very start of a lifelong journey as a developer. Stay curious, embrace change, figure out what inspires and motivates you and have fun!

Surfing the JavaScript Wave: Embracing Incremental Change in Real World Software Projects

James Munro — Mon, 04 Nov 2019 10:17:34 +0000

The JS ecosystem moves forward at a break-neck pace. New paradigms, frameworks, and tools are released seemingly every day. React Hooks are a recent example of this, with many software houses dropping tools in a race to rewrite their codebase to use the new techniques. But what do you do if you're in a small team, managing a non-trivial sized codebase, with limited time to invest in staying on the bleeding edge?

Deciding to adopt new technologies is not a straightforward process. It's a constant battle of weighing up the pros and cons of emergent tools and technologies; considering both the accumulation of technical debt, the potential risks of early adoption vs. the potential for huge productivity or product value gains.

In real-world scenarios, it is often not appropriate to drop tools and rewrite all your existing code to utilize something new. A balance must be found between keeping your knives sharp and still delivering a constant flow of business value. How can we balance these two seemingly incompatible workflows?

Grab your surfboard and ride the wave…

A Process for Incremental Change

In the Mobile & Practice squad at DataCamp, we have embraced a methodology of incremental change. Using a combination of simple tools and techniques we believe we have a flexible approach to keeping the knife sharp whilst still delivering business value on time: we focus on unlocking potential incrementally.

Whilst we do not have a formal procedure, a pattern has emerged over time around these steps.

Learn & Understand
Decide & Communicate
Embrace Incrementally

Let's take a deeper look at what this means.

Learn & Understand

We start with a discussion, focused around the goal of reaching a decision on how to move forward with a new technical initiative. For instance, when React Hooks dropped we were excited about the possibilities, but we resisted the temptation to drink the Kool-Aid and stop product development to re-write our codebase without first undertaking a real-world look at the actual benefits (Render Props - remember those?).

We start with an exploratory phase of learning about new technology. This is often in the form of pair/mob programming sessions. We start with a blank canvas and aim to get something basic working end-to-end. This will then develop into a further session where we take an existing portion of our production codebase and evaluate what happens if we adapt it to use the new technology.

We ask ourselves important questions:

What are the advantages of doing it this way?
Are there any (hidden) costs?
Is this a "viral" change - does it implicitly "spread" to other components

Just to give you an idea of what kind of things are in scope for these sessions, here are some recent sessions we have paired or mobbed on:

React Hooks (and therefore Functional Components)
End-to-end testing with Detox
Reducing "style debt" by using font primitives
Streamlining our workflow with Docker Compose

With our new learnings fresh in our minds, we can make a decision on if and how to proceed.

Decide and Communicate

Once we are satisfied with the benefits/costs of adopting new technology into our codebase, we can align on how we will embrace it incrementally.

We recently formalized our adoption of Architectural Decision Records (ADRs) as a tool for aligning-on and communicating our decision to adopt certain technologies. We even have an ADR for our use of ADRs!

The ADR is a simple markdown file and is initially introduced to the codebase as a proposal in the form of a PR. Using a PR allows us to discuss the proposal and further develop our shared understanding/knowledge around the technology.

The ADR will make it clear how we will adopt the technology moving forward and in the meantime documents the value and costs we learned about in the "Learn & Understand" phase. This way, future contributors (often our future selves) can refer to the ADRs to understand the context behind a particular decision.

Embrace Incrementally

Here's the fun part! Now we get to use the technology in the codebase. So, now we're going to drop everything and re-write everything from scratch? Wrong!

By using some simple off-the-shelf tools and strategies we can ensure that we embrace the change incrementally and sustainably.

Custom Lint Rules

Assuming the cost is low enough, we are big fans of introducing new eslint rules that we can configure as warnings. This allows us to assess our progress towards our goal of fully embracing a new approach over time. If a lint rule is not available for the particular use-case we have, we will also consider writing one ourselves.

For instance, if we are deprecating an old way of doing things we can use something like the react/forbid-elements rule to mark old-style components as deprecated with a warning.

Another nice side-effect of using the lint rule approach is that it lends itself to tidying things up as you go along: The Boy Scout Rule.

Boy Scout Rule

One of my favorite software engineering principles is the Boy Scout Rule often cited by Uncle Bob (Robert C. Martin). The notion is very simple:

"Always leave the campground cleaner than you found it."

When applied to our methodology of embracing incremental change, this can be paraphrased as something like this:

When touching older code related to the code you're currently working on, clean it up and update it to use your modern engineering best practices.

This is our main way of embracing change incrementally: ensuring that new code is written to our new standard, whilst refactoring and updating old code as and when we touch it.

A Real-World Example: Functional Components

A real-world example in the DataCamp mobile app is our adoption of Functional Components as a preferred approach to implementing components (with some exceptions of course).

After a thorough analysis and reaching a shared understanding of the costs and benefits of introducing Functional Components - and subsequently React Hooks - into our codebase, we set about introducing change incrementally. We began by aligning around an ADR that described our best practices for developing React components: focusing on why we prefer Functional Components, the advantages (and disadvantages) of using them over Class Components and when exceptions could be made. We also outlined our approach for adopting them in our codebase.

There were many instances of the class components already being used and we couldn't justify dropping tools to fix all of them. Rather, we focused on writing new components using only the new approach and adopted a strategy for incrementally reducing the debt over time using an eslint rule:

A warning is displayed when a developer inherits from React.Component and warnings will also be produced for all existing infringements of this new rule. This allows us to prevent the problem from getting worse whilst also allowing us to monitor the reduction of the problem over time:

Note that we also refer to the corresponding ADR within the warning itself: this helps to clarify the reasoning behind the rule for developers who may not have encountered this before, and also our future selves.

Using a combination of linting and the Boy Scout Rule as above, we are able to ensure that new components are written to the latest standard whilst simultaneously reducing the debt/embracing the change across the rest of the codebase. Eventually, when the number of lint warnings related to this rule are small enough, we can potentially just briefly focus our efforts on reducing the count to zero and making the warning into an error to prevent regressing on the debt.

Whilst this example is fairly simple, I hope it helps demonstrate how the process can be used to introduce incremental change across your projects with a clear adoption strategy whilst also promoting clarity for the reasoning behind the changes. By introducing change incrementally we are able to keep up with the latest developments of the JS ecosystem, whilst avoiding the duds and still continuously delivering business value.

Conclusions

In this article, we’ve looked at a simple process that you can adopt to embrace incremental change in your codebase. It’s not intended as a one-size-fits-all or a dogmatic mantra but rather as a loose framework which we use to embrace incremental change within our codebase:

Learn & Understand
Decide & Communicate
Embrace Incrementally

Keeping on top of the latest developments from the JS ecosystem is no easy feat. From a commercial software perspective, it’s a constant tradeoff between keeping your knife sharp yet still continuously delivering business value. However, with the right process and a surfboard, you can stay afloat!

Is this a wave you’ve also surfed? Let us know what techniques and approaches you’ve come up with to tackle this problem in the comments…