Microsoft touts real-time over-the-network pair programming in Visual Studio, GitHub ships it Microsoft and GitHub on Wednesday announced real-time collaboration in their respective code editors, almost as if they'd been collaborating. Microsoft offered a placeholder rather than a product. Said program tools director Amanda Silver: "We’re working on 'Visual Studio Live Share,' which enables developers using Visual …
> Pair programming: perpetually training uninterested developers.
Then you are doing it wrong (or you have the wrong people as developers).
> Gobby
Does it allow me to share a debugging session from one editor (VS Code) with someone else using a different editor (Visual Studio)? Because this is not just shared editing.
>Then you are doing it wrong (or you have the wrong people as developers).
The same could be said if you can’t write code by yourself and then meet witth your team members to review and discuss about it.
But “doing it wrong” or “having the wrong people” are fake arguments because you are basically asking for an ideal situation, e.g. that a team have the same kind of people as developers.
> too many cooks ruin the pot
We tried this idea at one of my previous employers - pair programming. It was all the craze in the late '90's / early 2000's.
Think of having someone you don't necessarily like breathing over your shoulder while you're trying to think. Because of workspace constraints, he/she is well inside your space. And he/she makes comments. And he/she has suggestions on how to make code that hasn't been written yet better. He/she can read your thoughts ahead of you. He/she knows that you will be wrong 1 minute and 13 seconds from now.
After two weeks of this brilliant an innovative way of getting on each other's nerves to the point where changing careers and becoming a pest exterminator sounds like a viable option, half the programmers threatened to quit. That was the end of this ground-breaking experiment.
If I need to ask someone a question, I send them an email, or I RTFM. Not necessarily in that order. RTFM first is always better.
So damn true. Or: perpetually being not responsable for the code you write.
It’s sign of the times, now they have kids in elementary school all sit together around a large table to learn as a group. Independent learning and thinking (solo flight of thought), is going to be a skill of the past soon.
This is old, well-documented MS behaviour:
1. competitor ships product
2. Microsoft announces they are working on the same, but more expensive and with "Microsoft" written on it
3. Easily impressed PHBs decide to wait for the Microsoft one because nobody ever got fired for buying Microsoft and what's even better the MS salesman might give them a free pen or - if they get really lucky - a key chain
Setup a graphic devenv on a remote VM and share destop with Skype.
One person leads generally, can take over occasionally and when you want you can swap roles.
Used to do this as a matter of course for non trivial merges, so the author of any bit of code can always merge in their own bit if there are conflicts.
No magic tools required.
It becomes obvious that the commercially exploited development tools have reached their current limit if companies suddenly try to sell us this kind of crap. Because who in their right mind would use anything like this?
It's already difficult to administrate a larger team project because although you expect every programmer to do their best to send in flawless code, the reality shows us that everyone can make a mistake. The larger your project grows the more important quality checking will become. And even then most project developers prefer that others (so devs. other than the coder(s) themselves) go over the code manually because humans can often spot certain hiccups better than automations.
This is also one of the reasons VCS can be so extremely invaluable because it allows you to pick out every single commit to check it out, and also apply full control over it. Something tells me that this kind of failsave won't be part of this monstrosity. At least not the first releases because... If you sell people a fully working product then what's left to sell them at a later time?
Sure; if you use this system to get someone else to go over your code to spot mishaps then I'm confident that it'll work and can become a valuable tool. But that's not pair programming, one person wouldn't be programing but merely quality checking.
But to actually program on the same thing together both participants would have to know exactly what the goal is. So: the initial programmer would first have to explain the goal, how to reach it, what to do and what not to do (for example: with Java you'd either want getters and setters or not, or you want private's because this will be stand alone or you recon that it might become part of something bigger so lets go for protected instead) and then also you'd have to divide your tasks. Who does what?
So my dilemma: wouldn't all that time spend on getting the coding strategy explained be much better spent on the actual coding?
I wonder how long before we can see this scheme used to excuse ones coding mishaps.. "Yes, the code was crappy as heck but it wasn't my fault. My coding pairing buddy made a mess, not me. So you shouldn't be criticizing me (even though I sent in the code in the first place)...".
I'll stick to vim for now :P
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
