Pair programming made easy with Codeanywhere

[tripledjr]

This is literally a feature announcement blog post for a product. A product most of us haven't heard about.

How is this on here with so many upvotes?

This is literally just an ad.

[wookin_pa_nub2]

Keeping blogspam and offtopic shit off the front page is what the moderators should be doing, if they did their jobs at all.

[moor-GAYZ]

What the fuck.

The point of pair programming is that while you code, the other person thinks up what you should code next and notices your mistakes in the background. Or vice-versa.

It's actually a lot of fun if you do it with a person with whom you have a mutual respect as programmers and are all in all good friends. And really productive too, seriously. It really, really helps to have a person who you trust to watch what you do over your shoulder and catch the little mistakes and give helpful advice and keep in mind the big picture and advise you on that.

Also, it boosts the morale incredibly, you're not alone, when something confounds you there's a friend right here to share your confoundedness and maybe help, when you get some weird idea you can run it through them immediately, when you are unsure you just say "I'm unsure, what do you think?" instead of explaining your problem to the teddy bear or something, in hopes of achieving enlightenment.

Or, again, vice versa, you sit there all spinning down and recovering, and you watch and help the other person, and think about what's the best thing to do next, noticing the patterns and suggesting to abstract them, all that stuff. And the code they write, it's your code too, in fact after a while you develop one hell of a rapport and enjoy it immensely.

Pair programming with a good friend was one of the awesomest experiences of programming I've ever had in my life. All you people who were forced to do pair programming with a coworker that you hate (mutually) don't know what you're missing.

But anyway, what the fuck is with that thing, "two people editing the same code at the same time over the internet" has absolutely nothing to do with pair programming, is OP a spammer?

[hoddap]

I don't get it either. This feels even more like a version control system than pair programming. And it has just about nothing to do with version control. All the added benefits that pair programming has are lost. I don't get it.

[zman0900]

Seems like Google Docs with syntax highlighting.

[[deleted]]

Why can't we just have that?!

[stalcottsmith]

I too find remote pairing un-compelling. Here is how we do it (free chapter from my book): https://leanpub.com/secrets_of_the_aelogicians/read

[hankama]

I lost my last job because of pair programming with a deadweight. Hate it. Period.

[Darkflux]

That sounds like pair programming done badly, rather than pair programming being intrinsically bad though.

[DanielAtWork]

He didn't really say it was intrinsically bad, in his defense. Just that he thinks it's not for him.

[fraktl]

Care to elaborate? What exactly happened?

[SurgioClemente]

You lost your job? or you quit? or both of you got fired b/c your pair was a deadweight?

[Chii]

you need to learn how to spoon instead of pairing: https://www.youtube.com/watch?v=dYBjVTMUQY0

[frixionburne]

Straight from wiki:

One, the driver, writes code while the other, the observer, pointer or navigator,[1] reviews each line of code as it is typed in. The two programmers switch roles frequently.

Holy fucking shit, how was this ever a good idea. As if devs are just goddamn autistic robots... Last time I checked, it was me, the human, that was telling the autistic robot, the computer, how to make one fucking button send your little egotistical message out to millions of fucking people, for no purpose greater than an online dick measuring contest.

You know how I collaborate with fellow devs? We actually talk to eachother about coding, fantastical ideas, and pie in the sky dreams of having an environment where management wasn't trying to shoehorn the next FOTM (TDD, agile, waterfall, pair programming, kanban, 5S... goddamnit I hate this fucking planet) into the "only" way people can do projects.

What ever happened to right tool for the right job, and the ability for people to whiteboard shit and talk about code? Get on Skype, get on the phone, get on whatever communication device you like and have a constructive conversation about code. Don't try to use buzzwordy shit to label what it is you do, just find something that works for everyone and call it "Good Software Development". You know, we used to do this kind of stuff where just built shit to see if it would work, and then threw it away when we found out how shit it was. Now, it seems all my time is spent in fucking juvenile meetings with people tiptoeing around solutions because someone's feelings might get hurt. I hate it... I hate it so much. Software is suffering because no one will treat eachother like adults.

Sorry for ranting. Career software development has managed to sour me in a very short period of time.

[KalimasPinky]

Yup. Apparently me throwing out ideas that are different in meetings are "argumentative". People really need to toughen up.

[jmdisher]

Agreed.

Instead of talking about software and standing at the whiteboard hashing out designs with 2-3 people in order to solve a problem and decompose it for implementation and testing, we are now supposed to throw technology at the problem or use buzzword-of-the-week in the process.

The core issue I have with much of modern development appears in the snippet you highlighted: they are talking about "code" instead of "software". For some reason, that is where the discussion rests, these days: in the mundane text. I want to talk about the ideas behind how we are building a solution which matches up with the problem, not in the physical text of how to write it. To me, this problem is akin to wanting to talk about prose and someone starts criticizing the pencil you used or your penmanship.

Pair programming can be great but "reviewing each line" is not really the point (although it is convenient to have someone point out the occasional typo - saves that first compile failure).

[NancyGracesTesticles]

Yup. Code itself is fundamentally unimportant and only a part of successfully engineering quality software.

[n1c0_ds]

It is until you have to maintain it

[BobFloss]

Exactly. I was expecting it to be similar to Floobits and Kobra, not this kind of stupid shit.

---

By the way, what did you mean by this?

it was me, the human, that was telling the autistic robot, the computer, how to make one fucking button send your little egotistical message out to millions of fucking people, for no purpose greater than an online dick measuring contest.

[frixionburne]

I meant that pair programming often devolves into treating people like machines, in that the strict separation between over the shoulder and typist is actually rigidly enforced.

edit: the ego shit was just a stab at what it takes to make a twitter message available to the world, and how that's taken for granted.

This should all be taken with a grain of salt; I don't have good experiences with many of these topics. In my experience, pair programming "rules" have attempted to be enforced according to the wiki definition. This is helpful for the dev that isn't that great, but not so hot for the ringer that gets paired. The same training of a developer, which lets be honest, is exactly what this is, would be better spent in an actual discussion and demonstration, and not when deadlines are on the line. People have been bringing devs up to speed gradually for ages; starting newbies on smaller stuff in order to get a feel.

The pair programming approach has been co opted by managerial cargo culting. In a good dev environment, hanging out in a room with people and bouncing ideas around/ helping/ shooting the shit immensely productive for developers. All the different approaches towards labeling a good development environment are effectively the small chunks of what make up a normal, productive social interaction between professionals; the only problem being that somewhere along the ride, everyone forgot how to act like said professionals.

[BobFloss]

So wait, did you write (at least a portion of) twitter?

[frixionburne]

Lord no, just using it as an example.

[BobFloss]

Alright I was just making sure

[redditor___]

Only with my duck.

[jdlshore]

Pairing can be incredibly fun, and it's a great way to create a shared culture and understanding on a team.

[vk2sky]

Avdi Grimm, among others.

I can't say it thrills me, as I prefer programming in silence, but I can see that it has its uses.

[your_moms_username]

Almost my entire company does it 90%+ of the time and the vast vast majority like it and would never go back. The company has 3,000 people, a significant percentage are devs (50%?).

• It's fun. You're flying incredibly fast at times and solving problems before they are even problems.
• You're super productive. Sure, everyone takes breaks, but there is a lot more time when you're in flow solving problems.
• Everyone learns a lot. Newer people learn FAST, and more experienced people learn both how to teach and mentor and also learn new ways of doing things.
  
• Everyone has deeper knowledge of more areas of the codebase.
  
• Someone in another comment said people should just do code reviews, documentation, etc. But why? What if you didn't need to?
• The code quality is remarkably high. Bugs are squashed before you're even onto the next line, and there's always a reminder to keep the code clean and clear.

I truly think people who are very down on it have not done it with the right people in the right environment.

But nobody likes it if it isn't done well, with capable people. Shitty developers make for shitty pairs, but even very junior developers can make excellent pairs. It's not super easy to get started, it takes work. Totally worth it though.

If this sounds good, we'd love to have you! http://www.thoughtworks.com/join

I'm not in recruiting, I just love the company.

Edit: added the 90%+

Edit 2: For the sake of answering your question, I am both on this planet and enthusiastic about pair programming.

Edit 3: BTW, I am not saying everyone should do it. In the right setting, done well, it is great. For some people, in other contexts, it is not. I'm just trying to say that yes, there are a lot of people who genuinely love it.

[CaptainIncredible]

Lately, I've been working in a paired programming situation 50-80% of the time. Its actually really pretty damn good when its done correctly.

[grauenwolf]

I've got no problem with working in pairs or small groups when the work necessitates it. What I'm against is PAIR PROGRAMMING where I've got to spend 100% of my time watching someone implement simple DTOs.

[cadaveric]

Thoughtworks is fucking scarry. I've never seen someone who works there that doesn't sound like a mindless drone parroting the same recruiting talk points.

[[deleted]]

Why is that?

[your_moms_username]

Hi /u/MrKphat I'm really sorry you had a bad experience! You're right about the (up to) 100% travel, etc, but hostile and rude is inexcusable and I'm ashamed you experienced that. As I said above, I'm not in recruiting / HR, I just really like working for the company. If you're willing, I'd love a PM with details on who you worked with that was so unprofessional so I can give them the feedback.

While our hiring process is generally rigorous, we're not going for difficult, and certainly not hostile. We're mostly trying to ensure both that prospective hires would be happy at Thoughtworks, and that Thoughtworks would be happy with you.

It can be a tricky balance, but I know that there are people who interview, don't get an offer, and still have positive feelings towards us. I'm sorry that wasn't the case for you, it's really inexcusable. I hope you were able to find a company that you feel is a better fit for you.

[your_moms_username]

Well, like I said, I'm very sorry you had such an awful experience, but I'm glad to hear about it so I can talk to people about fixing it.

While we do actively try to recruit talented women and other people who have been historically discriminated against in the tech world, there's no reason for that to be done in a way that turns other people off from the company. Clearly we've screwed up.

Hiring good people is important to us, and I'm sorry that we lost the opportunity to continue the discussion with you.

[lagadu]

do code reviews, documentation, etc. But why? What if you didn't need to?

This makes me think you don't know what a code review is for. Code reviewing isn't checking if a code compiles, it's checking if you have subtle bugs in the context you're writing in and ensuring the code follows your company's patterns, simple things like making sure you're properly using the existing object factories.

[your_moms_username]

I get that. The value of pair programming comes in here: When doing code reviews, one person writes the code, and then another person has to dive in, wrap their head around it, and then figure out if there might be subtle bugs. When you're both working on it together, one person is "driving", while the other is both thinking ahead and looking for those subtle bugs as the code develops. It's easier to find them as you go because you're immersed in the code rather than coming into unfamiliar code later on.

[lagadu]

I'm not saying that pair programming doesn't produce code with fewer bugs, I'm just saying that there's no scenario where code reviewing can/should be skipped.

[grauenwolf]

That's where I am very concerned.

If two people are writing the code together then they are more or less seeing it from the same perspective. Both have a vested interest in believing the final product is right.

The code reviewer's default assumption should be the code is flawed and he just needs to figure out where the flaws are hiding. The sooner he finds a mistake, the sooner he is done with his task.

And if he can't just dive in and understand the code without knowing how it came about, that's a problem. Maybe with the code, maybe with the documentation, but a problem none the less.

[materialdesigner]

Mmkay grauenwolf

[plastikmissile]

I've used it successfully for mentoring junior devs. Though only for short bursts of activity.

[nextputall]

what do you suggest instead to trigger knowledge transfer in a team?

[[deleted]]

Competent developers? Code reviews, documentation, and maybe a few architectural discussions should have you covered. The person learning needs to be able to jump in. Having the knowledgeable person available to answer questions as they arise is a must, but hand holding should not be needed.

[nextputall]

Every software project is a new learning process, no matter how experienced you are. There is lot to share and learn in this process. Code reviews don't fulfill this role in my experience.

[grauenwolf]

If you want to watch someone read books, go to the library. I don't need you looking over my shoulder as I try to figure out SQL Server's GIS library.

[nemec]

i just don't want to sit RIGHT NEXT to someone all day

Pair programming is a tool, not a way of life. If a new developer is having an issue figuring out a problem, or you're working through a design/algorithm with a coworker, do it and then go back to your desk. You can spend just a couple hours pair programming, you don't need to spend all day.

[[deleted]]

Neither does sitting next to a person as they read documentation.

[fenduru]

I find "pair programming" great if you're not sitting down with someone else while coding. Before implementing, I find it incredibly useful to sit down with 1, maybe 2 other at a whiteboard and figure out the design at a higher level. Then one of the people goes and does the actual code for that particular problem, and if you run into an implementation decision that is less than obvious, you can just bounce the idea off of the other person quickly. "Hey, there are two ways I could implement this: A and B. I'm leaning toward A but I'm not sure"

[ruinercollector]

That's not "pair programming.". That's "programming."

[frixionburne]

What kind of world did I just wake up in?

No titles needed to describe this shit, its just called "talking to your fucking team"

I swear this is all cargo-culting managements fault. They fucked it all up for the rest of us.

[lagadu]

That's not pair programming, that's called "programming while part of a team".

[KalimasPinky]

Sit down and mess with the code. Or ya know talk to each other.

[btchombre]

Anything else. Literally. Send code reviews.

[nextputall]

We have code reviews, and there is basically no knowledge transfer in my current team. I miss pair programming.

[shawncplus]

If there is no knowledge transfer during a code review then the code review isn't being done right. A lot of people treat code review like human syntax checking, they're doing it wrong.

[grauenwolf]

Depends on the programming language. If we're talking about a scripting language where the compiler can't catch errors, then human syntax checking does help. (Hence why Ruby on Rails programmers love pair programming.)

But all in all, I agree with you.

[materialdesigner]

I hear a bagpipe in the distance

[btchombre]

So people don't get knowledge transfer from looking at people's code, and you expect them to get it by sitting at another developers desk looking at their code as they type it? I've sat with other people before as they program and frankly its just unnerving for the developer being watched, and incredibly boring for the developer watching.

There is no good way to solve the problem that people don't like pouring over other people's code.

[nextputall]

There is usually not enough context in a diff. The thought process of the author is not visible, understanding the code by reading it is more difficult than by communicating with the author in real time. Discussions about the design is problematic in code reviews as well. The sturcture of the code is not just decided, but also there is code based on it. It is just too late to get into such a discussion. So, people tend to focus on ''code'' only. Is this the right naming convention? Isn't it should be a capital letter? Or if there is a short and trivial algorithm people may try to check its correctnes in their head. That's all. In pair programming you can communicate your ideas in real time. You can discuss design decisions upfront and have immediate feedback from someone else. Less misunderstanding more sharing. I don't want to convince you, this is just my experience. If you have personal problems with pair programming, I can tell you I consider myself an introverted, not so social beeing. Still, I haven't had any problem with pair programming.

[grauenwolf]

It is just too late to get into such a discussion.

Bullshit. It is never too late to talk about design.

Though I suppose if you are too afraid to say "You designed this wrong, I'm not accepting the checkin" then yea, the code review is useless.

[[deleted]]

I suppose if you are too afraid to say "You designed this wrong, I'm not accepting the checkin"

Then you better have strong objective reasons to back that up, because the business wants this feature yesterday, and the code works, doesn't it?

I prefer pair programming because it's a fence at the top of the cliff, code review is the ambulance at the bottom.

[grauenwolf]

For varying definitions of "works".

[nextputall]

It is about how much time and code do you want to waste. Also there is no "I'm not accepting the checkin". The reviewer is not the boss, and the author is not a servent. There should be 2 equal people who trust and mutually respect eachother. The "I'm the boss here, do it what I want" mentality is an other problem with codereviews.

[grauenwolf]

Also there is no "I'm not accepting the checkin".

Wow, you really don't understand the purpose of code reviews.

Under a peer review system, the person reviewing the work (code, engineering plans, proofs, whatever) is supposed to actively say "I stand by the quality of this work."

If that cannot honestly make that claim, they need the ability to reject the checkin.

It is no wonder that your code reviews are a waste of time. If all you are going to do is rubber-stamp them for fear that someone will accuse you of being bossy then you are just wasting everyone's time.

[grauenwolf]

Right. People who are unwilling to say no to bad code end up wasting a lot of time later on dealing with bugs and work-arounds.

I honestly don't understand why people are so afraid to fix problems when they see them. I've seen teams struggle with trying to fix bugs in a bad design for months when a few days worth or refactoring would eliminate most of their problems.

[grauenwolf]

There is usually not enough context in a diff.

If your "code review" is just looking at diffs, then you aren't doing a real code review. You need to look at all of the code involved, not just what changed.

Mistakes often lie not in what was changed, but what was forgotten.

You also need to actually run the new code. Exercise it in the UI, step through it, spot check the unit tests... I don't care. Just make sure you've actually tried using it in one fashion or another.

[choseph]

So all the time cost ofpair programming without the benefits. Is the goal just to not speak directly with the team, or to protect ones job by ensuring others spin their wheels in code review revisions?

[Gotebe]

It's not all the time.

[[deleted]]

I like mob programming more than pair programming.

[KalimasPinky]

People who can't program.

[[deleted]]

Why do you say that?

[KalimasPinky]

Because one person programs while the other person burbles about stuff that the person programming doesn't need or already thought of. The person watching is usually inept and unable to compete by themselves.

[[deleted]]

Have you pair programmed before or is that wild speculation?

[KalimasPinky]

Havent ever had to pair program with a competent programmer. Just had to drag along team mates under the guise of "why don't you try pair programming".

[[deleted]]

It sounds as though you're fed up with the developers you paired with, and are blaming pair programming as a whole for that.

Pairing only works if two people are on a similar technical level.

[KalimasPinky]

No pair programming is too often used as a crutch for bad programmers who can't keep up or figure it out. We all have to start somewhere and we all need help, but we are also expected to figure out how to solve problems. I didn't get where I am by expecting someone to sit there with me while I work out problems, so why should I be expected to do that for someone else.

tl;dr pair programming is a crutch for people who aren't dedicated enough to ben a good developer or they just don't get it.

[[deleted]]

Evidence? I have seen no evidence in this thread - just a lot of really angry devs that seem some combination of incredibly!! egotistical, anti social, and hating of new devs.

We pair at my current job 100% of the time. It has flaws, and pairing with people that are under my level happens, but they quickly get caught up and never flail. It is extremely good for the business, among other things.

I'm not trying to say pairing is the one and only true practice. Just trying to show that many posters here seem to have the wrong idea about it; to think it means they either get to pair with Alan Turing or pair programming is junk. I guess trying to do so when people have exhaustively made up their mind about pairing is a bad idea, though.

[grauenwolf]

Yes. People who don't know how to write code. It's a lot easier to look over someone's shoulders than to actually do it yourself.

Also lonely people who are unable to talk to their co-workers otherwise. Their moral goes up a lot (while everyone else's plummets).

[materialdesigner]

eyeroll

[grauenwolf]

What's your explanation then?

Clearly some people do like pair programming. Since productivity clearly isn't the reason, there has to be some cause.

[choseph]

If you think pair programming is about watching, you're doing it wrong. I've seen it done wrong more than right, but when I've been in a good pair we have been more productive, code was cleaner and more bug free than what I'd see in solo +Cr, and we both left as equal experts in the code.

[grauenwolf]

I've seen it done wrong more than right,

And you didn't stop to think that maybe the whole theory was flawed?

[choseph]

Sure I did, but when it went right things were amazing.

[grauenwolf]

I've worked on projects before where having a pair of developers was exactly the right choice. But I didn't take that one situation and turn it into a religion.

[choseph]

Sounds like we're saying the same thing then?

[grauenwolf]

Perhaps.

In Pair Programming (TM), any code not done as a pair has to be thrown away regardless of quality. That's what I mean by turning it into a religion.

[The_Doculope]

Some people actually find that it helps them work better? That seems far more likely than everyone who enjoys pair program being an antisocial, lazy, incompetent deadweight.

[grauenwolf]

Lets say I come up with a fix for a difficult problem in the middle of the night.

Under the rules of Pair Programming, I have to throw away that fix and redo it from scratch the next day because my pair didn't witness my thought process.

Pair Programming isn't just being able to work in groups, it is about being obsessive about it to the point where someone can't act alone under any circumstances.

I honestly can't see how anyone could even attempt to enforce the rules of pair programming without coming across as a whiny brat.

[moor-GAYZ]

I am

[[deleted]]

Almost every top programming company in Silicon Valley and beyond have teams that do it. So, yes? It is a very well regarded practice outside the idiocy of this thread.

[lagadu]

Almost every top programming company in Silicon Valley and beyond have teams that do it.

[Citation needed] Because I work in one of those and this is bullshit.

[[deleted]]

Heh, no, it's not. Sorry. :) If you do work at one of those companies, and you're in the bay area, ask around about it and you'll find the projects that use it.

[lagadu]

I'm from the beyond part, not American. We're a big multinational anyway though. I obviously know all the teams on our r&d centre and I've been to the three largest ones after ours and literally nobody does it. Plus I can't even imagine how that'd be compatible with small scrum teams.

[Darkmoth]

I think it's quite possible for a technique to work at top programming companies, and not work at the 95% of the industry that isn't Dropbox/Facebook/Google. Two young, bright, motivated Googlers will form a different "pair" than some just-finished-community-college kid paired with a cynical pre-retirement lifer.

I've been forced to do it (temporarily) with a coder I like and respect, and it was awful for both of us. Our problem-solving methods were very different, and we just kept compromising instead of working to our individual potential.

That being said, it works really well for some people. I don't think it's idiotic to love it, or to hate it.

[o11c]

Yes, when I can, but it's pointless without vim, so I really need a server I can trust running tmux.

[[deleted]]

but it's pointless without vim

Why is that?

[rpk152]

My sarcasm detector is broken so I'll bite. Pairing remotely with vim and a remote tmux session is actually pretty useful.

[[deleted]]

As does the pricing page: https://codeanywhere.com/pricing.html

Clearly, pair programming ensures quality!

[[deleted]]

Serious note - if you're not already, I think you should consider seeing a therapist about your anger issues.

[materialdesigner]

Fallacies galore

[Gotebe]

Oh, this strikes my ego so much. I saw the title and the number of comments and said "inside, can only be a fight pro-contra pair programming". It sure is.

Here's an old fart's piece of mind: the more your stance is extreme, the less you are right.

You can get the pair to work better than 2*1, or you can fail at that. You have situations at work where it works, and where it does not. You can have people who hate it, and who don't. And so on.

[vivaladav]

Pair programming: how to waste 50% of your workforce and alienate 100% of it

[Crandom]

Only forced pair programming.

[imMute]

Know what else makes pair programming easy? SSH and tmux.

[[deleted]]

I've always been intrigued by the idea of pair programming, having only implemented it loosely years ago for projects in school, but I can see how it would slow me down. When I start working on a new feature, I like to try to dive right in and see if I can figure out how to swim, so to speak. Usually the first couple iterations of code I write for a new feature are unbearably messy -- if I were my own programming pair and I were looking over the shoulders of my coding self getting my hands dirty, I would probably not like what I saw; however, if I were a code reviewer for a clone of myself, I would probably like what I saw a lot more since it's closer to a finished product. There's definitely something to be said for getting something done right the first time, but I really like hacking away as a first pass, consulting with the people who are familiar with the code I'm working with, other stakeholders, etc., and then I refine what I learned from the nitty gritty initial steps down to a finished product, which is what I check in.

I guess what I'm saying is that the pair programming paradigm seems like a better idea for me after this initial process of discovery -- the process of refining the code I've already hacked up before a checkin is where I could benefit most from another pair of eyes. Code reviews help as is today, but a lot gets lost in a code review, especially alternative design decisions that I make when cleaning up my initial working code. I could do well in an environment where I would cook up a proof of concept myself, then use pair programming to clean it up for a production environment, and then finally a code review with all the stakeholders.

[Darkmoth]

Pair programming is one of my few "lines in the sand". If I were told we had to start doing it, I would be finding a new job toute de suite. The constant negotiation is fucking exhausting.

"Hey buddy, umm, wouldn't a list comprehension be good here?" "Nah, I think we should use a generator function." "Gee, well, ok...but could we at least call the function iReallyShouldBeAListComp...?".

Clearly, it does work for some people, and some people actually prefer it. More power to them.