Forem: CoScreen - Deep Collaboration for Engineers

What You Can Learn from How Successful Companies Use Pair Programming

Max Andaker — Fri, 27 Aug 2021 13:58:21 +0000

In 2012, Huffington Post breathlessly reported that Facebook was “making” employees share desks and computers.

The headline was clearly meant to catch the attention of non-technical readers, conjuring up images of employees huddling together at cramped workstations. Once the reader got past the click-bait headline, they were introduced to the concept of pair programming.

Ten years ago, pair programming might have been a novel concept outside Silicon Valley. But today, it’s well known in technology circles, as Facebook and many other technology companies were built on it. And they continue to use it.

Considering Pair Programming? You’re Not Alone

In the last decade or so, pair programming has come into vogue. So, if you’re considering making it part of your development process, you’re in good company.

Facebook is one of the most famous companies to use pair programming, but there are many other household names that employ the practice. Companies like Peloton, Stash, Grubhub, Snap, and Vimeo are all examples.

There are also many other technology companies that are not as well known outside technology circles that are big fans of pair programming. They include GitHub, Pivotal Labs, and Sparta Science.

“In a remote environment, pair programming is one of the best things you can use for two programmers!” - Jason Warner, CTO @ GitHub

There are countless unnamed startups that have made pair programming part of how they develop their products and solve their software engineering problems.

Pair programming’s cousin, mob programming, is also used by companies like Hunter Industries, though perhaps not to quite the extent that pair programming is used.

Whether it’s pair or mob, just because so many other companies use it, does that mean it’s right for you? To answer that question, you should look at how successful companies use it.

Pair Programming’s Pros and Cons

If and how you use pair programming depends in large part on your company’s maturity. As shown above, established companies have been quite successful in using pair programming. But it also has benefits for startups, with some proponents claiming that all startups should use it.

“CoScreen is probably the easiest way to do pair programming and dev collaboration that there is.” - Luis Capelo, Co-founder & CTO @ Grid AI

The most important reason is that pair programming helps define the company culture, as it can help establish a sense of teamwork and accountability, which are critical for young, fast-growing companies.

It boils down to the idea that software development is about people. It’s an endeavor that’s typically done best when people work together. No matter what detractors of pair programming say, it can’t be denied that it’s fundamentally rooted in teamwork.

Beyond culture, pair programming has other benefits for startups. Iyzico is a fintech startup that found that it helped them reduce risk by having more eyes on their code to catch bugs and errors. They also found that they were able to scale faster and better than they would have been able to with just one programmer working on a problem or a feature.

Iyzico offered a litany of other ways in which pair programming benefitted them, including testing, engineering orientation, and domain knowledge.

While there are many companies that use pair programming with great success, no one claims it’s a perfect solution. It has drawbacks that any company will have to weigh to determine if it’s best for them.

For instance, pair programming can be demanding on engineers. Having to work that way for hours on end can be draining.

But perhaps the biggest perceived drawback of pair programming is that it can be difficult for remote pairs. Many companies that relied on developers sitting side-by-side in pairs had that practice turned upside down in the pandemic-driven age of remote work.

In reality, pair programming might be even better suited to remote settings than in-person. In our Deep Collaboration podcast, GitHub CTO Jason Warner said he was not a big fan of in-person pair programming because office politics and almost religious adherence to pair programming were detrimental to productivity.

But his view changes in the case of remote environments. “I find it so incredibly helpful,” he said. “It literally is just two people batting ideas back and forth.”

The issue is that only a few companies offer tools that truly enable remote pair programming. CoScreen offers remote pair programmers solutions that’s almost like being next to one another and, in some ways, better.

“CoScreen is making remote better than in-person” - Sid Sijbrandi, CEO of GitLab

Going far beyond the capabilities of video conferencing tools like Zoom, CoScreen permits deep collaboration, allowing multiple teammates to simultaneously share screens, edit, and communicate from anywhere in the world.

How Successful Companies Use Pair Programming

While its use may be widespread, pair programming is not employed in the same fashion everywhere. The ways in which companies use pair programming are as varied as the companies themselves.

To give you an idea, we’ve highlighted a few companies that have shared how they approach pair programming.

Salesforce

Salesforce uses pair programming in its remote onboarding process because it helps experienced engineers teach relevant code to newer coders.

“Kevin Zhang is a Senior Software Engineer building mobile applications at Salesforce in San Francisco. ...His team has used CoScreen to simplify and streamline the remote onboarding process using formal and informal pair programming and other best practices...” - How to onboard new remote engineers with 30% less friction using CoScreen

Square

Square is a San Francisco-based financial services and digital payments company that was founded in 2009. They famously created the square reader that you attach to your phone’s jack, and it accepts credit card payments.

“We do a fair amount of pairing at Square... The rule we follow is that every piece of code going to production has to be seen by at least two engineers. Pairing is one way to comply, code review pre-merge is another. If you like pairing, Square is a great environment for it.” -Zach Brock, a former employee at Square

He added that pair programming is so important to their organization that they will often engage job candidates in pairs as part of the hiring process.

Pivotal

Pivotal Labs are legendary for their use of pair programming. This company builds software with their clients. They have based their principles HEAVILY on the use of a “unique services methodology called paired programming”.

Joe Moore, their Principal Engineering Manager, did a whole presentation over paired programming called I've Pair Programmed for 30,000 Hours: Ask Me Anything!

Wells Fargo

Everybody knows Wells Fargo. It’s a banking company and the largest mortgage and auto lender in the United States. Why would a banking company need pair programming? Because they do programming within the company. Jasmine Adamson, one of their programmers and web developers stated, “We're not your average 'tech firm' but we're doing some of the same things. We typically have many beginners on staff and pairing them up with experts gets them up to speed more quickly and allows us to control code quality a little better. Personally, I don't like it. I love teaching, but I don't like the company paying for it.”

Microsoft

Microsoft is about as successful of a company as you can find. It’s a fortune 500 company, which has been featured (many times) in Forbes. It develops, manufactures, supports, and sells computer software. They make electronics, personal computers, anything tech-related, you name it, they’ve done it, so it’s not shocking that they use pair programming.

“We find from the results of a survey sent to a randomly selected 10% of engineers at Microsoft that 22% pair program or have pair programmed in the past. Using qualitative analysis, we performed a large-scale card sort to group the various benefits and problems of pair programming. The biggest perceived benefits of pair programming were the introduction of fewer bugs, spreading code understanding, and producing overall higher quality code. The top problems were cost-efficiency, (work time) scheduling problems, and personality conflicts. Most engineers preferred a partner who had complementary skills to their own, who was flexible, and had good communication skills.” -Pair programming: what’s in it for me?

Is Pair Programming Right for You?

Pair programming is not a magic bullet that will allow companies to build better products and serve users better. It’s simply a handy tool that’s available for developers to use as their needs dictate.

Like any tool, it has strengths and weaknesses. Some people use it more effectively than others. And it can’t do everything.

Is it the right tool for your organization? That’s for you to determine. But if you can make pair programming fit in your organization as the other companies mentioned above have, pair programming can help you do great things.

Looking for you next pair programming tool?

“CoScreen is probably the easiest way to do pair programming and dev collaboration that there is.”

Luis Capelo, Co-founder & CTO @ Grid AI

Try CoScreen for free

Keyboards: Here there be Dragons

Jason Thomas — Fri, 20 Aug 2021 15:02:08 +0000

Here at CoScreen from the very beginning our goal has been to bring multi-user remote collaboration into the modern age. Multi-user operating systems have been a thing for some time, and collaboration has been possible in various aspects for decades via various terminal-based tricks and tools. **Then Xerox PARC came along and popularized GUIs: and those too believe it or not were originally imagined to also be potentially multi-user and collaborative. Still, somewhere along the way, something was lost. Computers became personal computers, and the world of multi-user collaboration fell to the fringes of time and history.

Windows was originally built on DOS, which by its nature was never even multi-user, and then jury-rigged onto NT (which was) to preserve in function many of these classic aspects, only to adopt a sane security and permissions model. OSX was built in part on FreeBSD (Unix), and inherited all of the multi-user checkboxes, but made little use of them, building a windowing system very much designed for only one user, one window, and one mouse.

Videoconferencing on NLS (1968)

Douglas Engelbart’s “Mother of All Demos” demonstrated many of the aspects of modern computing we have all come to take for granted. Windows, hypertext, graphics, video conferencing, a computer mouse; and the somewhat forgotten but not lost real-time collaborative editing. Much of what separated Engelbart from his colleagues that would go on to found Xerox-PARC, and define user interfaces for decades to come, was that “[Engelbart saw the future in collaborative, networked, timeshare (client-server) computers, which younger programmers rejected in favor of the personal computer.]”(https://en.wikipedia.org/wiki/Douglas_Engelbart)

Our ultimate goal is for CoScreen to fade into the background and just become part of the underlying operating system, unobtrusively making your computer remotely collaborative. It turns out modern operating systems have deviated so far from the concepts imagined originally that they resist collaborative use.

While on the road to this dream, we have encountered and defeated many exciting and challenging problems. Some of these problems have nearly defeated us or sent some of our engineers onto the very edge of their sanity, especially those problems that haven’t been the problems we expected to encounter.

Keyboards, international layouts, and their complexities are one of these problems. As an engineer, you would probably expect that most of the problems dealing with international keyboards and remote control have long been solved decades ago in VNC, RDP, or in commercial remote control solutions like NX, TeamViewer, and the like. Surprisingly even after decades, technologies like RDP still often involve a lot of individual configuration, tweaking of settings, and several unexpected issues regarding the use of international keyboards. All of this individual configuration, keyboard layout files, and complexities, will immediately burst the bubble of almost any person using an international keyboard with a mismatched remote system.

CoScreen’s intent regarding how a user’s keyboard interacts with a shared window is simple — do what the user wants us to do. At times this means rendering a particular character into the shared window, while other times, this means delivering an exact key sequence to the target application.

This goal is simple to understand and state; however, like all things behave intuitively with respect to users in the realm of computation, the complexities of achieving it are not.

Thanks: u/jch2617 → r/ProgrammerHumor

Terms

To make sense of what we are talking about moving forward, a number of technical terms need to be understood:

Dead Key: A special key used to attach a diacritic to a character.
Input Method Editor: An OS component used to generate characters that are not on the input device [2].
Logical Layout: A virtual mapping of characters applied over, and superseding, the physical layout. For example: choosing Dvorak as the Input Source on MacOSX.
Local layout: The local logical layout that is active
Local user: The user who is sharing an application
Physical Layout: The physical arrangement of keys on a keyboard. This is technically a composite of the form factor and layout of the keys — e.g. Full / ANSI [3].
Remote user: The user with whom the content is shared and is the one delivering the keys.
Remote layout: The logical layout of the remote user
RemoteWindow: The name of the object that represents a shared window in CoScreen.

The matrix of possibilities regarding input methods from various users in a CoScreen is pretty mind-boggling. To simplify, we have focussed on several key confounding factors, which are as follows:

A remote and local user may have a different logical layout applied to a physical layout.
A user may be entering a key sequence, symbol, or emoji, that relies on Input Method Editors (https://en.wikipedia.org/wiki/Input_method) and “Dead” keys.
An application may override behavior for an OS. Emacs, for example, uses the Option key on macOS differently from other applications. In Emacs, the Option sequence is processed, rather than the special character that is injected when an Option sequence is pressed — Option + f renders the character ƒ, while in Emacs this triggers the command to move forward a word.
The shifted characters may not align between logical layouts. For example, much of the shifted keyspace in a German layout matches US, but the 7 key translates to / when shifted.

CoScreen’s Solution

We experimented with a wide variety of different solutions. Our original approach used the underlying keycode, and in our native layer, we attempted to translate and map those codes via a more traditional VNC or RDP-like approach. We could write an entire article just on the subject of event simulation and injection on Win32 and OSX, which was our original primary engineering focus.

The result was input that worked pretty well with a standard keyboard, by interpreting and transmitting most international characters as Unicode. Still, it would fall on its face by misinterpreting some control sequences like in the Emacs example given above and didn’t work at all with IMEs.

Now on to what did work: When possible, key processing is kept common across platforms. However, this only works to a point because the operating systems differ in their key injection handling and facilities.

CoScreen renders and composites all shared windows to natively managed hardware-accelerated surfaces using a specialized video stream containing content to display, and metadata about where and how to display it.

But CoScreen is also an Electron-based application and uses Electron Windows in order to leverage the flexibility and speed of modern web-application based programming. It does this by reaching into the native windows and attaching our own native surfaces to them, but underneath our hijacked native rendering surface is an Electron BrowserWindow, and we leverage it for event input. By standing on the shoulders of giants in terms of leveraging the event input work of the Chromium browser, we can generate a much better general input strategy, without compromising performance.

All user key input events are intercepted by a hidden element in our Window. Most actions (click, key, etc) focus the input element to ensure it processes all keys (there is a known issue as of 6/13 on Windows where the window must be re-focused).

The following events are critical for key input processing:

keydown
keyup
beforeinput
compositionstart
compositionend

To fit into the current architecture, keyup and keydown events are synthesized for compositions and are sent one Unicode character at a time. If an event is the result of a composition, a new flag isComposed is sent with the key payload.

keydown

When a keydown is received, it is not necessarily clear whether this is a keystroke that can be forwarded or whether it starts a composition because the isComposing parameter will generally be false for the first keystroke in a composition. Depending on the value of the key field, one of three actions will be taken:

Do nothing: This will be done if the key is one of the reserved IME key strings.
Immediately forward to the window: This is true for control keys (detected with length > 1), keys where repeat is true, and keys where ctrlKey or metaKey are true.
Cache: All other keys.

beforeinput

This event is sent before the input is ready on the input element. If the isComposing flag is true, the last cached keydown event is discarded because the composition has started. If the flag is false, the last keydown event is popped from the queue and sent to the Window.

keyup

This event represents a key being raised. If the isComposing flag is true then no action is taken. If the flag is false, and there is a completed composition is in the queue, a keyup is synthesized and sent to the Window. If no composition is present the event is sent unaltered.

compositionstart

This event represents the start of IME composition. All existing keydown events are cleared.

compositionend

This event represents the end of composition. A keydown event is synthesized from the result of the composition and sent to the Window. The result of the composition is queued to be sent when the last keyup occurs.

Post Window Processing

The following flow diagram represents the processing common to both operating systems after the above IME processing.

Remote user

The resultant key up/down payloads are forwarded to the RemoteWindow instance responsible for the shared window.
If the platform is macOS, and ALT is down, the un-altered key is obtained so that it can be used for translation by the receiver. The reason for this is that macOS exposes a new keymap when Option (Alt) is down. In that case f (on a US keyboard) becomes ƒ. Unfortunately, no keyboard has this natively, which causes our lookups to fail. Normally, we’d deliver the character, but for applications like Emacs, we need to deliver the key sequence with the un-altered character to achieve the desired effect (move forward a word in the case of Alt-f).
Send the key payload to the local user.

Local user

Determine if the incoming key is a dropped key (which can vary by operating system. We drop keys for which we don’t have a translation strategy today)
Determine if the target is Emacs and apply the app specific policy (ignore the modified key if Alt is down and use the unaltered key).
Forward to platform specific native processing.

Windows

All windows processing takes place in the native layer. With Windows, one can either inject a virtual key up/down, or submit a unicode character. The latter will not take the place of keystrokes for applications (e.g. vim’s gg) and cannot be used generically, though this was desired and tried.

The flow is:

If the isComposed flag is true, inject a unicode character.
If the key is a non-character, inject the virtual key based on the code field.
If the key can be mapped to the local key layout, inject this key.
If no character in the local keymap exists, but Ctrl or Alt are down, inject the virtual key from the key code.
Inject a unicode character.

In each case, because windows is stateful, a cleanup task is queued for 500ms later. This task will inject a keydown for the previous keyup if none were sent. Failure to do this will result in “stuck” keys.

macOS

macOS specific processing has components in the JS and native layer.

In the JS layer, the native-keymap is used to look up the virtual key code in the local keymap corresponding to the code sent by the remote user. This is how we properly handle translations from Dvorak to non-Dvorak. If found, this code value is used instead.

The native layer looks up the generic key code from the macOS headers and sends an event to the input system. If the isComposed flag is true, -1 is used for the code.

Note: This area is a bit strange, and was the result of some trial and error. In particular, failure to send -1 with a chinese character (for example) will cause the input to render the character equivalent to the specified code.

Keyboard Events

Keyboard events have several fields, the following of which are used by CoScreen:

key - The character string sent by this keypress. This will reflect the logical keymap.
code - A string representing the key on a physical QWERTY layout keyboard. This means that any other layouts will not be taken into account. In general reliance on this field is problematic for us, but we do use it to look up key codes in some capacity.

In summary, making use of the amazing work done by the Chromium team is an enormous shortcut, but is by no means simple as this article has demonstrated. We still have much to learn regarding remote control, and input, and with international customers onboarding, and combined international teams becoming the norm, we hope to become a tool that makes the experience of working with your CoWorkers remotely just work, regardless of where they come from, or what tools they use. We hope to one day be able to make as close of a semblance to the collaborative, networked, computation environment, envisioned by early pioneers in the field, as possible.

References
https://en.wikipedia.org/wiki/Dead_key A dead key is a,the key struck immediately after.
https://en.wikipedia.org/wiki/Input_method
https://blog.wooting.nl/the-ultimate-guide-to-keyboard-layouts-and-form-factors/
https://www.w3.org/TR/ime-api/#introduction

The Developer’s Guide to Remote Debugging

Jason Thomas — Wed, 30 Jun 2021 16:28:37 +0000

What’s more aggravating than debugging a system? Doing it remotely. It’s aggravating because not only are you frustrated that your code isn’t doing what it’s supposed to do, but now you have to figure out how to get someone to help you check out your code. In addition, you’ve exhausted all resources, and you have no idea what you’re doing wrong.

Unlike other remote communication tools, CoScreen makes remote debugging easier. It allows you to communicate with your fellow developers and share multiple windows to find your bugs and broken pieces of code faster. Without CoScreen, you’re likely losing valuable time discussing what’s wrong (if you’re even able to describe the bug correctly) instead of physically seeing the problem and being able to fix it together on the spot.

How do you debug remotely?

Let’s say you’re a developer and you’re working remotely—most likely due to the COVID-19 pandemic, your team has transitioned to a remote or hybrid work model. You’re coding, and, inevitably, your code doesn’t do what you want it to do. The error is impossible to find, and you’re getting frustrated.

First, you’ll try a few solo debugging avenues.

An example of a solo debugging adventure

Let’s say you are doing remote debugging, and you find a bug in your code that isn’t saving the user data as it should in an app. This means you should spend some time manually looking through the code on your computer, reading the files that contain the code responsible for saving user data.

If that fails, then start to debug your code. Depending on where the bug is (front end or back end), the debugging will look different (and, at this stage, you may not know if it’s a front- or a back-end problem).

At this point, use a debugger (especially if it’s in the front end). If it’s in the back end, use logging to log values at points in the code. If that doesn’t work, go to Stack Overflow, GitHub, or Google to see if someone else is having (or has had) this issue.

Once you’ve exhausted all of your solo debugging avenues, it would help if you had a second pair of eyes to help you find the bug.

You have a few options:

Get a hold of one or multiple teammates—preferably someone who is also familiar with the code. This is an opportunity to do pair programming or mobbing.

Download a video conferencing tool to work through the problem. (This means you’ll have to find the right tool to get the job done; more on that below.)
Try talking through the issues.
Generally, if you can explain the problem in enough detail to understand it, this act alone may help you find a solution. Sometimes, it helps if you take a moment to step back and see it from a different perspective to find the errors you couldn’t see before.
Show the code to a teammate. Compare code if you’re working on it together. Maybe they can see what you can’t. Switching roles can help: let your teammate take a look at it as if they wrote the code.
Take a really close look at your code. Sometimes, with the backlighting, you may not notice a missing semicolon, or you may have forgotten to close a brace.
When all else fails, try posting your code on Stack Overflow—the developer community may be able to help.
Finally, if that doesn’t work, try “filing an issue” with the framework (React, Laravel, Rails, etc.), as it’s likely not an issue with the code but with the framework.

The current issues with remote debugging

The problem is a lot of the current communication platforms are not built for developers and don’t allow to show and compare code while they’re also talking to each other. You’ll have to pick and choose what features you’ll be able to have, like the ability to chat with each other, share screens, or show multiple screens at the same time.

Sometimes, the only thing you can do is download the platforms and try each one out to see which one works for you. (Spoiler alert: you can read to the end of the article, and we can tell you what the best platform to use is and why.)

Sometimes video conferencing tools just add to the problem. Most video conferencing software creates more issues rather than making remote debugging easier for developers. There are plenty of existing tools that offer a few features to help devs communicate.

One size does not fit all: Typical video conferencing tools

Zoom, Facetime, Google Duo, and Skype allows you to do voice and video calling along with chat messaging. They don’t let you share multiple windows simultaneously for a side-by-side comparison. Zoom offers screen sharing (unlike the others), but two users can’t both share windows on a joint desktop at the same time.

These big-name platforms aren’t suitable for programmers or developers because they lack side-by-side window sharing and editing, which enable you to make changes to your code quickly and efficiently. This side-by-side comparison and remote control is really what makes remote debugging possible.

Some Apps Don’t allow you to share multiple screens

Most developers aren’t going to use the following apps because they don’t allow developers to share monitors to compare code. If you want to make a change to another developer’s code, you’ll have to explain your code and where to look to find the issue without the ability to see multiple monitors at the same time.

[WhatsApp[(https://www.whatsapp.com/) is similar to Facebook Messenger in the sense that you can do voice and video calling and chat messaging, but it’s more like what you’d use to call your mom and dad. A cool feature with WhatsApp is you can also leave a voice message, so there’s no rush for someone to get back to you, and you don’t have to sync up if you’re in different time zones.

Discord is also like WhatsApp and Facebook Messenger, but it’s for gamers. It’s integrated with supported games, like Halo, so that you can talk to a different kind of teammate. ;) Most developers aren’t going to use this for anything other than gaming, though.

Slack is the approach that most co-workers use. It integrates some of your other communication tools, like Zoom and Google Calendar. It allows users to communicate with each other by chatting, scheduling meetings, and doing one-on-one video/voice calls.

VS Code Live Share is the product that’s going to be the most similar to CoScreen. It’s typically what most developers use to share code, and it’s a real-time code collaboration tool. It’s basically an extension in VS Code, meaning you need a Microsoft account or a GitHub account to use it. It has a multi-user remote control feature, like CoScreen, but with limited capabilities. The other downside is it doesn’t integrate with a lot of tools.

Duckly, formerly known as GitDuck, is also a great real-time code collaboration tool, but it connects directly from your IDE (integrated development environment), which is not necessary with CoScreen. When you use CoScreen, you don’t need to connect to anything additional in order to do coding, which is a big advantage for CoScreen. Duckly allows you to share your code and terminal in a video call. With CoScreen however, you can share your code without sharing your whole screen.

Some apps don’t allow Full Multi-User Remote Control

Microsoft Teams is what teams use to communicate. Usually, you use Teams if Microsoft is what’s commonly used at your office. It doesn’t make sense to use Microsoft Teams unless you’re using other Microsoft products, so they are all compatible with each other.

Let's say you’re doing remote debugging with another developer on Microsoft Teams. You have your code up on your screen, and, as you're comparing each other's code, you see a bug in their code on their screen. You now have to physically tell them where the bug is so they can make the appropriate change to the code. You can't physically go in and make the change yourself because you don't have the ability to control or edit their screen.

How CoScreen helps you find bugs faster

There's a solution out there that offers many of the same features as some of the video conferencing tools previously mentioned, but it also solves additional problems with remote debugging that those tools don't address.

CoScreen was built for developers by developers, which gives you the edge you need to code more efficiently and remote debug easily. CoScreen allows multiple users to share multiple windows at the same time.

CoScreen shares individual windows but not the entire desktop, so users don’t have to sacrifice their privacy. It even has this cute little tag at the corners of the windows, so you can see exactly what you’re showing in your tab before you show it!

A stellar feature of CoScreen is that it enables you and your team members to share, edit and control any app windows simultaneously on your joint workspace. This means that your teammate can physically go into your code (through a window you shared) and make changes to your code. CoScreen users can edit each other’s shared windows as if they were their own.

Beyond debugging: Other use cases for CoScreen

CoScreen is a unique and versatile tool for developers to use, and you can use it in several ways other than to squash bugs in your code. If you’re trying to teach someone some part of the code, CoScreen is an amazing teaching tool because it gives you the opportunity to pull up their code alongside your own while you’re talking them through what to do.

Alternatively, another use when helping a new developer—you can pair programming with them on CoScreen. Sometimes, when onboarding a new developer, companies pair them with an experienced developer so the experienced developer can teach the newer developer and pass on their skill set. They might also try to do a little remote debugging together.

CoScreen does everything except squash the bugs for you

The potential to increase the productivity of remote debugging with CoScreen is massive.

Try CoScreen for free!

Even a 10X Engineer Works Best in a Team

Jason Thomas — Wed, 30 Jun 2021 14:13:49 +0000

There’s a tired cliché about the stereotypical, high-performing “lone” software engineer. Isolated from the rest of the organization, cranking out line after line of code with ungodly speed and accuracy due to their savant software development skills.

Also known as the “10X Engineer,” these mythical beings are thought to be capable of changing the world without breaking a sweat. Ultra-talented, ultra-productive developers who write impeccable code the way Mozart wrote symphonies.

This mythical status has driven companies and startups the world over to pursue them relentlessly. When they do manage to snag one, conventional wisdom dictates that it’s best to leave them alone and wait for the magic to happen.

But that kind of thinking may be harmful. In this article, we’ll examine the phenomenon of the genius programmer, why it may not be a good idea to have them work exclusively alone, and how companies can maximize the abilities of talented programmers.

The Legend of the 10X Engineer Who Only Works Alone

Some have claimed that the popular notion of the 10X engineer — the introverted, antisocial genius who can single-handedly make your business succeed — is deeply flawed.

Having a smart, productive engineer on your team isn’t worth the hit your team dynamics can take if this person refuses to fit in or work with others. There are other smart, productive engineers out there who will benefit the team as a whole, and those are far more worth having. - The “10X Engineer” Has Officially Become a Meme

It leads startups to pursue hiring people they think are 10X engineers and then treat them as untouchable gods of coding. A host of organizational problems follows, including toxic work relationships, poor communication, and unhealthy work environments.

Often their productivity is driven partly by their own high expectations of themselves. A 10X developer may push themselves out of loyalty to a company or an idea to hit unrealistic goals. These types of developers suffer heavily from burnout, particularly when expectations are set on that level of productivity being constant and permanent.

Everyone can agree that there are exceptional, talented programmers among us (we think we have more than our fair share at CoScreen). In fact, the idea that they are 10 times faster, better, or more productive than their peers is based in reality.

Researchers found that the most skilled programmers perform at rates 10 times better (or more) than their least-skilled counterparts, depending on the task. Notably, however, those “rock stars” outperformed the average developer by only a factor of two or three.

The desire for startups to recruit high-performing developers is not misguided. Where many companies go off the rails is in eschewing the foundations of effective teams and collaboration in favor of letting their prized programmers work in isolation, because they think that’s how it’s done.

But that is not the right path. Placing engineers in a sole programmer role can, in fact, be dangerous and detrimental to the organization and to the programmers themselves.

But working on a software project all by yourself, instead of being empowering, is paradoxically debilitating. It's a shifting mirage that offers the tantalizing promise of relief, while somehow leaving you thirstier and weaker than you started. - In Programming, One Is The Loneliest Number

Why is there this disparity in organizations? Are the highly productive lone developers somehow making their peers less productive? The truth is that organizations that rely too heavily on their “rockstar” engineers ultimately do a disservice to those very same engineers, their peers, and the organization itself.

For the organization, the lone-programmer approach can be inefficient. It often cultivates a lax approach to process, if there is any process at all. Often, there is little or no accountability for code quality, errors, and standards, but only to near-term timelines. Organizations obsessed with individual driven productivity trade long-term costs for short-term gains.

If a company’s institutional knowledge resides in the head of just one individual, they can find themselves in deep trouble when that person leaves and nobody knows exactly how things work. Or, peers start to over-rely on 10X Engineers for almost everything, then are demoralized when they’re not given responsibility that’s critical to the company.

Companies can try to avoid these issues by having rigid processes, extensive specifications, and project plans. But those guideposts add administrative layers that tend to also hamper the effectiveness of the developers, as well as produce operational headaches.

Working in isolation isn’t always what’s best for the programmer, either. For the engineer flying solo on a project, everything is on them. They don’t have anyone else to serve as a sounding board to help them work through obstacles or come up with new approaches to challenging problems. There’s no one to cover for them when they’re out sick or on vacation.

Plus, the more heroic hours engineers work to “carry” their teams, the less productive they become. (Source)

Despite their reputations as lone geniuses, solo rockstar developers typically don’t want this kind of pressure. They don’t want to be the sole person everyone comes to in order to solve every problem. Being part of a team is critical to allowing developers to take vacations and avoid burnout.

That’s not to say that there aren’t upsides to lone programmers. They can help companies avoid groupthink. They can also build more cohesive components with less complexity where they are interfaced together.

And, to be sure, there is often an allure of working alone. Developers can often work faster, and for certain tasks and projects, it simply makes more sense.

But even for the most talented engineers, getting the best work out of them has as much to do with the organization that surrounds them as it does with their own capabilities.

What Really Makes a Great Programmer?

The 10X engineer archetype places technical capabilities above all else. It holds that their savant-like ability to make code bend to their will trumps any and all other skills that might be necessary for them to function in a normal work environment.

But it turns out that great programmers are great not just because of their technical skills but also because of their “softer” skills. Having an engineering mindset — and simply being a good co-worker and person — includes traits like curiosity, open-mindedness, communication, teamwork, and learning from failure.

(Source)

Great engineers are also knowledgeable about other people in their organizations and have a shared context and a shared identity. They are not afraid to rely on and value the help of other team members to drive everyone toward a common goal.

Very often, it seems, what makes a great programmer is other programmers, and a functioning, working, institution behind them. One that includes seeks to distribute their load among product managers, project managers and designers.

Fostering Shared Context and Collaboration

The legend of the lone programmer who can’t be bothered with the trivialities of other people simply isn’t compatible with a high-functioning team, nor with a high-functioning programmer in the long term.

Great teams, with great developers, value different voices, ideas, and perspectives. Teammates build on each other’s ideas, leading to innovation and creativity. They work together to try different approaches to learn what works and what doesn’t.

So how do you get there? How do companies create the kind of team dynamic that helps create great programmers and effective teams? There are two distinct yet related approaches that have garnered a lot of attention recently: shared context and collaboration.

The idea behind shared context is to orient the team, or the entire organization, around a mutual understanding of the work they’re doing, the customer they’re trying to serve, and each other. In short, it’s helping the team see and embrace the big picture.

Collectivism, a close cousin to shared context, is an approach organizations can use to draw on the combined wisdom and experience of the team to drive innovation. It’s an approach that values input from multiple voices so that different perspectives, possibilities, and ideas are given proper consideration.

Following these philosophies not only helps companies get the most out of their engineers (10X or otherwise), but it also offers a litany of benefits to the company:

Helps to create a sense of trust and open communication among the team, a key characteristic of any healthy team
Reduces the need for extensive, overbearing administrative guardrails to govern sole programmers’ processes, slowing them down at the same time
Eliminates frustrations and errors caused by team members not understanding each other
Helps create better products through stronger code and meaningful contributions from more people
Reduces multiplication of code where the fundamental logic might be unnecessarily processed in several places

In addition, collaboration and shared context are critical for organizations with geographically distributed teams. To a certain degree, they happen almost naturally to teams that share a physical workspace. But in times of remote work and teams spread around the globe, companies have to be intentional about making those things happen.

Examples of channels for building shared context. (Source)

It may sound simplistic, but the key factor in building both is communication. Sharing information, whether through formal communication tools, processes, and interactions or through informal interactions, allows the free exchange of ideas between individuals and teams. Even seemingly trivial interactions, like small talk and after-work gatherings, help to create a sense of team and esprit de corps that build a stronger team over time.

It’s important to recognize, however, that it’s a process that’s never done. Team dynamics are always changing as people grow in their jobs, others leave, and new hires come on board.

It’s also not an all-or-nothing proposition, where individual work is completely disregarded. When you have supremely talented and productive engineers on staff, the last thing you want to do is go overboard with meetings and processes. They’ll only get frustrated.

There is a time and a place for programmers to go off and work alone. For example, while collaboration is important for generating creativity, it also tends to be slower. Many companies have found that the best approach is a mixed one, favoring a synchronous, team effort when tasks are complex and nuanced, but turning engineers loose when speed is critical.

One of the best ways to not disrupt an engineer’s productivity is by reducing unnecessarily long meetings, which requires scheduling a time, inviting people, and determining who will present.

CoScreen lets you avoid that hassle by allowing developer teams to share context on-demand. When a developer wants to share information, they just need to invite people to a CoScreen and start sharing. Or they can ask a question and someone they invited can start sharing to offer an answer.

This reduced the need for traditional, cumbersome meetings in favor of short, concise, focused sessions that are scheduled on-demand.

One Company’s Approach

In a Wing Remote Stack Summit, Zapier CEO Wade Foster talked about his company’s approach to fostering a strong team dynamic, despite being 100% remote. He said they are very intentional about building a shared understanding among employees and foster a balanced approach between working alone and in teams.

“We try to make sure our teams are scheduling time to catch up with each other.”

He also cited using communication tools, like chats during video calls and Slack channels that allow employees to discuss non work-related topics.

“They can just talk about shared interests,” he said. “It recreates the water-cooler dynamic.”

When it comes time for their developers to put their heads down and get to writing code, whether they work in teams or alone, depends on the task at hand.

“We default to (the asynchronous approach) but recognize when synchronous needs to happen,” Foster said. “It’s at those moments … when it’s a meaty topic, and there’s nuance, and it’s not going to be straightforward.”

Lone Developers Have Their Place

Western culture tends to value the contributions of one over that of the group. The lonesome cowboy, the knight in shining armor, the superhero. The genius programmer.

There is a time and a place for the undeniably great contributions of these individuals. But there needs to be a balance. Lone Developers need not be lonely anymore.

They can still have their productivity and focused, in-the-zone time. But at the same time, with the right tools, they can make other developers, and their organization, better.

Establishing a shared context and collaborative approach with free-flowing information and a healthy team dynamic serves to amplify the abilities of your top-performing engineers. When you can balance the approach to teamwork and individual effort, you’ll have a strong team that can be fast and nimble when it needs to be, while building great products over the long term.

Love It or Hate It, Pair Programming Is Here to Stay. Here’s How You Can Live with It.

Jason Thomas — Wed, 30 Jun 2021 14:11:58 +0000

We all remember the word problems from middle-school math:

If Jane can paint the fence in two hours, and Bill can paint it in three, how long would it take the two of them to paint the fence if they worked together?

Imagine that same word problem, except instead of
painting a fence, Jane and Bill were software engineers.

If Jane can write 20 lines of code in one hour, and Bill can write it in two, how long would it take them to complete the task if they worked together … on one computer?

The scenario described above has a name. It’s called pair programming. And many engineers would have a NSFW answer to the question and tell you why pair programming is bad.

Pair programming, an idea that’s gained traction in recent years, tends to inspire strong opinions one way or another. Companies and organizations love it. Many engineers hate it. No matter which side you’re on, it’s not going away. But it is possible to make everyone happy with the right approach.

Pair Programming: Reasons to Hate It

Before we go any further, a quick review for anyone who’s unfamiliar with the concept. Pair programming is a methodology in which two people work together on a single programming task. In most scenarios, the pair works on a single machine, with a “driver” and a navigator dividing tasks — entering code, observing to prevent bugs while discussing structure, style, and functionality.

(Source)

Companies that adopt pair programming have cited several benefits, including a shared project experience and ownership among developers, better understanding of project goals, effective collaboration, and happier employees. Some companies skip administrative processes like code reviews because the shared context is implicitly established and approved during the programming sessions.

A lot of people love pair programming and write emphatically about its benefits. But it’s not a universal love, as many engineers will tell you why pair programming is bad. Some will tell you they hate it.

Hate. It.

For a lot of engineers, programming is all about getting “into the flow.” It’s a euphoric state when everything is just coming together, and they’re able to work for hours on end, churning out high-quality code. Other developers see programming as a process of quiet reflection, trial and error, one-on-one with a problem, slowly building to a solution.

Pair programming interrupts that flow, or worse, prevents it from happening. It often follows a rigid schedule, dictating programming sessions at certain times, even if the developer isn’t in the right mindset. Some people simply work better on their own terms, when inspiration strikes.

On its face, pair programming is essentially two people doing one job. Some engineers say that only serves to destroy productivity, slowing the development process down. This can be especially harmful for startups that need speed above all else.

Another pair programming complaint is that it requires a rare, perfect match of two individuals. Such pairings are elusive because people are inherently different, with varying strengths and approaches to work that clash with others more often than not.

Finally, there’s the introversion problem. The introverted software engineer is a bit of a cliché, but there is some truth to it. As much as 40% of the population are introverts, and those people are drawn to jobs that involve independence, like programming.

For those people, working in pairs, talking to someone for six hours a day, can be mentally and physically taxing. For introverts, pair programming may be a “personal hell.” Research also suggests that the part of the brain used for speech is also used for programming. Engaging it constantly, switching between spoken language and coding language, can also be exhausting.

Pair Programming: Reasons to Love It

Despite the negative rep pair programming can have, there are some legitimate arguments to be made in favor of pair programming. It can make the code better, the employees happier, and the organizations more successful.

It may seem counterintuitive, but two people working on the same code can actually be more productive than if they worked separately. The productivity gains come not in the form of faster coding but by way of fewer errors and bugs, making review and refactoring faster or possibly redundant.

In addition, sometimes two people come up with better, more creative solutions by working together. By sharing ideas and discussing them out loud, pairs can get through obstacles and challenges quickly. A lone programmer can get stuck in a rut, stewing on a problem with no solution in sight, sapping productivity.

Interestingly, the productivity gains of pair programming continue when the two members are apart, working on their own between sessions. The energy and ideas generated during pair programming sessions have a lasting effect.

Pair programming also has some real upsides for employees, especially for junior-level developers. It encourages employees to share knowledge, so new hires and younger developers learn and grow their skills faster. This is immensely satisfying to junior developers whose confidence and passion for the work blossoms quickly. There’s a reciprocal benefit to senior developers, too, as their passion and focus get sharpened in the process.

Believe it or not, some developers find pair programming to be just plain fun. There’s a certain joy in working on a project as a team.

All of that adds up to some real tangible benefits for organizations. It results in faster, more efficient onboarding of new hires. It makes companies less reliant on individual “towers of knowledge,” and less vulnerable when they leave. It creates happier employees, who write better, cleaner code, resulting in better products and happier users.

From the organization’s standpoint, what’s not to love about pair programming?

Making Pair Programming Work

Pair programming doesn’t seem as if it will be going away anytime soon, and there are good reasons for your organization to implement it. But it’s not a plug-and-play solution, and you might face some resistance from developers telling you why pair programming is bad.

So here are some strategies you can use to make it work for your company and have your engineers enjoy it. Or at least tolerate it.

Understand it’s not one-size-fits-all

As good as it is, pair programming is not right for every task, every project, every time. It’s critical to know when to use it and when to go another way. That will depend on your organization, your people, and your projects.

You can start by trying pair programming on specific stories or tasks that would benefit from collaboration. If it touches a core feature, or presents a specific, difficult challenge, you might consider assigning it to a pair programming team. Conversely, tasks that are simple or time-sensitive might be best left to a solo programmer to just get it done.

However you implement it, be sure to let your teams evaluate the experience afterward to understand what worked, what didn’t, and why. Then, apply that knowledge the next time you consider pair programming.

Try different techniques

Pair programming isn’t just one thing. There are actually different types or versions of it, and the right for your organization, again, depends on your situation.
Truly collaborative pairing, like through CoScreen, allows you to have multiple drivers, and to switch between driver and navigator rapidly while letting users observe and continue doing other work on the side. Having the driver and navigator switch roles every so often can keep both engaged in the process. You can also use ping-pong pairing, in which the team follows a loop of writing, passing, and refactoring sections of code.

There are other techniques you can explore. The right technique depends on the task, but it might also be best left to the pair themselves to determine how they work best.

Follow general etiquette

The main thing to remember with pair programming, as with all personnel matters, is that you’re dealing with human beings. You should be sensitive to that, ensuring that the people you pair together won’t be at each other’s throats the first day.

Encourage pairs to be patient and empathetic toward each other. Create a dedicated area to document your company’s values, the purpose of pairing, and appeal to common courtesy. They should be open to trying one another’s ideas and able to explain and document their decisions. Be aware of your programmers’ personality types and how well they get along with others, and take that into consideration as you build your teams.

You can also pair people according to their seniority and experience to find the right fit for a project. Combining two senior programmers might be best for challenging, high-priority tasks, while a senior/junior combination helps with onboarding and development. Even junior/junior combinations can be beneficial in certain situations.

Finally, pair programming teams should use common sense to maintain effectiveness. Switching roles frequently and taking well-timed breaks helps keep them fresh and gives their mind a break.

Why Pair Programming Is Bad: It’s Best in Moderation

Pair programming can be an effective approach for your organization, even in an era of remote working. It will take some trial and error, and potentially overcoming time zone differences. But if you don’t overdo it, and you use it in the right situations for the right people and can get your teams to embrace it, you can make it work for, and provide benefits to your organization.

How to Use Zoom Screen Sharing for Engineering Collaboration

Till Pieper — Wed, 09 Jun 2021 20:06:58 +0000

Imagine what would have happened if the pandemic occurred just five years earlier, and software development teams, along with everyone else, had been forced to work remotely.

Videoconferencing and screen-sharing virtual meeting tools were brand new. At best, they were still quite rough. Even fewer homes had high-speed internet access than today. The only reliable way to collaborate with colleagues was to blindly discuss work through email and (gasp) the telephone. Engineers often had to adapt to new solutions.

Thankfully, that didn’t happen, as plenty of collaboration tools, including Zoom, Microsoft Teams, Google Meet, and others, allow virtual collaboration and screen sharing. These tools have made remote work easier.

But not every situation is the same, and neither are the screen-sharing applications that development teams use. Using these tools effectively starts by using them correctly.

Decide How (and Whether) to Meet

Like it or not, whether it’s temporary or long-term, remote work is simply a reality for software-development teams today. That means online collaboration and meetings are now easier than ever to schedule. But that’s not necessarily a good thing: employees are attending 13% more meetings than they did prior to the pandemic.

These excessive meetings have been shown to decrease productivity. One study found that videoconferencing meetings cost more than $1,200 per employee, per month, in wasted time. Not only that, but too many unscheduled meetings can reflect poorly on your organization, resulting in decreased morale and job satisfaction among employees. Most tools today are not tailored for software development and engineering. Engineers and developers need more than meetings, video calls, and screen sharing to work together. Deep collaboration is an essential tool to help teammates work together.

So, the first thing you should consider is the purpose of your meeting and whether it requires screen-sharing capabilities—or whether the meeting is even necessary. Sometimes, simply chatting or sharing a screen capture through email will suffice.

However, if your meeting involves a back-and-forth discussion, then you should consider using a screen-sharing app. For development teams, such meetings might include team meetings, customer demos, and customer onboarding meetings. In addition, internal cross-functional meetings, such as sales reviews, are also good candidates for meetings with a screen-sharing component.

The most common tools for meetings like these are Zoom and similar applications, including Webex, Google Meet, and Microsoft Teams. These apps allow a presenter to share their screen and also include audio/video conferencing, chat, and some file-sharing.

These tools have become nearly ubiquitous, so they’re easy and accessible for most users. Keep in mind that the screen-sharing capabilities in the tools mentioned thus far are primarily presentational. They allow one person to share their screen, and the sharing permissions can be transferred from one user to another. Screen sharing is always one way, and viewers cannot interact with, edit, or control the shared screen.

There are other alternatives specifically designed for engineering collaboration that offer more interactive and collaborative functionality. We’ll discuss those a little later. But first, let’s address some of the basics, like how to use Zoom, and then get into the issues that affect nearly all screen-sharing meetings.

How to Use Zoom to Share Your Screen

Zoom is usually the go-to conferencing tool for most of us. It’s just what everybody knows. Here’s how to use it.

First, sign up for Zoom and download it.
Then start a Zoom meeting.
Along the bottom of your meeting, you’ll see a black bar with several icons. Click the green “Share Screen.”
Then select what you would like to share. You have many options. The most popular one is to share the whole screen, but you can also share individual windows or share from your whiteboard, tablet, or phone screen.

For a more in-depth step-by-step tutorial on how to share the screen control in Zoom. This article discusses how to give screen control to another user, request remote control, regain keyboard and mouse control of your desktop in Zoom, and how to enable multiple users to share and control the mouse and keyboard at the same time while in a Zoom meeting using CoScreen.

The problem with Zoom, though, is it has limited capabilities. You get cut off after 40 minutes on the basic plan, so you usually have to pay for it if you use it enough, and their least expensive plan starts at $149.90 for a year. That’s quite an investment for someone who’s casually talking to people. Another issue is that in order to allow other users to gain control of your desktop, you sometimes have to enable it through your system preferences, which can get tricky. If that’s happening in the middle of a meeting, it looks unprofessional. A great alternative to Zoom with the capabilities to do (individual and whole) screen sharing and share control of your desktop is CoScreen.

Cover the Basics

With the use of video conferencing and screen-sharing tools increasing, time-eating mishaps and inefficiencies are also increasing. Meetings often start late or have too much time devoted to sorting out technical difficulties or users’ unfamiliarity with the software, like when you don’t know how to use Zoom.

Luckily, avoiding these inefficiencies is relatively easy. You just need to consider the basics before you start.

First, make sure you’re prepared and that everyone on your team is prepared, too. That means doing simple things ahead of time. Know what documents, files, and images you want to present and have the right windows open. Log in to any apps or sites you might need to access during the meeting. Make sure your team does the same.

If you are switching presenters, make sure the screen-sharing permissions are set up correctly. This will help you avoid delays or having to restart the screen-sharing app in the middle of the meeting, which can be embarrassing.

You’ll also want to have a dry run, ideally just before the meeting starts, to make sure everything is working correctly. This is especially important if there will be outside attendees, such as customers, in the meeting. But even having a dry run is time-consuming.

Too often, someone will be in the middle of a presentation, and something will go wrong. The information doesn’t display correctly, transitions aren’t smooth, or technology fails in some way. Most of these embarrassing mishaps can be avoided with just a little preparation. Most of these embarrassing mishaps are occupational hazards while working remotely. While preparation and dry runs are extremely helpful, sometimes those mishaps are hard to control.

Another thing to keep in mind is that many screen-sharing apps, notably Zoom, will completely take over your desktop when you’re screen-sharing. This can make it hard to toggle between windows if you need to find information, so you may want to have a second screen where you can access that information while sharing.

Finally, there are a few other things to consider as you prepare for a seamless screen-collaborating session on Zoom, Teams, or any other application:

While the presenter may want to keep their audio/video on, it’s a good idea to ask everyone else to turn theirs off, at least during the screen-sharing portion. This helps ensure that viewers with slower connections have fewer problems and minimizes interruptions. You can encourage viewers to submit questions through the chat or save them for the discussion portion of the meeting.
If you’re planning to record the meeting, make sure everyone is aware and gives explicit consent. The laws dealing with recording audio and video calls vary by state, so it’s best to cover your bases and get permission. This is especially important for meetings involving people from outside the company.
Use a resource for sharing files, along with clear instructions for accessing and downloading them. Zoom and other screen-sharing apps allow you to share files through the chat feature, but if you’re dealing with larger files, it might be best to use another source.
Follow your organization’s cybersecurity guidelines to avoid scams and data breaches.
Turn off your notifications, and close unnecessary tabs, windows, and applications. This not only keeps the meeting running smoothly but also avoids the embarrassment of personal information is on display for all to see!

There’s Sharing, and Then There’s Collaborating

While apps like Zoom, Teams, Webex, and others are great for presentations and meetings, there are times when one-way screen sharing is not enough. Particularly when your engineers are all working remotely, they will sometimes need more robust tools to be productive.

One example where a collaborative, interactive screen-sharing application is required is during pair programming. Co-located pairs had it pretty easy, as they could sit side by side at one workstation, taking turns at the keyboard while discussing the code.

Pairing remotely is a little more challenging because working at a single workstation isn’t possible. One-way screen sharing apps like Zoom offer a partial solution, allowing the driver and navigator to see the screen. But the actual work can be done on only one machine, so switching roles—a common practice in pair programming—is cumbersome at best.

Fortunately, there are tools that are designed to facilitate collaboration and project management for software development. However, these tools are focused only on a terminal or IDE collaboration. With that said, engineering collaboration and pair programming go way beyond IDE. One such tool is CoScreen. Unlike video conferencing applications, CoScreen offers features that let collaborators work together more effectively—even if they’re working remotely.

CoScreen goes beyond one-way screen sharing, letting users share windows on a joint desktop. This makes collaboration possible in ways that other video conferencing tools cannot.

With its remote-control capabilities, multiple users can interact with and edit shared windows as easily as their own local applications. So engineers can do more than just discuss what needs to be done; they can make live changes and edits.

That capability makes CoScreen well suited to a variety of use cases that developers face on a daily basis:

Pair programming and debugging: Engineers can work together as if they were at the same workstation, no matter where they are.
Creative troubleshooting: If developers get stuck, they can easily get help from a colleague and work through the problem.
Code and design reviews: Team members can walk each other through the design, and reviewers can make suggestions immediately and even test the code. *Standups and sprint demos: Everyone can align faster by seeing what the team is working on and what has the highest priority.
Ops and incident response: Engineers can share their terminals to work together to address issues in real-time.
Onboarding and coaching: Senior engineers can work with new hires to guide them through a project and provide help when necessary.

Don’t Settle for Ordinary Screen Sharing When Deep Collaboration Is Required

The software development landscape changed dramatically when teams were suddenly forced to work remotely. Nothing lasts forever, and it’s safe to say that at some point, companies will go back to co-located teams, at least to some degree. And when that happens, deep collaboration will be a vital tool.

“The dominance of Zoom and similar tools in the remote space made me seek more collaborative solutions like CoScreen, out of necessity for tools beyond just pixels on a screen with audio. We need more, and we should demand more if this is how the future of work will pan out.” - John Lilly, former CEO of Mozilla

Engineers will most likely be a great example of what these hybrid models of remote work will look like. Some engineers will spend time on-site when their presence is necessary, like when they’re taking measurements, and other times, they’ll do remote work, like drafting or doing a report, at home or off-site. Deep collaboration will be necessary between engineers who follow this hybrid model of work.

Large companies like Google and Facebook have already stated they plan to stick with remote work into 2021 and beyond. Many employees have said they want to continue working remotely as long as they can, citing benefits like eliminating commutes and spending more time with their families.

Online deep collaboration and screen sharing are simply accepted means of working, and companies need to make it as easy as possible for their remote teams to be productive. The right tools allow you to go from passively sharing a screen and displaying information to deep, interactive collaboration.

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.

Love It or Hate It, Pair Programming Is Here to Stay. Here’s How You Can Live with It.

Jason Thomas — Wed, 03 Mar 2021 21:48:11 +0000

We all remember the word problems from middle-school math:

If Jane can paint the fence in two hours, and Bill can paint it in three, how long would it take the two of them to paint the fence if they worked together?

Imagine that same word problem, except instead of painting a fence, Jane and Bill were software engineers.

If Jane can write 20 lines of code in one hour, and Bill can write it in two, how long would it take them to complete the task if they worked together … on one computer?

The scenario described above has a name. It’s called pair programming. And many engineers would have a NSFW answer to the question and tell you why pair programming is bad.

Pair Programming: Reasons to Hate It

(Source)

Companies that adopt pair programming have cited several benefits, including a shared project experience and ownership among developers, a better understanding of project goals, effective collaboration, and happier employees. Some companies skip administrative processes like code reviews because the shared context is implicitly established and approved during the programming sessions.

Hate. It.

Pair Programming: Reasons to Love It

Believe it or not, some developers find pair programming to be just plain fun. There’s a certain joy in working on a project as a team.

From the organization’s standpoint, what’s not to love about pair programming?

Making Pair Programming Work

So here are some strategies you can use to make it work for your company and have your engineers enjoy it. Or at least tolerate it.

Understand it’s not one-size-fits-all

However, you implement it, be sure to let your teams evaluate the experience afterward to understand what worked, what didn’t, and why. Then, apply that knowledge the next time you consider pair programming.

Try different techniques

Pair programming isn’t just one thing. There are actually different types or versions of it, and the right for your organization, again, depends on your situation.

Truly collaborative pairing, like through CoScreen, allows you to have multiple drivers, and to switch between driver and navigator rapidly while letting users observe and continue doing other work on the side. Having the driver and navigator switch roles every so often can keep both engaged in the process. You can also use ping-pong pairing, in which the team follows a loop of writing, passing, and refactoring sections of code.

There are other techniques you can explore. The right technique depends on the task, but it might also be best left to the pair themselves to determine how they work best.

Follow general etiquette

Finally, pair programming teams should use common sense to maintain effectiveness. Switching roles frequently and taking well-timed breaks helps keep them fresh and gives their mind a break.

Why Pair Programming Is Bad: It’s Best in Moderation

About the author:
Jason Thomas is the CTO and Co-founder of CoScreen, a radically different collaboration platform for engineering teams. He has worked in remote engineering teams for most of his career with a focus on video conferencing applications.

Even a 10X Engineer Works Best in a Team

Jason Thomas — Fri, 26 Feb 2021 16:51:39 +0000

The Legend of the 10X Engineer Who Only Works Alone

Some have claimed that the popular notion of the 10X engineer — the introverted, antisocial genius who can single-handedly make your business succeed — is deeply flawed.

Having a smart, productive engineer on your team isn’t worth the hit your team dynamics can take if this person refuses to fit in or work with others. There are other smart, productive engineers out there who will benefit the team as a whole, and those are far more worth having. - The “10X Engineer” Has Officially Become a Meme

It leads startups to pursue hiring people they think are 10X engineers and then treat them as untouchable gods of coding. A host of organizational problems follows, including toxic work relationships, poor communication, and unhealthy work environments.

But that is not the right path. Placing engineers in a sole programmer role can, in fact, be dangerous and detrimental to the organization and to the programmers themselves.

But working on a software project all by yourself, instead of being empowering, is paradoxically debilitating. It's a shifting mirage that offers the tantalizing promise of relief, while somehow leaving you thirstier and weaker than you started. - In Programming, One Is The Loneliest Number

Plus, the more heroic hours engineers work to “carry” their teams, the less productive they become. (Source)

And, to be sure, there is often an allure of working alone. Developers can often work faster, and for certain tasks and projects, it simply makes more sense.

But even for the most talented engineers, getting the best work out of them has as much to do with the organization that surrounds them as it does with their own capabilities.

What Really Makes a Great Programmer?

(Source)

Fostering Shared Context and Collaboration

Following these philosophies not only helps companies get the most out of their engineers (10X or otherwise), but it also offers a litany of benefits to the company:

Helps to create a sense of trust and open communication among the team, a key characteristic of any healthy team
Reduces the need for extensive, overbearing administrative guardrails to govern sole programmers’ processes, slowing them down at the same time
Eliminates frustrations and errors caused by team members not understanding each other
Helps create better products through stronger code and meaningful contributions from more people
Reduces multiplication of code where the fundamental logic might be unnecessarily processed in several places

Examples of channels for building shared context. (Source)

It’s important to recognize, however, that it’s a process that’s never done. Team dynamics are always changing as people grow in their jobs, others leave, and new hires come on board.

One of the best ways to not disrupt an engineer’s productivity is by reducing unnecessarily long meetings, which requires scheduling a time, inviting people, and determining who will present.

This reduced the need for traditional, cumbersome meetings in favor of short, concise, focused sessions that are scheduled on-demand.

One Company’s Approach

“We try to make sure our teams are scheduling time to catch up with each other.”

He also cited using communication tools, like chats during video calls and Slack channels that allow employees to discuss non work-related topics.

“They can just talk about shared interests,” he said. “It recreates the water-cooler dynamic.”

When it comes time for their developers to put their heads down and get to writing code, whether they work in teams or alone, depends on the task at hand.

Lone Developers Have Their Place

Western culture tends to value the contributions of one over that of the group. The lonesome cowboy, the knight in shining armor, the superhero. The genius programmer.

There is a time and a place for the undeniably great contributions of these individuals. But there needs to be a balance. Lone Developers need not be lonely anymore.

They can still have their productivity and focused, in-the-zone time. But at the same time, with the right tools, they can make other developers, and their organization, better.

Next-gen Screenhero: Building for better collaboration

Till Pieper — Tue, 23 Feb 2021 19:46:17 +0000

Screenhero was an online collaboration tool like nothing else, right up until Slack discontinued it in 2017, leaving a void in the programming world. Fortunately, we here at CoScreen have built a brand-new tool that does everything Screenhero did (and more).

If you never got to use Screenhero, there was a reason why it became so popular: It was a tool that let its user screen-share any of your applications with any collaborator over the internet. You both were able to use your own mouse to interact with the application, making it specifically designed for remote teams. With it, you could collaborate in real-time and with any app you had on your computer. It made a lot of work that much faster and was specifically good for pair programming and for presenting to clients.

CoScreen provides people with everything they loved about Screenhero — just improved in nearly every way. It’s packed with features that tackle the needs of remote teams through an entirely new concept.

When the World Lost Screenhero

Before Screenhero, remote developers had to work using video chat and screen-sharing tools that didn’t encourage collaboration. The best solution was possibly tmux, which allowed users on Unix-like systems to access multiple terminal sessions. But it wasn’t exactly an intuitive system, unless you really knew your Linux commands.

Screenhero removed that hurdle and allowed developers to work nearly in real-time, using any app they could think of, which was a game-changer upon its release in 2013.

Not only could two people share a screen, but both could also control it with their own mouse. Clients could modify a project a developer was working on, or two developers could code together. It didn’t take over your whole screen like other video services, either.

But then in 2015, Slack acquired Screenhero, and then discontinued the stand-alone service. They intended to rebuild all of the features directly into the Slack app to offer a more efficient experience, but developers decried the new integration. Worst of all was that it lost multiplayer support, and users complained that it wasn’t as bandwidth-efficient.

And, while many of us use and love Slack on a daily basis, no one uses it for its video chat or screen-sharing. Interest in the screen-sharing service on Slack floundered, and it was eventually removed entirely.

Developers all over the internet lamented Screenhero’s loss.

Stand-alone substitutes have emerged in its place, but nothing has been quite the same. Most of the competition has just emulated what made Screenhero popular, without adding anything new.

The (Screen-Sharing) Hero Developers Need Right Now

Developers still yearn for the return of Screenhero. But rather than waiting for this long-dead hero to rise from the grave, developers can instead lean on CoScreen to meet their needs in a new way. Not only does it do everything Screenhero did (and faster!), but it also offers a superior collaboration experience and is packed with innovative new features.

Perhaps the biggest improvement is that you aren’t restricted to sharing one person’s entire screen. Multiple people can share individual windows just by clicking on a tab above each window or by dragging them to the shared screen.

See CoScreen in action
It also makes for a fundamentally more interactive (and vastly improved) user experience. No longer do you have to wait your turn while someone shares their screen — every user can share their own app anytime they wish.

Users with a second monitor can utilize it like a shared screen, allowing them to drag and drop windows from “their” computer to the shared space as they please. It’s a handy way of keeping track of what window is where. Of course, CoScreen works just as well with a single screen, and it highlights who is sharing which window. And, whereas other services only allow two users to develop software together at a time, CoScreen allows up to eight to share and collaborate concurrently.

It also offers simple remote-control features that allow users to jump right into collaboration. With it, users can manipulate other people’s windows and apps as if they were their own. To assist in collaboration, there’s even seamless video and audio chat integrated that lets users easily discuss what they’re working on.

CoScreen vs. Screenhero

Feedback for CoScreen has already been hugely positive. For example, Don Goodman-Wilson, one of the original Screenhero devs, called CoScreen “game-changing” and now even works with them.

Even at this early stage, there have been a number of success stories:

Grid AI says that using CoScreen has allowed them to build software 2x faster.
Engineers at Salesforce, Okta, and other great companies have onboarded new remote team members faster than ever.

How will you use CoScreen?

Beyond Pair Programming: How CoScreen Will Help Live Collaboration Evolve

We want CoScreen to help with all of your “deep collaboration” needs.

Interested in pair programming, but can't be in the same office? CoScreen allows developers to pair program as if they were sitting at the same workstation.

Need to troubleshoot a problem? How easy would it be to simply drag the screen over and get solutions in real-time? This works for code and design reviews as well, allowing reviewers to suggest immediate changes rather than having to wait to see them implemented.

People in an onboarding or coaching role have found CoScreen invaluable to walk new members through the process. Since you can work with everyone collaboratively, they don't have to watch as you show them what to do — anyone can work together and learn as they go.

CoScreen also offers integration with apps such as Chrome, where it can replace your meetings in Google Calendar.

And CoScreen is not just for remote work! We all may be stuck working from home, but CoScreen has applications in the office. It will allow an in-office team to communicate with freelancers or clients or even easily present demos and get feedback in real-time.

We’re constantly impressed with all the ways we see clients using our product. Also — fun fact — we use it ourselves. As a remote team, we use CoScreen daily to work on making the tool better.

A hero for today ... and the future

So Screenhero may be gone, but we think you’ll agree that CoScreen will be celebrated by anyone pining for a screen-sharing solution. The multi-user functionality makes it truly unique and uniquely suited for the problems facing remote teams. Not only is it perfect for our current work-from-home lifestyle, but it’s also perfectly suited for in-person collaboration, ensuring that you’ll use it long into the future. Drop us an email at hello@coscreen.co, and let’s chat about how we can help you!