Remember when it was so easy to start a collaborative screen sharing session with Slack? We’re bringing back the experience, yet with the full USE Together feature set. Escalate from chat to action by sharing your screen with USE Together right from within Slack, with remote control and multiple mouse cursors support.
The way people work together is transforming rapidly, whether they are remote or in the same office. We deeply think team collaboration should have no boundaries. We’ve always aspired to let people smoothly gather online and collaborate even better than if they were at the same desk, from anywhere in the world.
Slack CEO, Stewart Butterfield, predicts company email as we know it will come to an end in 7 years. We believe in that. We’ve already helped many companies overcome the pain of back and forth emails: with USE Together, you are just one click away from anyone’s screen.
Today, it gets even easier than ever. You can now launch collaborative screen sharing sessions directly from Slack with our integration (using the /use slash command or directly with the call button) and know who’s on the session before you join it.
Participants don’t even need to have the USE Engine app installed on their computer. They can join you right from their web browser without having to install anything and still be able to remotely control your screen.
If you already have the USE Together app for Slack, be sure to update it by simply re-adding it to Slack. Also, you will need to update USE Engine to version 2.2.0+.
Any questions or feedback to share? Get in touch with us at firstname.lastname@example.org.
This is always an excitement to unveil what we’ve been working on recently. Yesterday, we launched a new release with brand new features we hope you’ll enjoy. Download the latest USE Engine binaries here.
No need to share code snippets through chat anymore. Copy and paste text or images from or to the shared screen seamlessly. Afraid that Jerry might steal your illustrations for his presentation tomorrow? Disable this feature completely in preferences.
This is a fact, most of developers have a GitHub account. We’re thus making it easier for our fellow devs to sign in to USE Together.
We’ve been already supporting sign in with Slack and a lot of users now sign in with their Slack identity. No need to remember yet another password, a few clicks and you’re in! Also, they both handle two-factor authentication (2FA) and can be interfaced with your single sign-on (SSO) provider.
When designing, getting a remote blurry screen is far from optimal. With this feature, participants get a Retina quality screen capture. Enable it from preferences, a full size capture of your screen/app will be instantly sent to the participants. Make sure you have enough spare CPU and bandwidth as this is two times the normal screen capture size.
We’ve revamped the app client and removed the lateral panel. You now get a small session toolbar appearing on top of the client that can be moved anywhere. We’ve also reviewed the host session toolbar so it looks the same and takes less room than before.
Should you have any questions or feedback to share, feel free to drop us an email at email@example.com.
Six years ago, GitHub launched the GitHub Student Developer Pack program to offer students the best real-world developer tools and training for free. We’re proud to announce that we’re partnering with GitHub Education and now part of the Pack.
Students are our future. At USE Together, we strongly believe they should get access to the best tools available. That’s why students can now get the best USE Together offer: a free Premium subscription, allowing them to pair from anywhere, at any time and with anyone, as long as they’re students!
We may offer discounts to teachers, educational and nonprofit users. We’d be happy to hear from you and know more about what you’re doing with USE Together. Contact us and share the maximum details about your project or organization. We’ll review each case individually.
What most effective teams have in common is certainly their ability to work together. When it comes to software development, one way to work together is pair programming.
Pair programming is a technique where two developers sit at the same desk and code together. The purpose is to spread knowledge over the team, share good practices and sometimes overcome technical challenges by combining two people experiences to solve a problem. At any time, one developer is coding while the other one reviews each line as they are typed and thinks ahead. They must engage with the task to perform for this exercice to be beneficial. Thus, no place for procrastination.
From the point of view of a manager, two developers working on a single task may appear like a waste of resources. However, studies have shown that for a 15% longer development time, pair programming improves code quality, reduces massive show-stopper bugs and enhances team communications (see “The Costs And Benefits of Pair Programming”: https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF).
Let’s see when to pair and how to do it effectively.
Even though the ultimate goal is to produce a fully working piece of code, pair programming can be employed for various reasons. Generally, it depends on the skill level of the participants.
The most common usage is a junior programmer pairing with a senior one. The former types while the latter instructs on what to do or help the junior figure it out without giving the solution beforehand. In this case, pair programming is used as a learning and on-boarding tool.
Roles are not exchanged at first. Junior programmers can’t learn by only watching someone else type lines of code they might not even understand. Either because they don’t know the code base yet or because they’re lacking experience. They have to experiment a bit their ideas and make their own mistakes to learn.
Thus, senior devs have to resist the urge to always take over the keyboard control and even show any sign of irritation. Patience is the key here. Sure you would have done the task in a minute, but would that serve any purpose? You don’t want juniors to be discouraged and leave the team. Instead, senior devs should progressively bring juniors to the path that lead to success.
To make this happen, the junior dev speaks their mind aloud as they type. When the senior dev disagrees, they let them reach a dead end then explain why it was not working. Another approach is to ask questions as the junior dev tries to describe what they’re going to do. They’ll inevitably doubt about the proposed solution. This way, they can understand by themselves it would not work and will actually learn. It requires a lot of patience and sessions should be definitely kept short, the exercice being so exhausting for both parties. At the end though, junior devs will be way more engaged and motivated.
The junior dev, mostly. Yet we all have different visions when it comes to problem solving and juniors can bring a breath of fresh air to a project you should not underestimate. Also, senior devs who’ve been part of the team for a long time well often share the same point of view on a code base and how things should generally be done. A junior dev, however, usually ask questions that force the veterans to explain what some portions of code actually do. This helps to detect design flaws early on that you wouldn’t have suspected at all. You onboard a new team member and at the same time review what has been done before, making sure it’s understandable and that it won’t all fall apart someday. Win-win.
Two juniors pairing together is generally considered a bad combination. They can’t rely on an experienced developer to help them sort their minds. On a complex story, when dealing with agile projects, they’ll lose time investigating each dead end. That generally leads to frustration and failure, also potentially increasing project risk.
A senior dev should approve the stories they pick, generally simple stories. It can work if the team is ready to accept errors and if the juniors already had prior pair programming experiences with a senior dev. They’ll be able to share with each other what they’ve learnt from their past pairing experience.
Also, there are always trade-offs to be made when dealing with development. When they have no senior dev around at disposal, junior devs have to take their own decisions. Something they could be reluctant to do when pairing with a senior, too worried to seem somehow dumb. Taking decisions is an essential part of the learning process when coding. It allows devs to build up their self-confidence.
Pair programming is a good practice to grow as a cohesive dev team. You want juniors to be more effective and expect someday they’ll be able to handle stories by their own, without systematically requiring you to fix everything afterwards. For this to happen, they first need to feel they are key elements of the project and team.
The last scenario I’ve not tackled yet is two senior devs pairing together. Although a senior programmer might be able to handle any story of a project, there are a few cases where pair programming can help: learn a new framework together, resolve bugs implying multiple code portions written by each parties or increase the bus factor.
Bus factor refers to the number of people in a team that can put a project in trouble if they disappear (literally by being hit by a bus but more seriously for vacation, illness or leave). Having a good bus factor value ensures the project will eventually come to an end. The rest of the team can easily take over the work done without being lost or having to restart from ground zero.
Pair programming helps to spread knowledge over the team and allows to increase the bus factor value. People involved on a project are no longer isolated on specific corners of the project and code duplication is avoided.
We often pair at USE Together just for the sake of increasing our bus factor. As developers, we have our own preferences when it comes to technologies, programming languages, frameworks. Pairing allows us to move out of our comfort zones, understand quickly how some piece of code is articulated and get ready to take it over when people are on vacation or simply working on other urgent stuffs.
There are numerous flaws we can potentially write when coding solo. We sometimes lack that step back that would have permitted us to quickly realize something will not really work as intended. When implementing a solution, developers have most of the time different approaches based on their experience. Two minds combined will help reducing massive show-stopper bugs.
Pair programming allows to share consistent coding practices between team members. When you expose some new way to arrange the project’s code during a meeting, people might not be as receptive as you thought they were. Pairing with them on a task that would, at some point, involve following your good practices will help them remember and understand the why.
Multiple techniques can be used to pair program. At any time, there are always one developer typing and one observing.
A classic one. The driver takes the keyboard and mouse control, writes code, navigates between files and mainly focuses on the current step to be done. The navigator, on the other hand, is responsible for reviewing each line of code being written and thinks more about the big picture: are we on the right track? Will that cause some bugs to emerge? What’s the next step? Driver and navigator often switch roles every 5, 20 minutes or each hour. It mostly depends on the pair but that should happen. Otherwise, the driver will feel exhausted quickly and the navigator will be bored and tempted to procrastinate.
This variant works best for senior-junior/newcomer pair programming. Basically, it’s analogous to driving lessons. The junior or newcomer dev is the driver and is responsible for writing the code. The senior dev is the navigator and gives clear instructions on what to do next, sometimes how to do it when the junior has absolutely no clues. After some lessons, the driver should have build up more self-confidence and know the main parts of the code base. The navigator then only gives a few tips when necessary. It’s important that the navigator resists the urge to take over the keyboard control. They should instead help the driver to figure out by themselves how things should be done.
In combination with test-driven development (TDD), a programmer is responsible for writing a failing test while the other implements the minimum needed for the test to pass. After a bit of refactoring, they exchange role: the person that made the test pass now writes a new failing test and the other one codes an implementation. Going back and forth, as a ping pong game.
The driver should speak their mind at any moment by explaining their approach. This way, the navigator can validate or suggest a better way to solve the problem. It requires some practice to rubber duck to a real person when you’re only used to speak with your brain. At the end, you will improve your own coding process.
Rest your eyes, drink, check emails, whatever but take breaks at regular intervals like 30 minutes or 1 hour. Constantly chatting and conveying your mind is exhausting.
We don’t think the same way, you should show some tolerance when your pair is taking too much time to solve an obvious problem. Maybe your pairing partner is thinking ahead about other issues that might arise or simply confused because of your irritation. Irritation is the first cause of bad pair programming experiences.
An essential skill for a programmer is the ability to search effectively on Google for docs, examples or similar issues as the one you’re having and possible ways to solve it. As the navigator, you might just be tempted to do that off-screen, say on your mobile phone, because the driver is indeed not searching for the right keywords and it’s exasperating you. Don’t. That’s an open door to distraction (oh I’ve received 6 emails). Instead, wait for them to find nothing relevant. Then, suggest new keywords and explain why you would search for that. Remember, pairing is learning and requires patience.
As the navigator, don’t insist too often on every mistake. The driver will figure out by themselves that a semicolon is missing or a variable is misspelled. Doing this too often makes the driver focus more on the code style than on the task itself.
Or zoom text. Especially when using high resolution screens. Hard to read when not exactly in front of the screen. If you can, plug in another one and mirror your desktop.
Use two mice and two keyboards to switch roles smoothly and at regular intervals (5, 20 minutes or 1 hour). But keep in mind you have one role at any time. Resist the urge to take over the control if you’re the navigator.
Keep the comfort of your own desk and overcome the last two points by pairing remotely with USE Together.
USE Together, the screen sharing app that lets you collaborate with your teammates from anywhere in the world as if you were all at the same desk 👩💻👨💻 is finally coming out of beta.
USE Together online beta has been available for free for about 20 months now and it sure has come a long way. We made it a point to listen to all of you and over these months, we received quite good feedback 👍 that allowed us to improve the app considerably.
From all the team, and to everyone who have been using USE Together since the beginning or have just started using it, thank you 🙏.
We’re thrilled today to announce that USE Together is finally getting out of beta on Wednesday, March 20.
You will be able to choose between two plans:
Both of these plans will allow you to invite up to 3 guests on your screen.
Only Basic users who share a screen will have the limitation. You will still be able to take control of a Pro user’s screen with a Basic plan, even if the daily limit has been reached on your account.
We made it simple for teams to manage their subscriptions from one place, with centralized billing. Add, remove team members and change their plans (Basic or Pro) at anytime. Each invited team member will get the whole team added to their contact list on the app.
Last but not least, some brand new features are coming:
📹 Record the session (screen share and audio chat) to re-watch it later on. A nice feature to make instructional/demo videos and keep track of what has been said during the meeting.
🖥 A new lightweight session bar will appear on top of your screen when a session is running. It will enable you to quickly change what you’re sharing, mute your microphone, record or end the session. You’ll be able to hide it completely.
🔗 Opening a shareable link will now ask if you want to join the session from the app (instead of the web browser only) if you have it installed.
Please note that starting from Wednesday, March 20, you will need to update the app to the latest 2.1 version to continue using it. You will automatically be subscribed to the 15 days Pro trial.
We’ll be happy to answer any question you might have. You can reach us at firstname.lastname@example.org.
Happy screen sharing 🙂