On asking questions
The XY Problem
The XY Problem is very common. I've caught myself falling into this trap multiple times. It happens when I'm trying to solve a problem (X), decide that a specific approach (Y) is the answer, and then ask for help with Y-without realizing that Y might not even be the best way to solve X. This wastes my time and confuses the person trying to help.
Let's say I'm trying to figure out why a certain code path in my kernel module isn't being hit during testing (that's the real problem-X). But I assume the fix is to write a custom kcov harness to capture more detailed execution traces (that's my assumed solution-Y), so I end up asking:
"How do I use kcov with a loadable kernel module?"
Now someone might spend time explaining how to hook kcov into the module, set up coverage buffers, etc. - but maybe I didn't need kcov at all. Maybe my tests just aren't triggering the right inputs, or the code is behind a config option I didn't enable. If I'd just said:
"I'm testing my kernel module, but a certain function isn't getting executed-how can I figure out why?"
I'd probably get much better help, faster.
Don't ask to ask, Just ask
This one's surprisingly common, especially in online chatrooms and forums.
I've been guilty of it too-joining a channel and typing something like, "Any LLVM experts around?" It seems polite, but it actually slows everything down. What I'm really doing is asking people to raise their hands before I even say what the problem is. That's a lot to ask.
Just ask the actual question and you'll get faster, more helpful responses-and maybe even from someone who doesn't consider themselves an expert, but still knows enough to point you in the right direction.
Bad: Any LLVM experts here?
Better: I'm using LLVM's IRBuilder and trying to generate a for-loop. What's the best way to emit the loop condition and increment?
