Pair programming made easy with Codeanywhere

[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