Sometimes I have to be That Guy during technical conversations, to tease out deeper architectural issues. Conversations generally follow the pattern:

Coworker: "Hey, can you add feature X to that library you wrote?" (The library was feature-complete a month ago.)

Me: "What do you need feature X for?"

C: "Because the library doesn't have it and it seems like it belongs there." (It doesn't for a reason.)

Me: "But what will you be using it for?"

C: "I need it to work around problem Y that I'm having." (Problem Y should never happen in our system.)

Me: "Problem Y… how did you design your code that problem Y is happening?"

C: "Well, I structured it like XYZ…" (We decided on day 1 that nothing in our system will use XYZ for reasons, and that there exist ways to solve the problem without using XYZ.)

At this point I know that my coworker's design has not been reviewed, has potential issues, and that my coworker might not understand the architecture we are using and why we're using it. Important things, which I wouldn't have known if I didn't play That Guy.

(Yes, I'm also That Guy who nitpicks code reviews and API designs, rambles about decoupling and cohesion, and complains when things are coded without any sort of reviewed specification.)