In places I've worked in, there's very little pair programming culture. If a dev needs help, maybe the reaction is "push your code to a special branch and I'll take a look later" or if it's really urgent "use screen sharing" instead. A lot of that comes down to different environments: some use Emacs, others use Vim, yet others use VSCode, and remote control isn't really effective because of all the different shortcuts and UI and customizations. That's before even different personal preferences for different tools: I want IDE-like integrated error messages right beside my code, they want error messages in a separate terminal window, etc, etc. Simple screen sharing and dictating things to do is good enough in that case. And if both persons are at least somewhat familiar with the language, you wouldn't be dictating token-by-token.
Until recently, I spent the whole pandemic exclusively remote pairing. We always did driver/navigator and never did any controlling of each other screens. If we switched roles we’d just pull the branch and work on our own machines. Tuple is nice for doing that quickly as you can just take over sharing without having to ask the other person to stop first. Its markup tools are very nice and simple, too.
Having a way to ping things or draw on screen is super useful even if everyone uses their own environment. No more "no, not this line, the 4-th one from top, well now its on bottom, wait don't scroll".
Ha, ya. Tuple's are perfect as it gives you the "draw quick attention to this spot" and then the pen tool auto-disappears with a setting to make it stay forever with a quick shortcut to erase everything. I actually almost exclusively use the pen now, though I use to make a lot of use of the ping.
I can tell you how Pivotal solves this problem (or used to; my time was years ago): Standardize the configuration. If some special tool is making you more productive, share it with the team and get everyone on board. Don't try to be a special snowflake.
IMO this is the right way to do pair programming. It tends to bring everyone up to speed with the latest tools, and it keeps eccentrics out of the weeds. It's not to everyone's taste, of course. But neither is pair programming.
Cater to your own needs. "Special snowflakes" would include disabled folk that need special setups. If you need a special setup to avoid RSI or to be more productive, do it.
Folks with disabilities would not be considered in the snowflake category. If a team member needs a certain setup then you have to support them, of course.
Snowflake behavior is being the person who just can't use the terminal if it isn't "set -o vi" keys. Or insisting that Caps Lock be mapped to Ctrl/Esc/etc.
But if you are used to Caps Lock being mapped to Ctrl/Esc/etc and then suddenly it’s not it is actually pretty jarring. I don’t think that’s special snowflake. The problem is that it’s not absolutely trivial for whoever’s currently using the keyboard to put it in whatever mode they’re used to.
Or that people are sharing a physical keyboard and having this problem at all. You can pair program with more than one keyboard.
'Dealing' with Esc for Vim would fall under RSI prevention in my book. Using Vim almost necessitates some form of easier switching modes; swapping Caps Lock, `jj`, etc. are all considered valid and 'normal' for the general Vim community and to say only one or even none of the options are "okay" in the company, well, unless it was my preference this would be an immediate resignation from me. That or the company better be shelling out and allowing time for employees to configure programmable keyboards they can pop in with their keys hardware configured.
The Pivotal sharing station has separate keyboards and mice for each developer. Many people bring their own keyboards and pointing devices. That's fine.
"I can only be productive in emacs" doesn't fly, unless you happen to be paired with the rare snowflake that feels similarly.
Team, not organization. A big team might be 5 pairs. There was no hard rule that everyone had to use the same setup - you'd occasionally see pairs in vim or whatnot - but since you're switching computers and pairs almost every day, you tended to homogenize quickly.
My team standardized on JetBrains. Even if someone is unfamiliar with the IDE, pairing gets them up to speed fast. Humans can learn any dev environment.
Hi there. I don't do pair programming and I'm pretty wary of it, but I checked out the site and watched the video and I have a suggestion.
Suggestion: market this to remote teams regardless of whether they do "pair programming" per se!
In my last job we had our team spread out over continents and time zones and home-offices and office-offices: bandwidth for meetings was super unpredictable.
Thus anything with a live video component was hit-or-miss, and if you had something very technical to discuss, you often had to sync up to make sure everyone was reading the same page on Jira or whatever.
I realize your tool is probably only for 1:1 conferencing, but even then, I think it could be compelling to have really good screen sharing with some annotation and the resolution control. Even if (especially if) it's only going to be used by two people at a time.
(Maybe this needs a different kind of license though. If I have 10 people on a team and expect 5 of them will use it but I don't know in advance which 5 or when...)
Also I would absolutely want something like this in a startup, even for managers, just to be able to go over stuff like AWS consoles (shudder) together.
It's a brilliant tool! Picture quality is excellent - I guess due to peer-to-peer - and the quality of the product also generally feels high. I recommended it to a new team just today.
But the audio connection seems to keep going for a few seconds after you close the pairing screen. Could be seriously embarrassing if someone utters something after thinking they've ended the call.
Lol I'm not lying to you! I almost always hear an end-of-call sigh from the other person that I'm sure they aren't expecting to broadcast because they think they've ended the call, but nothing embarrassing yet!
I'll try to screen-record my next interaction and show you. I think the problem is closing the window shuts down the screen link but not the whole pairing session, but people don't realise they need to separately end the call.
> I think the problem is closing the window shuts down the screen link but not the whole pairing session, but people don't realise they need to separately end the call.
Ah hah! This is totally it. Closing the screen share does not end the call (intentionally). I can decide I don't want to see your screen any more, but still want to talk to you. Definitely a debatable design decision, though. It actually used to work the other way.
They doesn’t really seem like a bug then, it should be possible to close the screen sharing without ending the call. Maybe you want to continue chatting.
I adore Tuple and my team used it really effectively. It’s the best tool out there for remote collab as far as I’m concerned. And with a colleague on a 4G connection the way it’s economical with bandwidth is really appreciated. But we have a few teammates on Linux and we just had to drop it. Is there any possibility of a Linux version?
I just about closed the window and dismissed you entirely based on this on the pricing page...
Do you support Linux and Windows?
Not yet! We're Mac-only for now. If you'd like to hear when we launch support for those OSs, please drop your email in this form.
If you have something in beta or coming soon, you should update it to send people to that more actionable link instead.
I've been working at pairing culture companies for a good number of years now, initially in-person, but then increasingly remote with offices distributed in several cities. Tuple was such a great find, even in the earlier times when sometimes we had to wait for connections to establish (presumably from rapid growth/adoption). It is still amazingly good at what it does and each little new feature seems to be reading our minds about bothersome things. It's a clear sign that it's used internally and also that feedback is really used. I always try to fill out the end-of-sesson form/rating if I have anything specific to comment on.
The best improvement was the clunky 'observer'-party that wasn't easily able to become the 'driver'. I think I actually received a reply on that one, plainly stating that it's a well-known issue that's being actively worked on, and not long after it began working seamlessly. I was about to ask about shortcuts, as moving the mouse to the menubar to temp-mute (or hang-up at end of call) can be a bit awkward if your screen is the one being shared--I just looked and there are Hotkey settings, just no defaults. Great stuff.
There used to be some issues where leaving Tuple running for days/weeks(?) sometimes could have it consuming CPU while idling. I don't recall the OS-version specifics, but I've got into the habit of exiting and restarting it every day or so. The problems may have been fixed but I haven't tried leaving it running to find out. If there's a way of submitting diagnostics specifically for these sorts of issues, I'd like to know.
It all it's as close to a perfect product as I use on a daily basis. Even with one team member's internet that can get slow at times, dropping to 1080p makes the text a bit chunky but still readable and able to follow along.
Tuple is great! It would be crazy cool if we could share multiple screens at the same time. What could be cool as well is if I can share a viewable only screen to the person I'm pairing with while they share with me their regular tuple screen.
Also, Tuple is waaay better than what we use when interviewing people with. Maybe some sort of hot seat feature where we could get people to download Tuple and interview/pair with them there.
Looks like their faq under pricing says you can do this now! I wonder if it would work for interviews that have more than one interviewer? I might check this out for some of our needs too.
Looks very cool - first time I've heard of this one. Minor feedback note: in your demo video, the top menu bar is mostly cut off (viewing on Chrome on Mac M1 Monterey), so when you are explaining the menu bar, I can only see the bottom sliver of it. I can use my imagination to figure it out, but ideally the video would be showing the whole menu bar. Other than that, looks great!
The toolbar looks cut off in the demo video - this is what I see when the presenter says "you can see the icon has gone red" (cursor is from the video): https://imgur.com/UzpbGxS
Indeed! The bulk of the work to support Linux has been separating out a cross-platform real-time engine that the UI layers of each platform can plug into. Toppling the Linux domino will make Windows much easier.
