Treasure these opportunities.
It's incredibly illuminating watching someone else debug a problem. Even if it's not your software, there are lessons to be learned in other people's thoughts, as expressed in mouse clicks, key presses, and spoken (or muttered) imprecations. Think of all the things you can look at:
- What is their architecture? Sometimes you care, sometimes you don't, but it's interesting to note that someone is using Java, or that app is all Perl. In particular if you're trying to use scripts or an API it can help to know about the underlying architecture so you can walk around the minefields posed by the language (after all, all languages have minefields!)
- Lessons for next time with this app. If you're going to have to interact with the app again, it's useful to know what they look at to debug the problem. You may not have all the tools you need, but you can probably use some of their commands to see where they look for things. Did they check a log file you didn't know existed?
- General debug lessons. Where do they look for things that aren't related to their app? Are they suspicious of IIS or tomcat? Do they immediately go to the registry or to wireshark? How do they trace that suspicion - what events are interesting and what do they dismiss? In what order do they take debug steps? Sometimes you can learn efficiencies or new tricks just by watching someone.
When we're working without outside influence, it's easy to fall into ruts - both as an individual and as a team - and that means we start to miss things. Watching someone else is a good chance to break out of those ruts a little bit. So when you're watching someone debug, don't automatically alt+tab and do something else. Watch for a while... you never know what you might learn!