Forem: CoScreen

Four Easy Ways for Refactoring Your Python Code

CoScreen — Wed, 09 Jun 2021 19:20:27 +0000

It's time to open up that Python code you wrote a while back and add a few new features. Or maybe you just finished some new code and want to give it a once-over before releasing it to production. Either way, it’s time for some Python refactoring.

In this post, we’re going to cover four techniques for Python refactoring. Some of them are specific to the Python language, and one is more general. We’ll include samples with each technique to demonstrate it in action and show you how to apply it to your code.

What Is Refactoring?

Before we look at the techniques, let’s make sure we agree on what refactoring means.

Refactoring is altering source code without changing its behavior. We do this to improve the code’s design so it’s easier to maintain, update, and test.

Refactoring has been around for a long time, but Martin Fowler recently wrote a book on the subject, and his definition is worth taking a look at.

Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which "too small to be worth doing". However the cumulative effect of each of these transformations is quite significant. By doing them in small steps you reduce the risk of introducing errors. You also avoid having the system broken while you are carrying out the restructuring - which allows you to gradually refactor a system over an extended period of time

Fowler introduces a few key concepts here. Refactoring consists of small steps. It’s not rewriting code; it’s making small, gradual improvements. It’s also an ongoing process, not a series of big sweeping changes.

Refactoring Python Code

Use Enumerate() Instead of Loop Variables
Let’s go through a list and print the items with a counter.

i = 0 for item in things: print('{}: {}'.format(i, item)) i = i + 1

The counter doesn’t help with readability at all here. It’s initialized outside the loop, and incrementing it requires an extra step. In Java or C, we could use the increment operator inside the print statement, but it doesn’t exist in Python. The increment operator, to be honest, wouldn’t do much to make this code more readable either.

But there’s an easier and more pythonic solution than adding a variable and incrementing it inside the loop.

for i, item in enumerate(things): print('{}: {}'.format(i, item))

Python’s enumerate() does the work for you by adding a counter to the list. This code is half as long and much easier to understand.

Inline Variables When Possible

Refactoring isn’t only about reducing the number of lines in your source code even though that’s often a common side effect.

def get_value(self, key): if key in self._jinja_vars: value = self._jinja_vars[key] if value is not None: return value else: return None else: return None

In this example, value is declared and then goes out of scope almost immediately. We have two opportunities to shorten this code and make it more readable at the same time.

def get_value(self, key): if key in self._jinja_vars: return self._jinja_vars[key] else: return None

When we get rid of the check for None, we don’t need to create value at all. This is safe because we can return the value without checking for None since we would return it anyway. The important check, verifying that the key is in the dictionary, has already been done.

Use Values() To Traverse Dictionaries

Python's tools for manipulating its data structures make it easy to write readable code. But if you're coming to Python from another language, you might not be familiar with them.

Let's look at a function that searches a dictionary of dictionaries for a specific key/value pair.

def get_item_by_color(self, color): for keys in items: item = items[key] if item['color'] == color: return item

At first glance, this function looks like another candidate for the previous refactoring. We could factor out the creation of item on line 3 and use the dictionary key instead. But would that really make this code easier to read?

There's a better way. The values() function will return each value in the dictionary instead of the key.

def get_item_by_color(self, color): for item in items.values(): if item['color'] == color: return item

Since we can work directly on the item provided by the loop, this change shortens the code and makes it easier to understand at the same time.

DRY: Don’t Repeat Yourself

Many developers learn Python as a utility language for writing command-line scripts. They’re accustomed to seeing large blocks of code in a single source file, with few or no functions. The files grow line-by-line over time, often via cutting and pasting.

But even in the simplest scripts, don’t repeat yourself (DRY) is a programming guideline you should follow.

Let’s look at a code snippet that downloads information from a REST API. We could imagine that it started retrieving just one dictionary from the server and growing over time. Each time the developer added a new function, they copied and pasted the previous one and made a few modifications.

Each function repeats the code to query the web server. If we want to switch to a different authentication method, add request logging, or enhance error recovery, we’ll have to modify each one of them.

def _get_field_database(self, jira_host): url = '{}{}'.format(jira_host, '/rest/api/3/field') result = requests.get(url, auth=HTTPBasicAuth(self._jira_user, self._jira_passwd)) schema = json.loads(result.text) fields_by_name = {} for field in tqdm(schema, file=sys.stdout, desc="Fields database"): fields_by_name[field['name']] = field return fields_by_name def _get_user_database(self, jira_host): url = '{}{}'.format(jira_host, '/rest/api/3/users?maxResults=500') result = requests.get(url, auth=HTTPBasicAuth(self._jira_user, self._jira_passwd)) users = json.loads(result.text) user_by_name = {} user_by_email = {} for field in tqdm(users, file=sys.stdout, desc="User database"): if 'displayName' in field: user_by_name[field['displayName']] = field if 'emailAddress' in field: user_by_email[field['emailAddress']] = field else: user_by_email[field['displayName']] = field return user_by_name, user_by_email def _get_projects_database(self, jira_host): url = '{}{}'.format(jira_host, '/rest/api/3/project/search') result = requests.get(url, auth=HTTPBasicAuth(self._jira_user, self._jira_passwd)) projects = json.loads(result.text) project_by_name = {} for field in projects['values']: project_by_name[field['name']] = field return project_by_name

So let’s factor the REST API query into a separate function.

def _get_field_database(self, jira_host): schema = self._exec_query('/rest/api/3/field', jira_host) fields_by_name = {} for field in tqdm(schema, file=sys.stdout, desc="Fields database"): fields_by_name[field['name']] = field return fields_by_name def _exec_query(self, query_string, jira_host): url = '{}{}'.format(jira_host, query_string) result = requests.get(url, auth=HTTPBasicAuth(self._jira_user, self._jira_passwd)) return json.loads(result.text) def _get_user_database(self, jira_host): users = self._exec_query('/rest/api/3/users?maxResults=500', jira_host) user_by_name = {} user_by_email = {} for field in tqdm(users, file=sys.stdout, desc="User database"): if 'displayName' in field: user_by_name[field['displayName']] = field if 'emailAddress' in field: user_by_email[field['emailAddress']] = field else: user_by_email[field['displayName']] = field return user_by_name, user_by_email def _get_projects_database(self, jira_host): projects = self._exec_query('/rest/api/3/project/search', jira_host) project_by_name = {} for field in projects['values']: project_by_name[field['name']] = field return project_by_name

Now each function calls _exec_query() to get the data it needs from the server. This codes scans more easily now, and modifying the REST query code will be simpler when the time comes.

Python Refactoring in Pair Programming

Birgitta Böckeler and Nina Siessegger briefly discuss refactoring in a post about pair programming on Martin Fowler's blog. It ties the activity to pair programming with test-driven development (TDD.) Refactoring is a critical part of the TDD process since you always take the opportunity to refactor new code after passing a test.

The post recommends a "ping-pong" methodology, where pairs take turns writing a test, writing code to pass the test, then refactoring the code together. Having a second set of eyes to review code and make sure it's readable as soon as it's verified with a unit test makes for better code.

Are you interested in reading more about distributed agile teams?
Read this guide about three steps that will help you get started now!

Get Started With Python Refactoring

We talked about what refactoring is and what its goals are. Then we covered four simple refactoring techniques that will help you make your Python code easier to read and maintain. We also discussed how you could fit refactoring into a pair programming setting.

Take the next step and see how you can apply these techniques to your Python code. But don't stop there! There are plenty more refactoring techniques you can use to up your Python game.

This post was written by Eric Goebelbecker. Eric has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!).

Join the Electron Developer Office Hour

CoScreen — Wed, 26 May 2021 21:28:01 +0000

Learn and ask your questions about ⚡️ Electron - the hugely popular open-source framework that powers VS Code, Slack, Discord, and many other great desktop apps.

Get an intro on how to get started with Electron, our lessons learned, and bring your questions!

Electron is a hugely popular open source framework that enables the development of cross-platform desktop apps using web technologies.

If you have ever used Visual Studio Code, Slack, Discord, or an endless list of other great apps on macOS or Windows, you’ve used Electron.

We believe in creating a meaningful space for developers of all levels to learn, collaborate and catch up on the latest technologies and frameworks. We’ve created a dedicated block of time to make sure someone from our team can help answer questions and facilitate the conversations for our growing community.

The up and coming Developer Office Hour will be hosted by Brad Carter, Software Engineer at CoScreen and an Electron enthusiast.

Here’s the rough agenda:

Quick intro on Electron and how we use it at CoScreen to build our cross-platform collaboration app
Helping you to decide when it is the right technology for you and when it isn’t
And, of course, do our best to answer all of your questions.

The event will be hosted on June 3rd 2021 at 11 am PST / 2 pm EST.

Make sure to include your name and any useful information so we can help you best.

We are looking forward to chatting with all of you and learning together.

*not all questions will be answered, but we will do our best to :)

The CoScreen Team

Getting Started with Collaborative Livestreaming

CoScreen — Fri, 16 Apr 2021 18:10:11 +0000

A case study with The DevRel Salon

Are you looking to get into livestreaming? Are you wanting to do something collaborative, like pair programming or running an unconference-style meetup? Understanding the tooling for collaborative livestreaming can be daunting.
Read on to learn about the tooling I use to run The DevRel Salon, a live collaborative conversation among developer relations professionals.

Tl;dr

You don’t need a specialized or dedicated computer for this kind of livestreaming, use what you already have
Use the webcam you have, video resolution doesn’t actually matter much
If you have a DSLR or mirrorless camera, check to see if the manufacturer has made a webcam driver available
Consider purchasing a dynamic (as opposed to condenser) USB microphone, audio quality does matter
Use Streamyard to produce your stream, it is an easy-to-use turnkey solution for both general production and handling guests
Use CoScreen for live collaboration with your guests
Use Twitch to broadcast your livestream to your audience
Be sure to set up the moderation options
Have fun with it, if you’re stressed out or not having fun, your viewers will notice. Set yourself up for success by keeping things as simple as possible

Howdy, I’m Don! I’m a systems and backend engineer, and a developer relations expert. I was once an engineer at Screenhero, but over the years I moved into developer advocacy at places like Slack and GitHub, where I helped other engineers get the most out of those platforms.

For the past few years, I’ve helped organize and run a The DevRel Salon, an international meetup for developer relations professionals. But rather than the usual format of having invited speakers lecture an audience, our focus has been on creating a collaborative learning experience by fostering conversations among peers. Our goal is to create a welcoming space for both seasoned and novice developer relations professionals to share their stories and experiences without trying to dictate topics or reinforce hierarchies.

To do this, we use a simplified Open Space Technology format. Participants arrive at the specified time and location, usually a café with a comfortable terrace, or a host organization’s office. To encourage conversation, we might suggest a topic, or invite someone with a unique experience to share. The guests then break off into one or more conversation groups. Crucially, to help spread the conversation beyond just those present, we assign a note-taker to each group to capture the details of the conversation (respecting the privacy of those present, of course).

But in the era of COVID, such gatherings are not possible. After nearly a year of dormancy, we have started experimenting with a new format: Livestreaming. But it was really important to us that we capture what made the in-person events so compelling, the inclusive interactivity. We couldn’t just put some talking heads on the screen, and let the collaboration play out in the stream chat—we tried that, and it failed. We needed to create a more collaborative environment.

Here is a short primer on what worked for us: The equipment, software, and processes that we settled on for our experiment in collaborative livestreaming.

Overall Structure

The way we structure the DevRel Salon livestream is not so different from other livestreams. We pick two hosts to facilitate the conversation, to keep it going, and help guide it in useful ways. They’re the people you see on the screen at the stream’s start. Additionally, we have a producer running the show, moderating the chat, inviting guests into the live conversation, and generally keeping things moving smoothly, although one of the hosts could also play this role. Finally, the producer is working with a dedicated note-taker to keep track of the conversation in a shared markdown document. Then we invite folks from the Twitch chat into the livestream to share their expertise and opinions. The conversations seem to last a bit over an hour before it plays out.

Computers

Of course everyone involved will need a computer. Your hosts and guests don’t need anything special, they can even use a smartphone to join the stream. But the producer’s computer is where all the audio and video come together to be encoded into a single stream. The producer will need a solid internet connection, and a computer capable of keeping up with the encoding demands, but it’s not so bad as you might think. We stream at 720p and I find that my 2017 15” MacBook Pro is more than enough machine to keep up with the demands, although the fans do come on.

Don's remote setup

Camera

Opinions differ about the need for serious webcam and microphone hardware. Between more people working from home, and a computer chip shortage, most popular items have become more difficult to find online.

Believe it or not, the webcam you already have is probably fine. The reason is that the entire video stream will be encoded into 720p or possibly 1080p, but your webcam’s video will only be a portion—possibly a very small portion—of the entire screen. I have an 8-year-old Microsoft LifeCam Pro that I used until recently with no trouble.

If you have a DSLR or mirrorless camera, many camera manufacturers have recently released drivers that allow you to use their products as webcams as well.

The more light you have, the better your webcam’s image will be. So I strongly recommend using a keylight. I have an inexpensive pair from Neewer—the build quality is awful, but they do put out a lot of light, which is the important bit. But there’s no need to spend money if you have an adjustable desklamp that you can shine into your face! You’d be surprised how effective that can be for improving the picture quality on nearly any webcam.

If you’re on a Mac and using an older USB webcam, Webcam Settings is an invaluable tool for extracting the best possible image quality, allowing you to tweak the exposure settings manually to make the best use of whatever light you have available.

Microphone

While the human eye can tolerate a low quality image, low quality sound can make understanding you very difficult. And, while there are inexpensive things you can do to improve your image quality, there’s almost no way to improve the audio quality from a cheap microphone. My home office is very noisy, it’s full of echos because it has a very high peaked roof. For that reason, the built-in microphones in my laptop and my webcam make me sound like I’m in the back of a cave, almost unintelligible.

Buying a dedicated microphone is the one place I strongly recommend you invest a little money. There are a variety of microphones targeted at podcasters that are perfectly suited for livestreaming as well. Most podcasting microphones come with a USB connector, instead of the old fashioned analog XLR connector; You should get one that provides USB output. Setting it up is usually just a matter of plugging it in. There is no advantage to be had in buying a microphone with an XLR output.

There are two different microphone types you should be aware of: Condenser and dynamic.

Condenser microphones are very sensitive, capable of capturing every nuance in your voice. This makes them the microphone of choice for recording studios, and are the most common kind of podcast microphone on the market. However, for these very reasons, they are terrible in less than ideal environments, as they will faithfully capture every bit of noise and echo at your desk. So, unless you have an acoustically tuned recording studio, I don’t recommend these. Unfortunately, most podcasting microphones are condensers.

Dynamic microphones are less sensitive, and are usually used for live performances on stage where there’s a lot of noise. For this reason, they also make great microphones for home offices or otherwise noisy or echo-y environments. The down side is that you have to bring them quite close to your mouth, so it will be visible in the video feed. I use a Røde Podcaster USB microphone: it gives my voice a warm, rich tone, and totally ignores all the echo and noise in my office.

Streaming service

Twitch is the de facto standard, and it’s where most people look to find a livestream. But it can be hard to understand, because its UI is frankly terrible. Once you sign up (it’s free), you’ll need to make a few changes to the settings.

The first is to enable disconnect protection. If you lose your connection in the middle of a stream, with this enabled, Twitch throws up a “technical difficulties” screen to let your audience know there is a problem, instead of just dropping the stream entirely. You can find it on your dashboard at:

The second thing is to turn on the automatic moderation. You never know who might show up in your chat and start causing problems. AutoMod scans your chat, and holds questionable comments for moderation. Here are the settings I chose for The DevRel Salon, but of course you can change these whenever.

Finally, to keep trolls out of your livestream chat, you can turn on email verification. Normally, literally anyone can show up in your chat anonymously, but by enabling this feature, anyone wanting to participate must have a valid email address, thus creating a small barrier to entry that will keep most trolls away.

Turn on email verification:

Finally, maintaining a schedule is important, because viewers like predictability. Decide when to air your first livestream, and set it up in the Twitch show calendar:

https://dashboard.twitch.tv/u/YOUR_CHANNEL_NAME/settings/channel/schedule

Don’t forget to share your upcoming show with your network!

Livestreaming software

OK, you have Twitch set up, but how do you get your webcam (and your other guests’ webcams! And the show notes!) into Twitch? You need production software. Production software takes all the various video and audio feeds, combines them in a visually pleasing way, and ships them off to Twitch in real time.

You may have heard of OBS, as it is the gold standard for livestream production. It can literally do anything you want it to…but as you can imagine, the learning curve for accomplishing even the simplest of tasks is extremely high. For this reason, I don’t recommend starting with OBS.

Instead, I recommend Streamyard. Streamyard is not nearly as flexible as OBS, but it provides a set of simple features that automate the most common livestreaming processes. Streamyard makes it easy to invite guests, share a window or a screen, and to manage the overall layout of the different video elements. Customizing with your own branding is a matter of uploading a few images. It funnels conversations from Twitch and other streaming destinations into a single chat pane, and you can highlight individual comments on the screen. OBS requires a fairly advanced understanding to do these things.

That said, access to all of these features in Streamyard costs money, where OBS is free, but costs time and stress to get over the learning curves and create the screen layouts and motion effects in Streamyard.

Streamyard can take your produced stream and send it to a number of locations. To set it up to send the stream to Twitch, visit:
https://streamyard.com/destinations/connect

It’s worth noting as well that if you don’t want to stream your session live, StreamYard has an option to simply record your session, for you to share on YouTube later. When you create a new broadcast studio, you’ll be presented with that option. Alternatively you can use a dedicated recording tool like getwelder.com or riverside.fm to make the recording instead of Twitch + Streamyard.

Collaboration software

Finally, if you are doing on-screen collaboration, you need a way to share access to your work! Although both Streamyard and OBS allow you to share a window into the livestream, neither offers any kind of interactivity with guests. So we need one more piece of software. There are two primary contenders in this space: VS Code Live Share and CoScreen.

VS Code Live Share is at the moment the most popular option, as many developers already know and use VS Code. If you and your guest are only working on text files (like source code), and are both already comfortable with VS Code, then it’s a great option that’s easy to get started with. But outside of that limited scope, VS Code Live Share is less appealing, particularly if you prefer a different IDE like Xcode, Eclipse, or JetBrains. VS Code Live Share also doesn’t work if you want to collaborate on something that is not pure text, like a web page rendered in a browser, or graphic or UI design, or UI design.

CoScreen is a new option that makes collaboration feel more natural. A spiritual successor to Screenhero, CoScreen allows you and your guests to share windows from your individual desktops to more naturally recreate the experience of working together on the same computer. It lets you use the tools you’re already familiar with, and invites more interactive collaboration. CoScreen is the best option when you want to go beyond text editing, for example, to share a web browser to preview or test a web app, or work together on UI design for an iPhone app in Xcode.

Naturally, I recommend CoScreen for its flexibility. Make sure you and any guests have downloaded CoScreen and created an account. CoScreen uses the concept of a shared room for collaboration, called appropriately enough “CoScreens”.
Make sure you have one created for the livestream, and that all your guests have the URL to join it. Click the “New CoScreen” button in the CoScreen dashboard to make that happen.

Go time

Now, how do you put all these pieces together?

Create a new broadcast in Streamyard

And clicking “Create a broadcast”. Choose Twitch from the list of sources, or if you want to only record your session for sharing later you can choose “Skip, Record only”.

Choose a source for the broadcast

Once you’re in the studio, make sure your camera and mic work. Invite your guest using the “Invite” button at the bottom:
Set up your share collaboration space. For the DevRel Salon, we use a markdown file to record notes from the conversation; I pull up a new file in Sublime Text, and use CoScreen to share that window with the note-taker so we can work on it together during the show.

Open the application you’re going to work on together, and click the “Share Window” tab that CoScreen places above the foreground window.

This will add the window into the share workspace.

Then I share the Sublime Text window into the stream with Streamyard using the “Share” button at the bottom of the Streamyard window.

Make sure to add yourself, your guest or guests, and the shared window into the stream, by hovering over each thumbnail, and clicking “Add to stream”:

Add everyone to the stream
The results should look something like this:

We’ve got the guests on the left, and the document we’re collaborating on via CoScreen on the right.

Although Streamyard handles all the chat really transparently, it doesn’t expose Twitch’s moderation tools. So you’ll have to open the Twitch moderation dashboard in a separate window:

https://www.twitch.tv/moderator/**YOUR_CHANNEL_NAME**

When everything is in place, just hit “Stream”! Once the session is over, you’ll be able to grab a recording of the session from Twitch (if you streamed it) or Streamyard (if you chose “Record only”). In Twitch, visit: https://dashboard.twitch.tv/u/YOUR_CHANNEL_NAME/content/video-producer

To get a list of all livestreams ready to download. Don’t forget that Twitch only holds your recordings for two weeks!

Download the livestream list
Results
See for yourself!

Took about two hours to set up, most of that was creating the branded graphics for Streamyard, and figuring out the configuration options on Twitch. I’m confident you’ll be ready to do some live collaboration yourself in no time.

Remote Pair Programming: A Developer's Getting-Started Guide

CoScreen — Mon, 08 Feb 2021 21:39:39 +0000

The popular conception about programming is that it's a lonely job. Movies and TV give us the image of the sole hacker, sitting in a dark room. They drink too much caffeine, and they're able to cobble together software to do anything at a moment's notice.

A programmer, Hollywood tells us, is a wizard. They live alone, they're very prickly, and you can never understand them. Reality tells us something else altogether. Programming is actually a very social job! The average programmer spends time reviewing their teammates' code and contributing to planning meetings. And for those trickiest tickets? Many developers don't turn off the lights and turn up the music. Instead, they reach out to a teammate and hop into a pair programming session.

Many programmers find pair programming an intimidating task. They're not excited about the idea that someone will watch them write code. Fortunately, that's not what's going to happen. In this post, we're going to talk about the benefits of pair programming and how good pairing sessions go. We'll also talk about some necessary skills for pair programming and especially how pair programming can work in a remote-first environment.

Why Pair Programming?

If you've never worked through a pair programming session before, this is probably your first question. Why would I want to work on a problem side by side with someone else? The answer is, sometimes you don't! Pairing up isn't the right choice for every problem. Are you tweaking some content on a login page or fixing the alignment on an image? That's probably not a task you need two people to finish.

Instead, a pairing session is best for complicated tasks. That might be designing a new API for an external product. Or maybe you're trying to fix a nasty bug. In those cases, having an extra set of eyes helps provide better code that you write faster than one person working alone. When the developers are truly skilled at pair programming, they deliver code approximately as quickly, but with fewer defects than when working alone... The benefits to this are obvious: if two programmers working together produce code three times faster, that's a huge efficiency win. As a bonus, that work often has fewer bugs and better tests. Skilled pair programmers often deliver better code faster.

Driving Versus Navigating

In any pairing session, there are two roles, and they'll be filled by each person at different times. The first role is the driver. This is the person who has their hands on the keyboard and mouse. They're the one who's actually typing out the code and controlling the windows in the UI. The other role is the navigator. The navigator's job is to think about the bigger picture surrounding the code. They'll make suggestions to the driver about where to take the code. Their job is to think about things like what parameters you'll need on that function or how to test that bit of logic you just added. They also have the added benefit of quickly identifying bugs the driver adds to the code.

As mentioned, throughout a pairing session, each member will end up working in each role at various times. There's no such thing as someone who's only a driver or only a navigator. Filling one of these roles for an extended period of time is draining on your brain, and your work's quality can decline. Instead, practice switching on and off, finding a good time for one person to drive and one to navigate, then switching off after you finish a discrete part of the code.

Remote Pair Programming

To this point, we haven't talked at all about where the pair programmers are located. You've probably been envisioning them inside an office, chairs side by side. And that's a great way for pair programming to take place. However, there's no requirement for two developers to pair together in the same room. In fact, pair programming works just as well in remote settings. I've been a remote-first developer for nearly ten years, and I find pairing just as effective over something like Zoom as I do sitting next to my teammate. Knowledge doesn't require colocation, and neither do your pair programming sessions.

The roles for pairing programmers don't change just because they're not in the same room. Neither do your goals. You’re still working on the same problems. You might be trying to write a tricky piece of code, or fix a broken test. Maybe it’s time to hop into a lengthy code review, side by side with the person who wrote it. Those goals don’t change. You're just not sitting in the same room as your teammate.

Good Pair Programming Sessions

Good pairing sessions—whether in person or remote—all start with a well-defined problem. You might need to fix a bug or design some new interaction layer. Your goal should be smaller than a Jira ticket. Pair programming shouldn't be an open-ended attempt to complete a task. Instead, you'll find that focusing on a specific outcome provides better results. When you're remote, you'll need to negotiate who's going to drive before you get started. That person will share their screen or a coding window. Next, you should walk through a quick display of where things stand. You don't want to dive in blind and work on the wrong thing.

From there, the real work begins. Often, you'll need to stop and think for just a moment. The navigator needs time to think about how to get from where the pair are to where they need to be. Then, the navigator provides a starting point and the pair are off to the races. Perhaps you need to outline some new data classes or define a function. The navigator shares what they're thinking at a high level, then the driver starts to type it out. During this time, the navigator should be paying close attention. Their job is to think about the details of what the driver is typing. Is the code clear and concise? Should you add a comment to document a decision? How will you test this work? The navigator makes suggestions to the driver about how to keep their code effective.

This process repeats itself for a little while. Like with all code development, the goal should be to define and refine, iteratively improving the code. Eventually, you'll finish the first part of your overall task. Often, that's a good time to switch roles. Pairing is a collaborative process, and each member brings benefits to the team. The code is better when each team member is flexing all their muscles.

Pairing Skills

Like all programming, pair programming is a skill. It often feels uncomfortable and awkward at first. The best way to get better is to practice. However, there are skills that you can hone on your own to get better at pair programming. Perhaps the most useful skill is thinking about the big picture when writing code. Good code is written not just to be executed, but to be read by people. The best code is automatically tested on a regular basis to prove its efficacy. When you practice writing clean, testable code, you get better at doing it. If you're writing code like that by yourself, it makes it easier to do so whether you're navigating or driving.

Another critical skill is effectively communicating your thoughts. If you're navigating and have an idea for a function, you want to describe it once. If you need to constantly talk through what you're suggesting to your driver, your velocity will plummet. Because programming is a social art, this is a skill that will serve you no matter what you're working on. Effective communication is especially critical for remote pair programming. When you're in person, you can point to the screen to easily identify something you want a driver or navigator to focus on. That's usually not true when you're working remotely. Instead, you need to effectively communicate your thoughts so that your partner grasps your meaning quickly.

Finally, good pair programmers should work on their mechanical skills. Things like typing quickly and accurately. Those aren't necessary for good pair programming, but they're a big help. If you're driving, typing the right thing the first time keeps your velocity up. If you type it quickly, that's even better.

Pair Programming Is an Investment

Whether you're in person or remote, pair programming pays dividends with better code that's written faster. There's friction when you're first starting, and it's a skill you need to invest in. It's not something people are born good at. What's more, tooling (especially in a remote setting) can feel like it's getting in the way. Understanding your tools is key to maximizing the return on your time investment.

At the minimum, you need a tool that allows for audio communication and screen sharing. Most companies meet this threshold easily these days. However, tools like CoScreen can take pairing sessions to the next level by offering an additional degree of interactivity. It simplifies things like switching between driver and navigator, breaking down the technical barriers that come with being remote.

When you invest time in pair programming, you'll find that your code comes out faster and better. What problems do you have that would be a good fit for pair programming?