Developers use many, many tools to collaborate. Those tools solve problems, but also create new challenges: distractions impede productivity, developers struggle to keep up with everything, or partially adopted tools — those are just a few examples.
But how can we tackle those problems?
In this post, I share six recommendations that came out of a study a few colleagues and I conducted together.
Recommendation 1: Choose the Best Tool for the Job and Know its Limitations.
The academic version of this first recommendation reads: “be aware of channel affordances and choose tools accordingly.”
Which is a way to say: every tool has its own idiosyncracies. Not only what it looks like, or how it’s supposed to be used. But how people actually use it, and what the tool does to the people, their behavior, and their interactions with each other.
However, developers may not always be aware of every tool’s characteristics.
To make conscious and informed decisions, developers need to learn to recognize the strengths and weaknesses of different channels. They need to become aware of the tensions between private vs. public channels, synchronous vs. asynchronous communication, ephemeral vs. archival channel properties, and so on.
For example, our study participants pointed out that Slack is great at unifying many different services into a single, chat-based interfaced. But at the same time, people can start to feel overwhelmed by its notifications. Developers should inform themselves so they’re aware of such trade-offs before adopting a tool.
If developers can make tool adoption a deliberate choice, many potential challenges might not become problems at all.
Recommendation 2: Discuss Your Tool Use; Write Down an Explicit Agreement.
To enhance distributed work, Olson and Olson suggest that teams create a “communication covenant” (or agreement) to define what channels to use for what kinds of communication and how to use them.
Indeed, many successful open source projects recommend which channels to use, such as how the Angular project specifies which channels should be used for different activities (cf. CONTRIBUTING.md).
One participant thought that collaborators should not just agree on tools, but also agree on how they must be used:
The tool matters less than how people use it. Biggest problem is people not using tools the way it was agreed upon.
Although some project teams do figure this out without a formal covenant:
Small autonomous projects/teams who have a fairly mutual understanding of what communication/collaboration tools they want to use to achieve their needs/goals tend to experience little communication friction, I find.
Groups also need to pay attention to how tools are socially negotiated. Social protocols and tools not only need to be initially decided upon, but also adopted and adapted by people over time, thus being socially shared, modified, and appropriated.
Recommendation 3: Less is More When Adopting New Tools.
A common challenge reported by our respondents was channel overload.
Although there are many possible channels that developers can use, using too many will lead to feeling overwhelmed. The chances that information is fragmented across different channels will also increase.
One participant suggested the following:
The use of numerous tools may be overwhelming. It is usually assumed that it is better to use fewer tools, and increase the direct communication frequency between developers using face-to-face or chat.
Independent of this though, being more deliberate about what tools to adopt as described above will necessarily lead to fewer tools being actively used.
Recommendation 4: Stay Abreast of the Latest Tools That May Improve Development Productivity and Team Work.
This may seem to contradict the previous recommendation to use fewer tools.
But many of the more recent tools (such as Slack) aggregate communication from different tools through one channel.
We heard from our respondents that no one tool fits all needs:
There are too many sources of communication to monitor, I have been trying to use tools like HipChat and Flowdock to get a more unified communication channel.
Likewise, new tools may emerge that address other challenges — and they should be considered for adoption. Maybe a systematic and timexboxed process for tool evaluation can help ensure people don’t go overboard with too many tools.
Recommendation 5: Take the Time to Learn How to Use Tools Most Effectively.
As discussed above, knowing one’s tools is important. One study participant described how poor tool literacy can lead to frustrations:
Lesser-skilled developers sometimes struggle to use common tools like git / GitHub, screen-sharing, text-based communication, and to configure their own development environment. This [means those] collaborating remotely get bogged down in troubleshooting sessions.
A different survey respondent described how important it is to develop skills that make the most of particular channels and avoid challenges such as noise:
Developing filter skills to pick out the important things from the noise.
Knowing one’s tools reduces friction. In addition, there are some meta skills such as being able to filter out inconsequential information that improve one’s behavior across multiple tools.
Recommendation 6: Know When to Unplug.
Some of our study’s respondents described how they unplug from the Internet or from specific communication channels. This allows them to focus and to avoid interruptions and distractions.
One respondent shared how they consciously decide when to use certain communication channels:
I turn off most communication tools at the right times (i.e., when I’m not in need of feedback or help). I’ll still use GitHub for finding resources and a private messaging tool, HipChat, or email for quick questions.
Similarly, another respondent described using a command line tool to avoid the distractions of the browser:
If you have to go to a Web browser there is a 10% chance you’ll be distracted. I use the project `howdoi` to get answers from Stack Overflow on the command line so I can stay out of the browser and keep focus.
It is also important to be mindful about one’s feelings:
The biggest challenge is meta – e.g. *noticing* when I’m feeling overwhelmed or distracted and adjusting to adapt (e.g. closing IRC, taking a twitter hiatus, etc).
A survey respondent wrote that “one needs to exercise self control when using these tools, otherwise it’s easy to end up spending more time on them than needed.”
A different participant went a step further, suggesting that “sometimes it helps to have a day of development where you unplug [the] Internet.”
As much as we need to collaborate in today’s workplace: we need to continuously remind ourselves that yes, there is still work left that is best done alone.
This Is Hard, But It’s Getting Better
Software development is the one knowledge-based profession where its members use their own tools to build and improve on their own tools: programmers create collaboration software. And programmers are the first to try it out.
That implies that developers get to try out many different tools for working together. Some may work. Some work only for specific audiences. And others are just not a good idea.
In any case, developers definitely try out and end up using many different tools. Most tools solve a problem, but many also create their own challenges.
And we now saw that there are certain strategies that can help developers manage all these tools.
Does any of this ring true? Does anything sound off to you? Please go ahead — share your perspective with us in the comments.
My colleagues and I don’t claim that we’ve generally found out how things work when it comes to developers and their tool use. Our study just provides a look at a certain slice of the truth.
But this small look has already been pretty telling. And I hope that tool builders — developers, designers, product managers, and everyone else — can take some learnings from our research and use it to make new tools that are even better.
Let me know — I can’t wait to try them out. 🙂
[mc4wp_form id=”421″]
Note: the journal “Transactions on Software Engineering” has published an extensive report on our study; you can read the preprint here.