Edit Page

This is a heatmap of the distribution of students taking the edX CS 169 Software as a Service course who responded to a survey on remote pair programming


Here is the same heatmap but weighted as a function of self reported hours per week spent remote pair programming by those students.


And again the same heatmap but this time weighted as a function of self reported number of remote pair programming sessions attended by these students.


Below are the anonymized qualitative responses for each of the long answer questions from the survey:

TODO: sort all groups below extracting similar sentiments into categories with counts

First remote pair programming experience
  • The event creator was very good at keeping the task focused. All people who took part had already done homeworks, so it was actually a check and a verification.  I had trouble from the lower resolution of my notebook (it was not always easy to read other people' screen), from my difficulty to speak fluently english, and to understand it as well (I'm a bit hard of hearing). Later I was frustrated when during pair programming was required googling. (196) [clarified with student: "I thought homeworks had to be done before and people was supposed to take part to pair programming with clear thoughts about how to do things. So looking at someone doing web search looked quite a waste of time."]
  • Waste of time. Lot's of talk, less than 10 lines of code as a result. (192)
  • I couldn't do remote pair programming because of net problem (187)
  • AWKWARD AT FIRST as time went on it got smoother and seemed more productive (179)
  • Never really figured how it works. Couldn't find any useful session when I needed it. No one came to pairing event when I created one. (178) 
  • Worked with a knowledgeable individual and it was very informative for me, and I think I was able to contribute as well. We finished the homework and worked professionally. (168)
  • Never happened: I don't like other people. (158)
  • I only participated in one programming session and it was a mutually beneficial experience. It was good to watch others (I learned tricks and little syntax notations that I wasn't familiar with before). Also, I had an idea of how to approach a problem that helped another solve the homework. The reason that I didn't continue was because I didn't feel confident in my programming abilities to be able to 'remote' pair with someone. Perhaps this is something inherent to me, but I feel like I need to 'know' 80% of the homework before I can enter a pair session. (152)
  • This was for HW0. It was a little awkward getting the hang of the technology for the session. We started as a group of three but eventually had four people show up and split into two groups. The group I was in only got about halfway through the homework before it got too late, but we were productive during this time and I believe everyone viewed the session as a success. I was the driver and I certainly benefited from the input of the other participants, who usually had a solution when I got stuck on some bit of syntax. (149)
  • It was nice. We enjoyed. (141)
  • Great experience. The second pair of eyes can spot obvious errors which one is blind to see. (137)
  • "Great thing, want to use it as often as possible (135)
  • Good experience. Lot of sharing ideas. Encouragement, Brain storming, Highly productive, got more things done than possibly imagined. Discovered my own strengths and learned from others by doing. (127)
  • During one of the early homeworks I worked with a Spanish guy living in Finland. It believe it was HW1 (pure ruby). We quickly completed the assignment despite the distractions of other people logging into the Google Hangout and not knowing how to use the Google software because it was their first attempt at pair programming. All in all, many distractions but I enjoyed seeing someone else's approach and definitely learned some new tricks from it. (126)
  • I created a hangout. 3 people responded and 1 actually turned up. We paired up and he drove, since he had already made a start on the project. We didn't use any video, just screen share and audio (116)
  • Memory game in java, monopoly game in c++, scrable game in java, poker game in java. (103)
  • Very easy, I use remote desktop programs like TeamViewer. (99)
  • I was too scared of my lack of programming prowess to have it publicly compared. (98)
  • Hi, my first remote pair programming experience was good, and very intective . I had fews information. but after got stuck on ruby and rails session I decided to wait for the next open CS169.1 course. (94) 
  • my first pair programming was in a company with another employee, in the first week i was there. I had to see how he worked to learn the way of doing the tasks. (93)
  • Trying to create php code to communicate with a MySQL database when working at MySQL. (85) 
  • My first pair programming experience was for saas.  I set up the class machine on AWS, installed tmux, wemux, and vim, and cloned my vim configuration files from github. The webcam & mike on my computer are broken, so we just used irc to talk. My pair was someone I knew from previous moocs. He's a professional programmer but had never paired before. We took turns "driving". Generally one of us would do a problem, then the other would write tests for it; then we'd swap for the next problem. It was interesting how often we were able to catch one another's syntax & logic errors right away. If there was syntax neither of us remembered we'd both use google and/or a repl on our local machine until one of us figured it out. There was some confusion when we both tried to take the cursor, but we eventually got used to explicitly asking for control. He didn't like some of my vim keybindings though :). Overall it was very fun. (84)
  • My first remote programming experience was strange. Was in there with people I've never talked with, there were many in the session and were like divided into groups developing different parts of a homework.(80)
  • It was not quite as productive as I had hoped. There were 4-5 of us in a Google hangout, and there were a lot of technical issues. At first, my screen wouldn't share. So I logged out and logged back in. Then Mike's screen wouldn't share. So he had to log out and log back in. Then it was OK. We were all stuck in sort of different places, and it was kinda hard to help someone debug without physical access. I would say things like "did you run bundle install" and "did you do rake db migrate" and he would say yes. (78)
  • It was good, but not as enriching to me because I lacked the Ruby and Rail knowledge to be able to focus on the problem and not the tools (reading API's, tutorials...). We were 4 of us but some leave at the middle and some other came latter. We did not use voice, just the chat. (73)
  • 10 min: people arriving late 30-45 min: getting setup. Getting google talk to work for everyone. Showing people how to share screens. Canceling people's mics. Coding. People taking pictures with the google hangout camera app. Getting some things done. People leaving. (64)
  • I was an intern as a company working with .NET framework. It mostly involved me being walked through DDD and the different 'layers'. Very passive. (61) 
  • It took a while to get up and running. There were maybe 4 people who joined, but it quickly turned into a session where it was just me and one other person. We made a little progress, but the assignment was pretty difficult, so we were unable to complete it. Still managed to share my knowledge with the other person, and I learned a few things from that person as well. (60)
  • It was quite good. We swap the roles and we finish in half of the time I would need alone. (58)
  • first, fear - who will come, how to setup this; but also curiosity - who will show up; in end, joy, because it ended as adventure, homework done,  and human communication makes it more "real". Unexpectedly interesting. (48)
  • I tried to use pair programming in saas CS 169.1x but I don't understand by myself yet. So I didn't participate (47)
  • It was really an amazing experience. Thanx to edX. For initial part, I was the observer and in the later part I acted as driver. I felt wonderful to have worked with someone whom I never knew and in within no time, we felt like partners made for each other. My partner, he was really a patient and cool one. It was thrilling when I came to know that it was morning time for him and midnight for me. Being an observer in initial stage, I felt good of the Ruby language and how to make use of Documentation effectively and efficiently and especially the Ruby style of coding. (45)
  • It was a little difficult due to laptop being maxed out and trying to switch between so many windows. I just ordered a second monitor and more RAM, and will give it another try in 169.2 Oh and I didn't have a real headset, do now though. The hw we were working on in the hangout was on the easier side and I kind of already had an idea of how to do it so it was easy for me to follow along. There were 4 of us and at times more than one person was command your attention, but again since I already familiar it was too disctracting. (42)
  • here in course, by a group, was fun. solved problem together. (41)
  • Awkward. When I joined the first session there were already 7 people in the session but 2 people were really the only ones working/contributing. I tried to get some people to break out into another session but frankly there wasn't a good or easy way to do that. I ended up leaving after 5 mins and decided to create an event of my own for the next day. That one went better because we only had 3-4 people participating. (38)
  • A bit hard to split on pairs (35)
  • It was quite nice. I had the possibility to talk while I am working. I do programming quite a lot alone. So, this is new for me. It's like a forum in realtime. :-) (33)
  • I jumped into someone else's hangout for HW1.5. I couldn't find my mic at the time, so I was scrambling to type in order to keep up with the conversation, but my messages often weren't read for some time. Subsequent pair programming sessions with my mic were much easier. It was still useful, and a great learning tool, however I find (and continued to find) that it is a very slow and laborious process. It was much quicker for me to bang out the problem myself after I left my first pair programming session. Later sessions were again more useful, since I had become more experienced I was able to offer more help, and seemed to glean more from watching others. (31)
  • It was great. Nothing special to be detailed out but yeah it was quite a professional one to be precise. (30)
  • It was interesting and a little bit confusing. There were 4 of us, and one guy didn't have a microphone, which prevented him from participating more. Some other people showed up in the hangout but did not participate. As for the programming, it didn't feel much like pair programming, as in a driver-observer activity. It was more like a disorganized group programming. The hangout worked surprisingly well for screensharing, and we could comment on each other's code without any problems. However, I couldn't get the hangouts to work from inside the VM, it kept crashing, so I had to connect from my host machine and switch to the VM to code and then back to the host to paste something and so on and so forth, which has been annoying. It was also interesting to meet people from such different backgrounds, like a highschool student from Bangladesh, although his accent was a little bit difficult to understand. (29)
  • I learn more from peer even if I already have a working code solution (28)
  • It was very slow for all, because we was a bit shy. Then, when we had more confidence was more fluid. But we didn't do pair programming correctly, we done something more like to group work. (26)
  • The very first time was with this course. It was brilliant. For the first time in many years I felt really happy programming again. There were two of us, plus we had the assistance of one of the brilliant TAs (Mr.Jonez/Jones - From Boston, I think). We met up three times and worked together/helped each other out. One of the best experiences I've had in any course I've ever done, EVER! (25)
  • Like an internet chat, but every one is decent and talks on one single topic (24)
  • I had never done remote pair programming before this course however in person pair programming I had done before. For my first session, I created a Google hangout and a few people joined. I believe we were 4 in total. Once everyone was connected and ready to go (which took a long time) things started to move quickly. We went section to section one 'driving' and the others making their observations. We got the entire homework done in a couple of hours, much quicker I think than if we had done it individually. With others watching, they help you avoid the silly mistakes. (22)
  • Difficulties to use tool (hangouts) garding sound volume, video, sharing during 5 min  Difficulties, who must take the lead in the remote pair programming to rhythm the session (19)
  • chat-only on HW1.5 of 169.1 > was a bit strange at first but worked remarkably well because more then 1 session is possible and it gives the possibility to participate in multiple sessions. (18)
  • Preparation is key. Do not expect much os a remote pair programming session without being prepared. (17)
  • I was pair programming with fellow 169.1x student YA and we were discussing how to implement full tests for sorting a bunch of movies in the RottenPotatoes app. We had spent a lot of time trying to do it without success, until he made some random comment that got me googling different ruby methods and bam! A one-liner solution. (16)
  • I scheduled a pair programming session but had difficulty setting up a G+ hangout at first, as I'm not used to the platform. In the end I invited one of the students who had indicated he would be attending my session. I paired with an American living in the Puerto Rico who was very worried about being the weaker programmer. I reassured him that I was also a Ruby novice and that I hoped to transfer some of my PHP skills into my Ruby programming. I took the drivers seat and wrote the first 2 methods of SaaS HW1, my partner contributed by looking up method calls and syntax in a paper Ruby book he had to hand. I'm not very talkative, but my partner did stop me to ask questions and point out any errors or weaknesses in my code. When I offered him a turn to drive he got nervous and worried that he would slow us down, he insisted I drive for the remainder of the session. When the HW was completed we shared the code by copy pasting in the chat window and submitted to the AutoGrader. After receiving a passing grade we chatted a little and then signed off. (14)
  • 5 or six people dropping in and out, some lurking while two got after it and I was able to get a helpful screenshot or two as they progressed. Even though I was not at their point in the hw, and their code was not done, it helped to have something to look at later. I have no microphone, so can be frustrating. I joined late, they finished up in about a half hour later and everyone left. (13)
  • I joined the class a week late so was playing catchup the entire time. Everyone was always a few steps ahead of me, so I felt most of the work was done on my own. (13)
  • It was beneficial because both could learn some things from each other, but at some point I found out it was pretty boring for me. I had to explain a lot of things I did and at some times we didn't agree about how to solve something so the one that was coding just tryed his/her idea and the other one had to watch and wait to see if it worked. I think we managed to find out what caused the errors easier than it would be if we were working by ourselves, though. (10)
  • I did not know whether we will use webcams or not, but found out it is not required when I joined, I wasn't preparing the assignment. I thought that we read the assignment and think about it one after the next, but I found out other people in the session were well prepared, some of them had the code already written. ! I actually had to ask them, that I was thinking that we will do the assignments together as each one start dive into one of the problems and we loop throw them, as a real pair programming session, not just sharing our answers, and they agreed, and decided to start fresh. The session was really useful, we came up with different ideas and really nice code, that no one could do alone. I think each of us really came up with an idea in the code that made it much much better, which was something really nice. Overall the experience was really great and I learned a lot from it and looking to do my next assignments in pair programming as well. (8)
  • My first pair programming was with another community TA on a agile project. The other person has paired before. So, he was able to lead the session properly and involve me in the pairing.
    We used ping pong github and screenshare (7)
  • My first remote pair programming session was while conducting a google hangout for the programming hw1 of CS 169.1x, a course on SAAS offered by edx.org as a world TA. In this session i pair programmed with others for the homework which included basic ruby programs. (6)
  • If you ignore the fact that because of my anxiety to provide as good an experience as others had provided me, i could barely speak, everything else was pretty great. (3) 
  • i have been trying to know the exact time for the lectures but i could not that is why i give it up we need the time for the lectures to be post to our mail on on the home page of the course in GMT and the link for the live session so that we will know how to attained the and participate in the activities (212)
  • It wasn't good. Because we were to many inside one single google hangout. But after, I attended a real pair programming session, we were two. This was interesting to get another perspective about a problem which combined with mine give us better solution. (225)



  • Followed up with 196 who described pairing experiences at work 
  • Using screen on a Unix host. This is the method I used the most. 
    • In this scenario, both people would sign on to a common unix host.  One person would start a screen  and provide the credentials so that the other person(s) could watch the session or interact with the session.  This method allows both people to actually make changes during the session when it makes sense to switch control.  This method requires that you use an editor on the unix box like vi / vim, which is not always efficient.  It worked well for me.
  • Using screen sharing on google+ hangouts, fuze
    • We used this method most of the time for training, but also for pair programming.  It allows you to use a GUI editor.
    • We also used this quite often for the daily 15 minute meetings with the team so that everyone could see the rapid board with the work actively underway.  I hesitate to call it scrum, because we didn’t have a scrum master.  We had a project manager who led the meeting and then a group of programmers and QA engineers.
  • Sitting side-by-side if you happen to be in the same office
    • This uses whatever GUI the pair decides is best.


Any other thoughts on remote pair programming sessions and how they are connected to MOOCs like edX 169?
  • Would prefer the MEAN stack (205)
  • It was really challenging, really. pair programming does not require only programming, but it's about the more broad social/meeting skills Dave was speaking about in the SAMOSAS lesson. (196)
  • I think the pair programming should go in pairs. With these hangouts, oftentimes you get up to 10 people at a time, each at a different point with a different problem, and folks tend to leave unless their patient enough to wait for somebody to pay attention to them.  (195)
  • I like it, but unfortunately didn't have chance to work on every HW in pair programming way (190)
  • I think they have their place, however for a course like edX 169 and other MOOCs, I would really like to see an offering of the course materials that lets you go through at your own pace. The course structure really doesn't leave much time for a working professional who has a wife and children to fit it in, yet I don't need to turn to forums at all for assistance, I know very well how to use Google, so I would simply have preferred going through the course with less stringent deadlines for a certificate that doesn't really count in the real world yet. (186)
  • I have a very young family with 3 small children and I found that I could not allocate time blocks for working on the course. When I had the chance to get something done I grabbed it so I don't think this fit well with the idea of setting up or joining pre-organised sessions. (182)
  • I would like to see non-assessable (i.e. "non-credit") programming tasks which are related to the assessable homework programming questions and where there is no constraint on communication between students, i.e. no need to worry about breaking the honour code. (180)
  • Having never used any of the pair programming technologies before it just added and overloaded my ability to accommodate the number and amount of new software tools required during the first 2 weeks of class. Suggest adding a 1- 2 week Pre course setup sessions to get the infrastructure in place so class content can be the focus from day one of the course. The course is over and I still don't have many of the tools working including; Heroku, AWS, putty, SSH, shared folders, Hangouts, rotten potatoes, to name a few. Did buy the ebook, and a Ruby book and did CodeSchool, and ruby Zombies in the hopes that I'll get thru ed169.1 next time. (178) 
  • PP can be very beneficial to coding, but it can present special problems to learning, as well as some solutions. Studying together is not a bad thing, but it's really not exactly pair programming, it's a study session. So while working together is helping, I don't think many here are getting the full experience of PP yet. On the other hand, we are getting what you should expect from a class- exposure if not immersion. (168)
  • I think it's a great idea. There are probably incremental improvements that could be made to the process (there always are) but I can't think of any and it certainly worked as-is. Perhaps a tutorial screencast just to run through how the technology (Google+, etc.) is used and a sample session? (149)
  • I do not think remote pair programming is convenient for MOOCs. ... I think it would be achievable only between programmers that are in the same level. Especially for edX 169 where much of time one would spend is to find the syntax details or bits and pieces of rails, I do not think it would work for me. ... I do love the concept of pair programming but for a course where you don't just start writing code, but you spent a lot of time searching through Google or studying the ruby and rails docs, I believe it is very hard to accomplish satisfactory pair work. (137)
  • Great idea and thanks for encouraging us to do this! I have really learned a lot (and looking at job ads it appears this skill is in demand) (126)
  • "I find it extremely hard to schedule time where I can commit to working on the assignments because I have to fit it in with work, family, etc. It is also incredibly difficult being in a timezone much different to most others. This makes it hard to schedule and/or commit to pair programming, which is why I didn't even try until CS169.2x hw1.  BTW, Tutorials are at 1am, so I don't really get access to them. There is virtually no chat during my night hours." (116)
  • May be a tutor on line (like a helpdesk) can resolve some questions, it must be a plus. (99)
  • It looks like that it's effectively there. Personally, I found it too intimidating to try. (98)
  • Another reason I didn't do any pair programming is I fell behind schedule. So when I was finishing HW 1.5 everyone else was finishing HW 2, etc. (95)
  • I think that technically the Google hangouts platform isn't there yet. I think that maybe a better use would be having each student work individually, then chat if any issues.(78) 
  • I like the idea, but in my case I prefer the individual work. (73)
  • It's interesting but I was always fighting to keep up to date with the course and didn't have time to pair-program (66)
  • Remote pair programming might not have been as bad if  1) the course specified a default technology for screen-sharing. (As it was, squinting at the screen for that length of time was challenging.) 2) It were easier to arrange sessions. I have trouble planning specific times when I'll be able to do homework, and prefer to do it when the time presents itself. 3) The virtual machine worked smoothly with the google talk plugin. (64)
  • It seems like not many people are actually doing the pair programming. Considering how many people take the class, there doesn't seem to be many people doing pair programming. (60)
  • I take online courses so I can work at my own pace to learn. I don't like the artificial deadlines of the traditional learning experience. Were I taking this course in order to find a job in the industry, I might try pair programming. However that is not the case. I work alone and things get done when they get done. It would be nice to see MOOCs get away from the traditional learning race. Slow down and let people enjoy life and learning. (53)
  • They were a huge distraction from the actual material. (49)
  • No - just want to use this opportunity to thank everyone who helps in chat. For me, time is very limited and it really helps to get a quick thought or advice from someone when I get stuck. (34)
  • They are great. (30)
  • I think people would be more likely to take the role of observer and stick to it if they could be sure that they would have the code to submit to the grader afterwards. I feel that most (all?) of my partners and I myself didn't commit to the role because we wanted to write everything down as it happened. Also, I think one thing that would be nice is a place to show up and say "hey, I can pair right now". I tried doing this in the g+ events but no one showed up. I don't know if it's because noone was available or if it is because nobody saw it on time. I also posted on the chat but no response from there. A little bit after I started the last homework I decided to try cloud9 and I really like it. I think I'll try using it for 169.2. (28)
  • I done this activity, pair programming, only with persons that I knew before the course. I didn't do with stranger. (26)
  • Google + is fairly resource intensive and people with lower spec'd (older hardware) may not get the full benefit. Skype group/conf call in conjunction with Cloud9 worked great. (25)
  • I hope the future gives us the ability to develop in your favorite ide via the net (23)
  • One problem that I experienced was that when you are supposed to navigate, you are obviously worried about getting your code working as well so you have to sort of drive on your own, on the side, while navigating for the other person. That is tough on one screen especially with the virtual machine going. I think the problem could stem from the fact that in an in-person pair programming session you are using the same computer/code so you get the code working together but in the course, we each have to submit our own code set so your first priority is not working with the other whether you are navigating or driving, you are worried about getting your code working on your PC as working on one code set and submitting it together is not allowed, which I understand there are very good reasons for that. As for remote pair programming an their connection to edx 169. I found it a very useful element to the homework questions and took a great benefit from them. (22)
  • I think the opportunity to try pair programming for real is a very valuable one, and remote PP is a creative way to enable this, as well as exploring in a pragmatic way what can be done with the existing enabling tools (Google +, etc) 've not participated thus far because I started the course very late (about half way through) and so I'm working through the exercises with a substantial time lag to the other participants. Maybe if I can catch up I will try it on the second part of the course? (20)
  • It's difficult to find people available during my free time. I say free time, because I'm working in a company as IT Quality Manager and I don't program software in my job. It's like an hobby for me or a personal activity, linked with the domain of my job (IS/IT) (19)
  • There NEEDS to be a way to separate a chatroom into pairs and still keep them attached to the meeting as a whole. (16)
  • Remote pair programming sessions should be limited to 2 or 3 participants.  Participants should indicate what time they will be available and how long they can stay, so that sessions can be scheduled more rigidly, otherwise sessions can drag on for hours. Participants shouldn't be able to join a session after it has been in progress for more than 15mins as this can disrupt the flow. All participants should be at the same stage in the homework at the start of the session if possible. Participants should be able to bookmark other students who they have shared a fruitful pairing session with, so that they can work with that partner again when schedules permit. (14)
  • There tend to be the two extremes of ability in chat and hangouts, so it could be expected that outcomes for pairers AS A GROUP be similar to those who did not participate. Fewer dropouts, or better outcomes among the lower-ranked pairers may be a better indicator of success. (13)
  • I am all about self-organizing communities - look at open source, but sometimes I think some structure would help. I know with 1000's of people this is a challenge, but maybe a video or something about how to run a successful pairing session would be great. Last of all. Thank you for providing this wonderful course. Joseph was very generous with his time and I really enjoyed the lectures from Dave and Armando. (12)
  • The idea of remote pair programming is great, it opened a way that I never thought about, I am really glad you came up with this in the MOOC, and I think it keeps you attached to the MOOC more, and help you complete the MOOC till the end. (8)
  • good learning tool. Should be continued and tried in other environments. (7)
  • From my little experience I have concluded that it's better to pair with someone as close to your level expertise as possible if you are concerned about producing good code and being efficient. Obviously if you want to learn things it's better to pair with someone more knowledgeable. (3) 
  • Currently its fine. But due to varying internet speeds some will struggle, like me. (216)


Do you prefer Pair Programming over individual programming?
  • Prefer a balance - sometimes want to just code and think alone (209)
  • Yes it really helps having another person looking at the code at the same time. (205)
  • No, I think it needs more effort to do the task using pair programming (199)
  • For difficult coding assignments, yes. For simple assignments, I think it is faster to code by yourself and more efficient for the project itself. (197)
  • I would prefer pair programming if done in the extreme way: two people developing a feature together, rather than one person helping the other get out of a rut. I like individual programming in a lazy sense. Sometimes, for lack of explaining my thoughts, I find it helpful to conjure up something presentable to discuss on my own, which takes some time. At that point, I like to pair up for discussions, optimizations, or even total redesigns of the existing code. Sometimes, it's hard to think with somebody breathing down your neck, but in the end, that really depends on the personality and knowledge of the person with whom you happen to be pairing. (195)
  • NO. INCOMPATIBLE WITH HONOUR CODE. (180)
  • In person more fun (177)
  • I didn't understand how the pair programming process works. I tried visiting some events in google hangouts. But found no activity there.  I didn't push myself for pair programming any further because I felt that I may become deficient in the subject if I fail to catch the speed of the pair programming counterparts. (173)
  • Sometimes yes and sometimes no. It can distract my train of thought, but sometimes that's a good thing because your partner may have the answer. I've definitely seen that code could benefit, and students can benefit as well. If both partners are competent in the task at hand, they appreciate the pair programmings system and understand it's strengths and weaknesses, I think it has many benefits such as better code, briefer code, fewer bugs, and better testing. (168)
  • No. It takes too much time, effort and resources over individual programming. Unless absolutely transcendental to the achievement of a project or mandatory at a company, it will never be my prefer way of programming. (164) 
  • it depends very much on the person you are pair programming with, you have to be on a pretty high level of understanding of the language and what you are about to do (162)
  • I don't want to work with people I don't know. (158)
  • Yes, I prefer pair programming over individual programming due to sharing of thinking,views,perspectives and resources between two in pair programming that makes more reliable,flexible,real scenario analysis of problems. (153)  
  • Prefer non-remote pair programming best because it fosters a relationship with another person and enables easier casual conversation along with programming.(152)
  • I found pair programming very productive and will do it again in the future if I have the opportunity. That being said, it was difficult to arrange even within the framework of the course. I fell behind during HW2 and after that I was too out of sync to pair up. (149)
  • Pairing better as more details can be caught (135)
  • I can't say I have enough experience yet to have a preference, but I have definitely learned some things from pair programming and am eager to pursue it further (today in fact in part 2, HW1-1)! (126)
  • pair programming is better because it's also a knowledge share (124)
  • I prefer pair programming because of its benefits:
    - Better code
    - Improved morale
    - Collective code ownership (122)
  • I prefer individual programming, but some consultancy (or rubber duck debugging have a place to be) :) (121)
  • In this case, yes. Given how little expertise I have in ruby/rails/cucumber/etc, it is helpful to have someone else to talk to when attempting to solve a problem. (116)
  • I think its great way for working but for me not usually working in pair remotely (101)
  • Depends, if you know very well a tool, if better divide the work and make individual programming, if not, pair progeamming is better. (99)
  •  I still need to give pair programming a try. I do find it hard to make time for and still maintain the flexibility i value i nedx courses. (97)
  • I generally prefer individual programming. It's much easier to arrange, and all parties (you) have a common goal. I've done pair programming in a work setting occasionally. In that case you're both there anyway and your time is the company's time, so there's less to arrange. And you have a common goal -- getting the company's project done. With homeworks your common interest is much weaker -- more just trading favors and hoping to learn something along the way. (95)
  • always is good to program with another person, you can learn a lot more. (93)
  • I don't prefer either; they're very different experiences. I've been pairing with the same guy for our c++ class, and it's been more difficult. The assignments are much vaguer and more open-ended; we both have strong but differing opinions on what we should be doing and how.  I'm interested in learning how agile businesses deal with that kind of issue. Also, his brace style is objectively inferior to mine in every way. (84)
  • Individual programming, not time enough to hang out. I don´t want that other students were out of time through my fault. (82)
  • I like to have someone to bounce ideas off and get things right the first time. (81)
  • I prefer pair programming because it allows you to have a repository of ideas which helps to start and continue to the end. (80)
  • I prefer individual programming, although I like to ask someone else when I get stuck. I've never really done pair programming properly though. (78)
  • I guess that using pair programming when everybody knows the tools and focus on the job is quite beneficial. But in the context of this course I don´t think so good. A part from that I'm working family father, which means I have a strange and chaotic agenda. (73)
  • I think that I prefer pair programming, but the remote of this course made me defer to individual programming. (64)
  • I was intimidated by pair programming because I only have one programming class under my belt. I don't know if I will try it with strangers (61)
  • I like pair programming after I've had a chance to have an attempt at the homework assignment. I'm always interested to hear from others about their approach to the same assignment. (60)
  • I prefer pair programming, but not always you have good pair. (58)
  • For this course, I preferred individual programming. Part of the appeal of online courses is the flexibility to work on your own schedule. Pair programming requires an added layer of coordination, and I was confident enough with my programming and problem-solving skills to forgo pair programming. (54)
  • No. I took this course to develop my personal programming skills. Also, I made no attempt to work at the pace of the class. That makes it a problem to pair program. (52)
  • I am more flexible alone so in my spare time I dont like it. (50)
  • Not happy to use a Google platform, and didn't have time to experiment with remote screen sharing. (49)
  • Not really... it's a stress; if I'm sharing, everyone watching me making mistakes. On other hand, probably it's even faster. (48)
  • It's obvious preferring pair programming since it helps in building global contacts interacting with peers all around the world accomplishing a task in good time efficiently and helps making our code universally understandable. (45)
  • I've never pair programmed before, and only twice in the course, but I think at times it might be useful because you might have a question or stumbling block and your pair could get you unstuck. For me I visit StackOverflow and post or query if I need help. (42)
  • individual -- dive into problem much faster, without interruption, but when have questions pair programming is good. or when you get stuck (41)
  • I prefer pair programming because the resulting code is mostly free of common bugs such as off-by-one. Also, many bugs regarding the higher level logic are already captured by the observer. Additionally, the code readability is enhanced thanks to the comments of the observer. (39)
  • For these MOOC courses, pair programming is absolutely necessary to help get you past things that have you completely blocked. Most of the sessions I saw were just troubleshooting those blockages. I expected Pair Programming to be more synchronous work between two people starting from the same point & achieving the end together. (38)
  • Yes. Two heads are better than one. (35)
  • I prefer individual programming because I figure out and learn things better by myself. Company of any kind usually distracts me. Sometimes it is very helpflul to get advice from another person but it is usually not worth for me comparing to distraction from a full session collaboration. For me, access to chat is ideal. I get stuck, then I ask for help and get advice or idea from someone. (34)
  • Pair programming and individual. Sometimes it's also good to be withyourself.  But I think - my knowledge right now - mostly can be done more effective with pair programming (33)
  • yes because it brings out rich knowledge and skill experience from each participant. (32) 
  • Hard to answer this question. I work full time as a teacher (not teaching IT either), so my time to work on programming is purely in my free time. As such, I tend to need to prize speed and efficiency over all else, and in such circumstances I generally prefer individual programming as it is quicker usually. However, I feel that pair programming is the better learning experience, and I would dedicate a great deal more time to it if I had the ability to. (31)
  • Yes I prefer that because it gives us help with our problems and also we might learn few new concepts from others. As I learned a lot of new concepts during the pair programming sessions in this course. (30)
  • I think I have yet to try real pair programming, with people clearly taking the role of dirver and observer. However, from what I've seen, I mostly like pair programming. Other students usually have interesting comments to make on my code and they also bring interesting idioms, methods or even syntax I didn't know about. It also feels very nice helping people who are stuck at a point where you clearly know the answer. (29)
  • I prefer pair programming but when both have some experience in the program language(26)
  • It's a big help in a lot of cases, but not a replacement for individual time. Programming is a creative process and having to pair program all the time would get in the way. But using it to overcome 'writers block' is the killer app/excuse/reason to use PP. (25)
  • pair programming with the right partner. because you can "relax" and get a better view, as when you do something alone. (23)
  • I prefer pair programming session over individual programming because while one person is writing the code the other is essentially the editor. You can collaborate ideas and perspectives and in the end you have simply better code. It is said that "Programmers working in pairs usually produce shorter programs, with better designs and fewer bugs, than programmers working alone.". I am a believer. (22)
  • It's not the same experience. I love to search myself to understand the solution of my problem. I take time to read information on internet, but when I have people with skills and be able to explain correctly the solution, its time saving. Because, it's hard to find the correct people inline with my level, i prefer individual programming. I have the habit of it. (19)
  • I don't but that's mostly because I'm autistic by nature and prefer going through the programming-cycle myself. (18)
  • Pros for Pair Programming: - Get additional input/insights while solving problems. - Establish new connections with peers. Cons: - sometimes a session can be fuzzy & slow (17)
  • Yes, since it is less distracting and more enriching. Additionally, it adds a social aspect to software development. (16)
  • I still prefer individual programming, because I like to work through a problem on my own. (14)
  • Depends on the details to some degree, what the task is, partner, etc. I have worked in small teams and pairs before, and for a complex or important bit of code, it's nice to have a discussion partner that is not only knowledgeable but fully invested in the outcome. (13)
  • When I found a good session, I loved it, I found the flow and the things I would normally get stuck on someone was there to help correct, suggest, etc. The biggest problem is each session is kinda hit or miss. I think everyone intention was good, just sometimes there was no direction. (12)
  • I prefer to balance pair and individual programming; I find long stretches of pair programming to be quite draining, but it can be useful for important chunks of code. It also depends partly on the needs of the project. (11)
  • I prefer individual programming with some instance in which I can talk with someone else about the program, so I can try my ideas without having to wait for the other one or follow him on everything he does, but at the same time we can share ideas and help each other when any of us gets stuck.  I didn't find working on the same code with another person too appealing. I like doing things by myself and with my own pace.  (10)
  • Yes I prefer pair programming over individual programming, as from the one time I tried it I think I learned so much, both in Ruby coding and ideas to solve problems, having other people review your code in real time is really great and having other people sharing their ideas with you is really useful, you learn a lot from it in both coding and problem solving. (8)
  • Positive It is very convenient to talk with another person. You can learn a lot from others thought process Negative(Slight) Most of my pairing has been on the HW. Since I completed them before, the value gained has not been too much, (7)
  • yes, i prefer pair programming over individual programming for two reasons. First, when i pair programmed for ruby development with a developer who had detailed knowledge of ruby, i learnt a lot from that session. Second pair programming helped me develop a powerful and effective code. (6)
  • I am not sure yet. It seems that i am extremely more productive when programming alone. Maybe it's the language barrier or that i haven't find the proper pair yet. (3)
  • I prefer both pair programming over individual programming but both on different scenarios. Pair programming is best when we have to create an application/module as a overall. Individual programming is best when we are developing a small portion of code. (216)
  • At this course - I prefer invidual programming - I have no free time. And I don't know when I would have time or I would suspend my work for few hours. At work - I prefer invidual programming because I'm master of myself. (217)
  •  For learning a new language stage, I prefer to do individual assignment for practicing purpose. The pair programming materials should be separated to individual programming materials. i.e. different set of tutorial question/assignments. This is because this is still new language to me, I had experienced pair-programming prior to this course a long time ago. The thing I learned is that, yes, it helps to solve a problem quickly if paired, but it also means it is easier to forget what I had learned because I did not put my hand on the keyboard.  (218)
  • Individual programming is better for me as I don't like remote pair programming as a lot of time is spent for finding a pair or for solving connection problems etc (219)
  • Yea I do cause it gives you an insight to a different logical view from other pairs.  (220)
     
Do you prefer remote pair programming over in-person pair programming
  • Easier to work with others in person (209)
  • No, I would prefer in-person pair programming, communication become very difficult when its remote, beside the connections delay (199)
  • Remote works well for me (197)
  • In person pair programming is better because you are more engaged and it's easy to share stuff (like pen-and-paper drawings and cheetos) and to switch roles, although modern day tools make this less and less noticeable. Remote pair programming is better for hermits, smokers, nudists, the unshowered, mooc students, and people who choose to work at home in order to properly care for their children. (195)
  • Not right now, no. I'm not opposed to pair programming at all. In fact, I would like to try it, when the time is right. I don't think trying it over the internet is how I would go about that though. And for MOOC courses, because it is extremely hard for me to make time for the coursework, I'm not likely to make that more complicated by trying to add pair programming to the mix. (186)
  • I have twin children and I took the course at any time when they leave me alone. (181)
  • Alone (177)
  • yes since we have tools like tmux/screen/floobits both participants can work on something at the same time in contrast to one working the other one just starring at the screen (162)
  • I prefer individual programming, because my ruby level of programming is low. (157)
  • It might be good as always it is not possible that two persons are available at a time at same place.(153) 
  • Having never really tried in-person, I can't really say. (149)
  • I prefer in-person pair programming, but the remote is a good option since I don't know personally any friend or person who's taking the course. Thus, it's impossible for me to take in-person pair programming for the edx courses. (142)
  • Yes but upto certain extent only. (141)
  •  In person. Can make quick change of developers for few lines. (135)
  • prefer in-person (133)
  • I have only experienced remote pair programming, but I imagine it would be easier in-person. (126)
  • in-person pair programming because the moments are really real (124)
  • I prefer in-persion pair programming because:
    - I can contact directly with my partners
    - The communication are usually faster and more effective (122)
  • I would definitely prefer in-person pair programming. It makes it much easier to communicate. (116) 
  • It looked interesting, but I did not use pair programming because I'm worry about my english skill.(102)
  • Yes, I think is good working remote pair because you can have quality code (101)
  • Remote is best, because we can use two computers instead of one. (99)
  • I prefer in-person pair programming. Much less communication friction. And generally in-person means I already know the other person. I don't want to pair program with a stranger. (95)
  • always is good to program with another person, you can learn a lot more. (93)
  • in person / whiteboarding and just being around leads to creative solutions (85)
  • I would prefer in-person pair programming, it is best the short distances to interact each other. No connection problem. (82)
  • I do. Less bugs, better design. Misery loves company. (81)
  • In-person pair programming has some advantages over remote pair programming. Using native language makes brainstorming a breeze, on the other hand, using a common language for remote pair programming, at times, makes it difficult to express clearly ideas. (80)
  • In person, definitely. Remote is just too glitchy, too hard to tell what's happening.(78)
  • No. I can't see other people's screens. Some people zone out and leave their computers. Other people just take pictures of the driver's work. (64)
  • Is much better person pair programming, you don't have scope problems. (58)
  • In-person because it's not dependent on closed-source technologies. (49) 
  • No much difference. But of course, in-person it even more active. (48)
  • It depends on the task. (45)
  • probably would prefer in-person, because there would be a more definitive assignment of the driver/navigator roles.
    The downside the MOOC pair programming is that each student is driving their own code so everyone is focused on getting their code working. To me it wasn't pair programming in the true sense that only one person was typing. (42)  
  • I prefer remote pair programming because it gives more personal space to both the driver and the observer. Furthermore, when an issue arises the observer is free to look up documentation or other resources without stalling the driver's work. (39)
  • I'd prefer in-person pair programming. The communication is much simpler. (38)   
  • I am not a big fan of either one. To me, the best team work is highly individual work well divided between the team members and well communicated and planned to be put together.(34) 
  • I prefer in-person pair programming. I can talk mostly my native language and I have a real person next to me. Its more human in this technical world. (33)
  • remote or in-person both offer same rich experience. (32)
  • Neutral on this. I would say that I prefer in person, but that is probably because the person I pair program with is one of my closest friends. Remote programming offers the ability to meet up with a diverse range of people with widely different perspectives, techniques etc. However, it can also mean ending up with someone very far behind that drags the group down. Again, it is a brilliant learning tool committing the time to help them catch up, but it is very time consuming. (31)
  • I would be on a neutral side as both help at some point of time. Both of them have their own pros and cons. But remote pair programming is better than in-person pair programming as it helps us more to widen our knowledge. (30)
  • Remote is more comfortable for all. But we lost the concentration in several times and the face to face feedback. Disconnection problem were frecuently. (26)
  • in-person not always feasible and time consuming plus difficult to agree on a schedule and last minute back outs. (24)
  • a "in-person" is more personal. you talk to your friend next to you (23)
  • I believe that anything in person is going to be better, but remote pair programming is a good substitute when you can use video/audio and screen sharing. If the person doesn't have a mic, it really becomes difficult. (22) 
  • Depends. If the project is difficult I think pair programming is more productive. In projects, though, that can handled effectively by an experienced developer sometimes pair programming may be a bottleneck for rapid application development. For pedagogical reasons, also, I would prefer pair programming. (21)
  • I prefer in-person pair programming, because some difficulties due to the usage of a new technology appears when we don't have habit to use it. (19)
  • I do because of my autistic nature it's easier to do remote programming then in person (18)
  • I prefer in-person pair programming, with the proviso that the navigator has hand his/her own terminal to research the docs or SO questions while the driver codes. (14)
  • I basically learned programming by pairing in person, and so I was on the receiving end of the knowledge transfer. Here, I am not so familiar with Ruby or rails so I don't feel as comfortable being the navigator. (13)
  • I find the best value of pair programming for me is to learn the concepts alone, review the problem alone, maybe start thinking about how I would solve it alone. Then walk away, give my brain some time to digest it, and then join the pairing session primed and ready to go. (12)
  • never really done in person pair programming. Probably would prefer in person pair programming. Had some network connections. Would like to see people's face when discussing (7)
  • I prefer remote pair programming over in-person pair programming for two reasons. First, when i remotely pair programmed for my project development based on ruby, it gave tremendous flexibility as i could join the session according to my feasibility. Second when i wanted to program with a developer in Canada, while i was in India then remote pair programming helped me to do so. That's why i prefer remote pair programming over in-person pair programming. (6)
  • Nope. It seems you get the point across more efficiently when you can use your body language too. (3) 
  • I prefer pair programming than remote pair programming because real collaboration is there. But sometimes remote pair programming is best when your companions are not around you. (216)
  • remote is excellent idea if compared to in person, dealing with problem only. (218)



Describe a typical remote pair programming session.
  • We usually use it to work out problems. We use webex and skype. (205)
  • Fractured and off subject. (178) 
  • I only had one other pair programming session (HW 1), but I'll optimistically call that typical. We had three people and I had arranged the session to be for just one section of the HW (the second), so we would have what I felt was an achievable goal. We actually stepped back and went through the first section as well and despite that we blew through both sections in under an hour. Very productive use of time. (149)
  • Connection, write some code, watch how your partner write some code, end (135)
  • When we were using public Google Hangout sessions, the result was typically chaotic. Until recently (in part 2 of the course we have switched to a private hangout with just 2 of us), it was quite distracting as different people would come and go with different levels of concerns (ranging from clueless to already completed the assignment and just wanting to help). In fact, it was more of a group study (programming) session than actual pair programming. Often productive and interesting, but not actually pair programming (until our recent switch to a private hangout). (126)
  • One of us shares their screen and drives, with the other providing advice/corrections as appropriate. (116) 
  • It starts slow, like sharing my development screen and 2 or 3 people trying to have an idea of what to do. Then someone comes and has a clearer idea and we all catch up. (80)
  • Depends on the number of people. More than 4 people can become chaotic. It also depends on how knowledgeable the group is. If you have several people who are far behind in understanding, it can slow things down a bit. (60)
  • Too many problems. Usually people don't have microphone or good internet. (58)
  • Everyone logs in, then one leads, shows task and how it is implementing. Everyone watches and asks question. I know in thoery we should change roles time to time, but it's rare so. (48)
  • An event will be created and invitations are sent to the whole edX group. Then everyone interested get ready for the hangout. First, hearty welcomes to each other. Then immediately without delay, everyone come to the task. One will be the driver and remaining discuss along the way helping the driver. Code refinement is the best thing about pair programming. (45)
  • My second pair was on HW4. This was a hard HW and I wan't as far as most in the hangout. It was really my fault for not asking more questions I was more like a fly on the wall. So for me it was like I was solo programming with a bunch of people talking in the back ground. Too distracting.
    Again to pair it would seem like you'd have to start code from scratch together with just 1 other person. The hangouts seem to be more of a chat session with live voices. Unless I'm doing something wrong, it is very hard to make out the text of the screen shares. Maybe there is a setting to adjust the resolution. (42)
  • Start by discussing briefly the objective. Continue by outlining its method's flow using comments and exchange implementation ideas. After agreeing on the implementation place under the comments either the code that solves the problem or methods that encapsulate the required logic. While the driver writes the code the observer gives suggestions on the code syntax. Warns on possible bugs, and reminds them of aspects of the module that need to be consider while implementing the specific method. (39)
  • Some people would hang in the background while 2 or 3 people took the lead, sharing their screens and driving the conversation. Usually people had started the work but had reached a block. If the other person had overcome that obstacle they would help explain what was missing. Some of the people in the background might chime in with ideas or ask questions. (38)
  • "typical", what is typical? I do not have so much experience with remote programming, but I like the approach very much.  What I definitly miss is, that I can work in my favorite IDE which is not possible at the time, and I researched a lot. Cloud9 and others are not my IDE. (33)
  • discussion of challenges and possible hints on how to resolve them. (32) 
  • People would come in, set up screen share, then there'd usually be a great deal of confusion and aimlessness as we tried to figure out the direction to take. We would ask each other questions on where we were up to and what we were having difficulty with, but it could take a long time indeed to get everyone on the same page. Even once we had, it could take even longer to figure out what needed to be done and how to achieve that. In the end I always gained a lot from it, but it was time consuming. (31)
  • Some people show up, mostly with some part of the homework done already; they just want help in one specific point. But everybody is at a different point. Sometimes someone without a microphone will show up, but doesn't get to participate much because most people don't look at the chat bar that often. The group decides who has done the least of the homework and that person will "drive" until he/she catches up. The other people comment on their coding while at the same time tweaking theirs or trying to solve their own problems in another part of the homework. Once everyone is at the same point, it is not clear who is driving and who is observing, since we all have to keep coding or we won't have anything to submit to the grader. The session usually ends when someone who was very active has to leave (usually because it's late and they need to sleep because they have to work the next day). The other people usually leave shortly after. At this point I lose hope of pair programming for that particular homework and do it alone. (29)
  • Speak about the homework, show our advance. Then try to solve the problems together, but rarely we done pair programming. (26)
  • We'd meet via google hangouts, then transfer to Skype conf call (as it was less resource intensive than google +) and use Cloud9 (https://c9.io) to work through programming problems. (25)
  • Typically you had a small group of people engaged and working well together with various others joining and dropping the hangout. Getting started was tough as most of the time almost no one was ready when they first join the hangout. For each section, one person was driving with all the others navigating. At the end of the section we would ask questions and try to "catch up". Then another person would drive and we would continue. (22)
  • No, pair programming because you have physical contact with the other person. (21)
  • Hello, who is on the line A leader explain the topic, the goal and the rules, the time of session After, a leader cadence the session to be sure that every people participate. (19)
  • Because I only do chat-only (not native English) it starts with someone asking a question and then we start looking at each others shared screen (mostly with VM), give advice, learn what others did, ... (18) 
  • We'd introduce ourselves, talk a little and work each on our own piece of code, asking questions and showing it to other participants. (16)
  • Pair programming on the SaS homework's was a little frustrating, especially in the early homework's, because many students drop into public 'on air' hangouts, take a screenshot of your code and then disappear. I can only assume they are attempting to get a passing grade on the AutoGrader without doing any work. Also in pairing sessions with more than 3 programmers, a few observers tend to lurk silently without contributing or offering to drive, I fin this off-putting. Apart from these observations the sessions are very helpful in understanding the content and solving problems together. (14)
  • I am already done with the homework because otherwise I am not comfortable. I log in and try to take some part of the people that are struggling at a lower level in chat, while TA takes on some of the people that are closer together, usually a bigger group. I look at their screen and try to figure out why they are getting errors that they don't understand. Hopefully with the benefit of hindsight I can point them in the right direction, although sometimes I can't remember what was the solution to these common micro-problems and must go from first principles again. Often these students are behind in the course. Often they are looking at the code and trying to figure it out logically when they actually need to check their values. If we get stuck on something, or TA?'s group does, we go and try to get the others to take a look. If I was more familiar with the material or a better student, this scenario might not be so bad. (13)
  • If I started the hangout, I would welcome people as they joined and quickly verse them on what we we're working on. If I joined a hangout, often it just felt like everyone was doing their own thing with an occasional question in the chat window. I think the biggest factor of a successful session is to have a moderator, not to dominate the work, but to keep everyone together and allow others to drive. (12)
  • Call on Skype, talk about assignment and ideas about how to solve, the one that types shares the screen. Use chat for showing complete output if there are errors. (10)
  • All the participants should have already read the problems statements, but no code is done. When we start someone takes the lead in a problem and start thinking about it and write his code, others observe the code and start collaborating with ideas. And we loop throw the problems one after next so each one play the role of developer one at a time. A typical of 2 to 5 people would be perfect for the session, as everyone adds his new ideas. (8)
  • My other pair programming session I held was to help other students.  I complete my programs before the session and help students with their problems. I usually ask the other students to help each other. If both are on the same part, I ask them to pair program. If someone else is stuck on a section, I ask the one who got it to help guide the other. (7)
  • A pair programming session on autograders, which includes pair programming on rag and hw repositories. (6)