The modern programmer's life sometimes seems like a long series of online chats punctuated by coding. These interpersonal contacts on the Internet--particular over high bandwidth--can alter the dynamics of programmer education. But like all interactive training, these contacts are most effective when the learner also has more stable assets to consult, such as code examples and documentation.
Interpersonal contact has been an important part of my own learning--for many things, not just programming--and its importance has come to the fore more and more as I talk with people about how they learn new computer tools and libraries. For the first couple years of my research into online education, I focused on documents. But from the start I wrote that online forums had always played an important role too. That led me to explore email lists. I used them as examples of online interaction, like many researchers, because it's so easy to retrieve information from archives.
IRC is still a narrow, text-only channel. VoIP extends it. But why can't education across the Internet become closer to the rich educational possibilities enjoyed by people who occupy the same office or classroom?
Programmers are learning to use the instant information-sharing tools that are already available, and IDEs are evolving to provide more and more of them. Many programmers, for instance, do their modeling or design in shared spaces such as Google Docs. The most recent release of IBM's Rational Team Concert product lets you provide instant status and changes in specifications to team members. Microsoft offers a similar instant sharing mechanism in Visual Studio Team System 2010.
To dwell for a moment on the current state of the art, consider what RTC and Visual Studio offer. You no longer have to set up a special file, call it something such as Status or Milestones, remember to change it and check it in every time you do something your team needs to know about, and then wait for the team members to sync up their working directory with the master repository. (I do that on lots of projects, and it never works right.) Instead, basic project management tools watch what you're doing and adjust files that every team member can see right away--or even receive notifications for.
These are welcome trends, but they suggest the way toward even more powerful tools, a leap comparable to the one that Ajax-driven web sites provide over the Submit button.
Relevant features in Visual Studio Team System 2010
Microsoft has grasped the theme of collaboration over the past several years. SharePoint is probably the most common and heavily depended on tool for data sharing in the world (I would confidently compare ShapePoint's market size to Wikipedia, given what a small percentage of Wikipedia readers actually edit it) and Microsoft is also offering new services to compete directly with Google Docs. But to nominate its most conceptually advanced platform in collaboration, on a historical note, I can't resist bringing up the Groove Network product (now called Office Online), which was one of the inspired visions of Ray Ozzie on his way to becoming Microsoft CTO.
Debugging has not become collaborative in Visual Studio Team System 2010, but the product is taking a step forward by capturing interactive debug sessions and letting someone step backward through the session later. The impact of this feature is that a tester can pass a bug to a developer along with the whole captured session, and the developer can relive the experience (backwards as well as forwards). This can eliminate long, frustrating email exchanges.
A related feature allows the tester to preserve a test session as a video for later examination. You can see a demo in an MSDN video.
Relevant features in Rational Application Developer
In my search for steps along a path to more interactive programmer learning, I was particularly intrigued the most recent version of Rational Application Developer (Version 7.5, released last September), which took interactivity to another level in. It lets you pass an interactive debug session to another developer. If you're in the middle of slogging through your code and just can't seem to make progress, you can save the session and ask another developer to work on it. The overhead is minimal, because the process and the state of the JVM remain on your system and the other developer's commands are simply sent over the Internet to it.
The architecture of the product facilitates remote debugging. The debugger accepts all commands over a socket, so a remote machine can control the debugger as easily as a local one. The source code is centralized on the server, so all developers can get access to it.
You can even add a debug session to the repository server and park it there until another developer is ready to debug it. The repository server maintains the connections between the debug session and the target JVM in the state left by the debugger. Your breakpoints are stored on the repository with the parked session, and the other developer can download or discard them.
While this debugging flexibility is a step forward in interactive development, I was a bit disappointed to find out that you can't stay in your session and watch what the other developer does, much less ask questions and contribute ideas. Only one developer can log into a debugging session at any one time.
The next step would be to let a developer turn over the screen to another, watch what's going on, talk during the session, and perhaps throw in some changes on both sides. This is not much different from remote desktop products that computer users routinely employ to let system administrators take control of their systems and interact with it in real-time.
Real-time collaboration can potentially conflict, in a fundamental way, with the goals of project management tools. In project management, you want to capture and archive changes so the team can review them. An interactive IDE could support this goal by including a recording mechanism. The results wouldn't be discrete bits of information like changes to a project status file, but at least the team could go back to them later.
And interactive sessions that take place at useful "teachable moments" could also be put online for new users to view. This would multiply the benefits of the time invested by an expert to teach one new person.
To repeat the point I made at the beginning of this blog, interpersonal tools aren't enough for efficient education. Intervening every time a new user hits a snag would quickly exhaust all available expert resources. So we still need documentation, and the enhancements described in my other articles. By pointing new users to such documents, experts can forge a powerful and productive connection between interactive and non-interactive resources.