DEV Community: Jason Thomas

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.

CoScreen exits stealth to bring multi-user screen sharing and editing to remote engineering teams

Jason Thomas — Thu, 25 Mar 2021 15:04:44 +0000

https://venturebeat.com/2021/03/25/coscreen-exits-stealth-to-bring-multi-user-screen-sharing-and-editing-to-remote-engineering-teams/

CoScreen has exited stealth, Windows & Mac clients are generally available:
https://www.coscreen.co/

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.