We are excited to share a new page of our story: USE Together will become Drovio on March 18! It’s still the remote pair programming tool you love, yet providing a new experience of screen sharing and for us, the beginning of an even bigger adventure:
We’ve surely come a long way since we started off from the ground up in 2016. Back then it was just Benjamin and me in a very small yellow-painted office who wrote the first bits of the tool. Screenhero, a Slack-owned similar app, was still around and I kept asking myself: what makes in-person and remote teamwork different? How can we make remote collaboration a breeze for all teams, with partners, with clients? How can we make the experience seamless? Two points quickly came up to the table based on a few discussions, research and the available screen sharing apps in the market:
We eventually released a Windows only version a day of July 2017 and opened it to everyone on our website. The UI was terrible, a few bugs caused major hiccups such as a whole black screen each time you started the app but eh, it was out. And we were so proud of it! That day, we even ended up doing well with our launch on Product Hunt, considering that we started from nothing. The feedback we also got from those users was a godsend and completely different from what we usually heard.
We took another year to review our copy. Meanwhile, we launched a beta version for macOS and Slack had merged Screenhero into their app, or kind of. Usage climbed up, good signals were received and still great feedback as well that enabled us to improve the app. As you’d imagined, things quickly got out of control as people from all over the world were all suddenly looking for apps to work remotely with their teams. We were busier than ever, yet we kept holding on.
Fast forward to now, we’re proud to serve today more than 26k users distributed on all the continents, with a rating of 4.4 out of 5, for about 5k sessions per week, each session lasting an average of 42 minutes.
We’re currently on a plain accelerating phase and we’re targeting 20 people before 2021 ends.
We’ve been spending the last few months working on great stuffs and I hope you’ll like them. This includes a new logo for our app: we wanted something sober yet to the point and matching the big picture.
👩💻 Video conferencing will be part of that release as well, for up to 10 participants with any paid plan. Seeing your remote pairing/mobbing partners helps to ensure things are fully understood by all parties. The funny thing is that we had this feature in our 2016 mvp but we decided early on to focus on screen sharing and audio.
🎨 The next one is a revamped UI to accommodate with the new direction we’re taking. This revamping will actually be split into two phases as there are many things we wanted to do but we didn’t have enough time to. We thus focused on the major pain points you reported us, including how sessions are handled. We’ll expand on that in another article.
🔐 You’ve been waiting for it, SSO (SAML) will be supported starting from March 18 on the new Business plan. This new feature will make it easy for all your team to connect and will also simplify team onboarding a lot as you won’t have to manage it anymore from the dedicated panel: when people log in using your company’s SSO, they instantly get added to the team.
🐧 Last but not least, our Linux app is coming out of Alpha! We’ll make it available to everyone and the feature set will be on par with what we have on the other systems.
Finding a name for an Internet business nowadays is incredibly hard. Yet, I wanted to transpose the essence of USE Together into it: we want to bring teams together, let them move forward on any task, any project, whatever the distance, whatever the tools/apps they use on a daily basis. USE Together lets teams escalate from blabla to action in no time, without any friction.
Considering that, I spent some times looking for words or synonyms that could convey the main idea, but the trickiest part was yet to come:
I eventually came upon drove/droves: a large pack of people who are united, moving forward together with one goal in mind. A few combinations and whois queries later, we eventually registered drovio.com.
We’ve decided to do a little cleanup in our pricing and bring in more value to our paying users. The first step was to merge both our actual paid plans, Pro and Premium. For the record, the Premium plan allowed users to join sessions of other users who were on a free plan and get unlimited remote control during the session. Actually, only a fraction of paid users was on that plan.
We’ll also be adding a new plan to our offer, designed for large teams that includes SSO support, a dedicated customer success manager and later, new enterprise-oriented features and services.
Both our new paid plans will allow you to do sessions with up to 10 participants ( vs 4 participants before).
The last change is on our free plan. Remote control is still limited to 30 minutes per day, but the number of participants per session will be limited to 2 and the feature set will also be limited.
Here’s what it will look like on March 18:
On March 18, every user on a paid subscription, be it Pro or Premium, will get their subscription upgraded to the new Standard plan at no additional cost for the rest of their billing cycle.
To be clear, if you’re on a Pro monthly subscription today, you’ll automatically benefit from the upgrade (up to 10 participants, unlimited remote control on any session, even with free users) and you will only be charged the full amount on your renewal date. It also means that if you switch to a yearly Pro subscription before March 18 for you or all your team, you’ll actually get a discount of up to 33% off for almost one year!
We’ve also decided to bring in a fair billing policy à la Slack for all teams. I deeply believe this should be the norm for any SaaS business and that users should only get charged for what they really use. Managers, VPs, C-levels have to deal with a ton of SaaS subscriptions for all their teams and one question often comes back to surface: do my teams actually use that app we’re paying thousand of dollars for each month?
We could have implemented a ton of graphics that you would still have to periodically review, but we value your time and your people too much for that.
Here’s how our fair billing policy will work:
Current teams will have the choice to either migrate to the new fair billing model or stay with the current one. The new fair billing model will require you to select one plan for all your team whereas the current one allows you to mix plans. The Business plan that includes SSO will only be available with the fair billing model. When you migrate your team to the new billing model, all your team members become inactive until they use the app again.
🤗 From all the Drovio team to all of you, thank you for your support, thank you for all the feedback you shared with us during those years. This has been an incredible journey for us, thanks to you. There’s a lot of great stuff coming up this year besides what is exposed above and we’re eager to share that with you all.
📩 Meanwhile, be sure to reach out to us at email@example.com, should you have any questions or just want to say hi.
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.