Coding can be challenging, but it can become a lot easier if you have the right strategies and tools.

After all, as noted software engineer and writer Joel Spolsky says, "it is harder to read code than to write it."

One way to make your development projects more successful is with collaborative coding. This refers to the process of working on the code with a team or with another developer. In a project that uses collaborative coding, each team member helps build the code and checks it for bugs or errors.

Working in pairs or teams helps finished code contain fewer mistakes and bugs, and this results in better code quality and projects being completed more quickly.

It also enables faster debugging and greater project resiliency, as this setup makes it easier for other developers to take over in case one of the developers has to leave the project.

But collaborative coding won't produce all of these benefits by default. Making them happen comes down to how you implement your collaborative development strategy and how you execute it. Here are four points to consider when doing so.

You Need a Secure Development Process

Although having multiple sets of eyes checking a project's code should produce a net benefit for the code's security — it can also introduce a new type of vulnerability into the mix. This is because sharing code through a collaboration platform creates the possibility of a data breach.

Humans, after all, are the weakest link in the cybersecurity chain. So, the larger the team, the greater the odds that someone will make an unforced security error during development.

And things like exposed or stolen login credentials can endanger a project — especially one that is designed to handle sensitive information like banking and personal details.

This means that project managers must choose a collaboration platform that's built with security in mind. Some collaborative coding platforms already have built-in security features, but others do not. And different types of coding projects will call for different feature sets, so there's no one-size-fits-all solution.

There are plenty of collaborative coding platforms that may fit the bill, however. Teletype, for example, comes with end-to-end encryption and the option to use self-destructing messages.

Another popular option is Brackets, which comes with data protection when interacting with third-party plugins and has a mechanism for preventing unapproved access and privilege escalation.

Some teams or developers might use established collaboration platforms not specifically designed for coding. Microsoft Teams, for instance, can facilitate casual coding collaboration. And although it's not an inherently insecure system, it has weaknesses that developers can address with an additional Microsoft Teams Security solution.

These solutions include features like malware protection, URL protection, access control over confidential data, compliance tools, and security alerts – which all improve platform security significantly.

Regardless of the platform you choose, though, it is important to use security tools or to install third-party security solutions that ensure the best possible security for your project.

Choose the Right Platform for the Job

It's also important to recognize that security isn't the only consideration when you're choosing a collaborative coding platform.

It's also critical to choose one that will provide every team member with the tools and resources necessary to do their job. The right platform should meet the following criteria:

It's made for a specific programming language or ecosystem

There are many benefits in using a platform that is created for a specific programming language. First, it most likely has all of the tools necessary to efficiently work on a project in a particular language. And it won't have unnecessary features added to cater to other requirements and preferences.

A language-specific platform is also designed with best practices in mind for developers working with particular languages or frameworks. So, for example, when working with dynamic programming languages such as Go, Ruby, and Python, it is preferable to use a platform like Cloud9.

It's fast to setup

Ideally, everyone involved should already be familiar with the collaborative coding platform that you'll use. But if this isn't the case, it's important to choose one that is easy to learn with minimal to no configuration involved.

A platform that requires IDE, server, terminal, codebase, and library configuration along with other setup procedures is not the most suitable option for live coding between pairs or teams of developers.

It should have a customizable user interface

Programming is a heavily detail-driven job and developers tend to have their own preferences when it comes to the user interface so they can work easily and conveniently.

Forcing everyone to use a platform they are not comfortable with is not a good way to proceed with collaborative coding. So it helps to have the option to modify the UI or dashboard to some extent.

The bottom line is that the collaborative coding platform should be easy to use for everyone. Developers may be highly skilled people, but not everyone is a master of everything. Those who are collaborating should agree on a platform and working arrangement that works for everyone.

Define Clear Team Roles at the Outset

We can categorize collaborative coding into three general setups:

• pair programming
• mob programming, and
• code sharing.

And understanding the inner workings of each of these setups is important, as different coding projects require different setups.

But it's equally important to understand the roles of the team members in each setup and to define them before beginning to code.

As the phrase suggests, pair programming involves two participants. Usually, one serves as the driver and the other acts as the navigator. The driver writes the code while the navigator reviews the output.

In this setup, the driver is responsible for the tactical aspects of the job while the navigator sets the strategic direction of the code. The two may then switch their roles to have a more thorough look at what they have produced.

Mob programming is similar to pair programming but involves more than two people. To avoid making it a chaotic or disorganized arrangement, it is also important to have the driver-navigator role assignments.

It is slightly more complicated, though, because there are more than two developers who have to agree on how to assign the driver-navigator roles. This means that clear communication and mutual respect are crucial.

The code-sharing setup does not require a driver-navigator dynamic. Instead, the collaborating developers only share their respective code to allow each other to review, modify, debug, or add to each other's code.

This is the type of collaboration that open source developers tend to rely on because it allows newcomers to participate at will and existing developers to pause their work whenever they need to.

The participants here may work on the code together in real-time or asynchronously. What's important is that they have a reliable system for version control.

That's where version control systems like Git excel. They help teams to avoid doing duplicate work and make sure that all developers are reviewing, revising, or adding to the latest version of the code at all times.

Create Skill Balanced Teams for Best Results

While some would consider collaborative coding as an opportunity to learn from more experienced and proficient coders, that doesn't mean every collaborative project is conducive to that.

This is because for certain types of projects, having too much of a disparity in the skill level of team members can grind the whole project to a halt.

This is a problem that feeds one of the biggest criticisms of collaborative coding as a development method. When team members must contribute as equals but lack the skills to keep up, progress stalls. When time is of the essence, creating a skill-balanced team is the only option.

That said, collaborative coding can be an opportunity for collaborative learning, but only when deadlines aren't involved. In that scenario, team members can take their time to learn from the work of their more experienced peers. And in the end, everyone benefits from the experience.

But if the goal is to make the project a collaborative learning endeavor, it is important to make that clear from the get-go. Otherwise, the more experienced developers could feel like they've been duped into providing training instead of getting the project done. And that never ends well.

Conclusion

The advantages of collaborative coding are undeniable — but there are drawbacks to consider too.

So, before deciding to go into the collaborative route, it is important to carefully scrutinize the pros and cons as they relate to a specific project.

And for developers who wish to try their hand at collaborative coding, it's a good idea to get familiar with the popular tools and platforms used for such projects beforehand. That way, both the project planners and team members will get the most out of the collaborative process — but without encountering some of the issues that it can entail.

Featured photo by snowing 12 - stock.adobe.com

Behaviours and skills exhibited by the very best pair programmers.

I know this is serious business but this pair are off the chart cute.

Dr. Sallyann Freudenberg is a software engineer and psychologist who has spent some serious time observing the behaviours of high performing software teams. Her blogs contain a wealth of information for any software professional looking to sharpen their skills.

As an engineer with no psychology background whatsoever, I couldn’t help but think — this is some really, really good stuff. It’s accessible, easy to understand and clear. I thought… perhaps I’ve picked up the wrong career? Maybe I’m a psychologist! So I read a little Freud and oh my god the horror, so I’m definitely still an engineer and have no interest in psychology any more. Also I can’t look my mother in the eye.

Anyway, after many hours of repetitive strain injury-inducing labour, here is what I have produced. A collection of tips, based on the work of Dr. Freudenberg. My hope is that you’ll use this as a primer, an appetiser if you will, before diving into Dr. Freudenberg’s work and developing a more full understanding. Let’s get started.

Take Regular Breaks

Easy one to open up with. I know I sound like your mother when you were young. She warned you against square eyes. Well she was wrong about the square eyes thing but she was right about taking a damn break once in a while.

Regular breaks are well understood in psychology. In the context of pair programming, they:

• Prevent context from building up too much. Breaks break things up.
• Lower the cognitive load and enable longer overall pair programming sessions.
• Make you happier!

Of all the basic sins I see, this is the most common. Five hour meetings with no time budgeted for breaks. “Powering through” isn’t always the answer. Sometimes, going for a coffee or a beer (depending on how stuck you are) can provide the answer too. If you’re interested, there is a brilliant book about slack time that gives a much fuller answer to this topic.

Push the keyboard, don’t take it

The keyboard, in Dr. Freudenberg’s research, was the physical component of control. Engineers would pass the mouse around freely in Canada, but the keyboard was held sacred. In high performing pairs, the driver would volunteer control of the keyboard. It would never be taken. From this, we can glean a simple rule for both the driver and the navigator.

The Driver — learn when to pull over.

The example from Dr. Freudenberg’s research illustrates this.

Example 1 (Anna is navigating, Ben is driving):

Anna: “If you…..go to….”

Ben: (sliding the keyboard over to her) “(You) drive….it’s easier”.

The driver is aware of the most effective way to communicate and is happy to relinquish control when needed. Don’t let your ego cling to the keys. Hand it over when necessary.

The Navigator — don’t disempower.

When you’re watching, watch. Drop hints, be friendly, but don’t force control out of the driver’s hands. It creates resentment. Treat that keyboard carefully.

The driver is often seen as the position of power in the pair, but the navigator has the ability to derail the whole exercise by hijacking the keyboard when things get tricky. With great power comes great responsibility.

Have somewhere to draw.

A whiteboard is the gold standard here. A nice, big, clear space to draw all over. Words are great and all but nothing beats a bunch of wonky boxes and not so straight lines.

In Dr. Freudenberg’s research, a key finding was the use of scribbled on diagrams in high performing pairs. The creative act of writing the diagram sparks thoughts and jogs memories. They were far more powerful than pre-existing diagrams, which seemed to be more useful when seeking a holistic view of multiple teams and systems.

Sometimes things are difficult to convey without a hastily drawn picture. If you don’t have a whiteboard, use a notepad. In one example, Dr. Freudenberg observed someone tracing a diagram with their finger. Drawing sparks joy people!

Invite spontaneous outside help

So there you are, working through a problem. An API that needs consuming and saving into a database. You debate, discuss and start writing. Nothing is working and you don’t know why, but if you can just focus… just a little longer. A few more uninterrupted hours.

Then… Bill from the payments team leans over and asks you about something you just said.

Oh my GOD Bill

But Bill has got a good point.

“Hey, that endpoint actually uses a different model to the other APIs”, Bill mutters, acutely aware of the thunderous look in your eyes. You could be mad at Bill, but the truth is, he was right to stop you. You were about to write some broken-ass code. Is Bill the enemy? No. Your way of working is.

Interruptions are going to happen, especially when you’re building the wrong stuff. The truth is, Bill just saved your bacon. In Dr. Freudenberg’s research, this kind of open communication was welcomed by high performing pairs. It increased knowledge transfer and made for a much more efficient pairing.

So go apologise to Bill. He just saved you a bunch of time and fresh grey hairs.

Preserve Context

The problem with the previous scenario was the context. Maybe Bill could use some personal boundaries training, but if it wasn’t Bill, you know it’d be Sandra from the Ops department. Bloody Sandra…

That complex clockwork of context in your minds eye is only available in your living room. In the workplace, you’re gonna need to talk and not always on your own terms. Dr. Freudenberg explains that software engineers need to operate at multiple levels of abstraction at the same time, constantly flitting in and out of levels of detail. This creates problems when building up large, complex images in your mind. How do the high performing pairs deal with this?

Lists, you silly goose

The key is to keep focused on what you’re doing. When you find new things, put that down in writing. The items in the list form little flags, reminders of questions and facts you’ve unearthed. This means you can remain focused on the problem at hand and not lose track of the discoveries you’ve made along the way.

The next time James from HR comes in to tell you to stop high fiving strangers in the lobby, your context won’t be obliterated. You might be slowed down for a moment, but glance down at those sweet lists. You’re back in the matrix.

And one more thing about lists

Before you go all sharpie-pro on your checklist, Dr. Freudenberg has one more finding. More often than not, lists are not revisited. They’re written and discarded. It’s essentially just a bit of ephemeral storage for your brain. Don’t worry about neatness. Worry about getting your ideas on to something more permanent than the jelly in your head and protecting the current object of your focus.

Share the burden with tag team pairing.

Coffee number seven. This damn test won’t go green, no matter what you try. You decided to swap when it did, so you’ve been driving for well over an hour. You’re tired, your partner is bored and progress has all but stopped. Soon, you’ll go home and drink whiskey like any 90s American action hero.

We’ve seen this a thousand times. Individuals investing too heavily in the problem and refusing to review their goals. Often it’s pride, sometimes it’s sheer belligerence. To combat this, Dr. Freudenberg found that as well as specified goal points, high performing pairs would “tag” one another in.

Avoid steroids… but other than that, these guys provide some good pairing role models.

This makes intuitive sense, right? In the ring, if Stone Cold Steve Austin is growing tired, you know he is gonna tag The Rock in (my wrestling knowledge is pretty out of date). If you’re running out of juice, it should be a legitimate reason to change drivers. Don’t trip and fall into the death march.

Follow Dr. Freudenberg on Twitter! I do and you should too. Also, the source material for this article (including all relevant academic sources) is available on Sal’s wonderful blog.

While you’re at it, follow me on twitter. I’m regularly blogging about the work of other, smarter people.