This past weekend I worked on debugging a piece of code with someone in my CS 5150 project team. We were debugging in tandem on single laptop screen. While we finally made some progress, several issues arose from the shared-display workspace.
The first issue we immediately ran into was the issue of switching between activities, in terms of what source code file to be looking for problems in. This led to some confusing back-and-forth switching since we both had our own ideas of where to be looking for problems.
In addition, as Scott discusses, the issue of concurrent actions on the shared-display became problematic. There were several instances when I thought of a possible solution, but had to wait for the other person to finish trying their possible fix. By the time they had finished with their attempt, I had trouble trying my fix due to the change in display focus and content, resulting from the other attempt, and also the time lag.
One other issue that came to light in our debugging session was the spectator aspect and its behavioral effects. As Cao discusses in the Flashlight Jigsaw paper, spectators can have significant effects on the outcomes of the shared-display processes. In my case, having the opportunity to both be a spectator and be observed by a spectator, led to some rather intuitive observations.
When I was controlling the machine and the other person was observing, there was a feeling of increased nervousness when attempting my fix. I felt like I made syntax errors more often and I simply just wasn’t as creative. When I was the spectator, I felt like it was sometimes difficult to not point out syntax errors immediately and sort of hover over the other person. This points to Cao’s talk of how being in a person’s intimate space can have some profound effects.
While there some were difficulties at this meeting, this particular task was very tightly coupled in that we each had some skills that were needed to figure out a solution, and a shared-display certainly helped in this respect. I had more experience with the programming language and the other person had more experience with the overall design of the code we were looking at. Individually, neither of us had the experience to find a solution in a timely matter, but a rapid exchange of ideas and feedback, guided by the display made the debugging process much faster than it would have if we were working on individual displays.
Subscribe to:
Post Comments (Atom)
Posts
This sounds like a very bad task to try using a shared display! Trying to focus on your own ideas while paying attention to someone else's is always difficult. Perhaps one solution to the problem of forgetting your debugging solution while you wait for your team member to finish would be to jot down notes on a sheet of paper and set it aside.
ReplyDeleteCoding tends to lend itself to a multiple-display process, especially since it supports merges, etc. I can see why you would have difficulties using just one screen. A queston: were there any issues in terms of territory, perhaps, that were inherent in simply sharing a display rather than specific to sharing a display for coding? I found that in my experience, using one person's computer brings up a sense of, "Don't touch, this isn't mine." Did you feel that?
ReplyDelete