Carl Orthlieb and I worked on a number of parallel projects on the Acrobat team. After Acrobat 2.0 shipped, we started looking at how to integrate with that thing called The Web. Carl came up with a standard for a “Web Link Annotation” which was an extension to the existing link annotations that allowed a destination to be a URI.
At the time, internet connections were slow and if you were in America and connecting from home, your average connection speed was 2400 baud. We cared a lot about the experience, so we invested a lot of time in I/O cover-up. The latter is a technique where you show some friendly animation to indicate that the computer is working (and if possible, show progress).
In our initial versions, the experience was less than stellar. You clicked on a web link in Acrobat and you waited and waited and saw nothing until the page was complete and if you clicked on a PDF link in a web page, you had a similar experience. We “fixed” that by drafting an API which allowed us to report in the Acrobat UI the progress that Netscape was making behind the scenes and vice versa. It wasn’t particularly elegant, but it worked. Well, it worked in theory.
We worked with Netscape on this API and the builds we got had some issues. Since Netscape was in Mountain View, it was easy enough to go sit down with the engineer responsible and get the issue fixed. One afternoon, I sat down with Aleks Totic and we looked over his code. He was scrolling down looking for a particular section and I was reading over his shoulder. I said, “Hey – hang on. Go back a sec.” Aleks scrolled back. “Stop. There!” Aleks focused on the code I was indicating and asked, “what is it?” “Right there – that’s an off by one error. You want to change that to […]”. “Oh! I do that all the time!” Oddly enough, so did I, which is how I spotted the pattern. It was code to display a progress bar in the UI which would paint beyond the bounds of the progress bar at 100%. The problem was that the total range of the bar was 0-100 inclusive, which is 101. His code assumed the range was 1-100 inclusive.
And that brief exchange was how I fixed a long-standing bug in Netscape Navigator.
Today, this type of work is called Pair Programming and it’s supposed to be a standard practice. In my experience, it was a good process for bringing junior engineers up to speed faster and for senior engineers to collaborate on new designs or to work on “impossible” bugs. Otherwise, I’ve felt it’s slowed me down. Still, it’s a good resource to use now and again.