FAQ Yourself: Use Questions to Tackle Tough Topics
I want to share a technique I have used over the last year whenever I encounter a tough problem or complex idea. Anything that is hard to grok quickly. It's a lightweight process that helps me to slow down and think methodically.
When I encounter a difficult concept, I write a question expressing my lack of knowledge. And then I don't allow myself to move on until it is answered. One I discover the answer, I write it out in my own words beneath the question.
This process is recursive. One question usually leads to more. I can drill down deeper into the topic, or else broaden out. So I'll write those down as well, and force myself to answer them all.
I use a simple and consistent format: the question in bold, and then the answer below it. If I want links, I like to add them below to see the list of references. I take notes in Markdown, so I'll share the general template 1.
**Q: QUESTION?**
ANSWER ANSWER
[source one](http://sourceone.com) | [source two](http://sourcetwo.com)
Here's an example of how it would look:
Q: What does an IVF/PQ index mean?
This is a type of indexing strategy for vector data stores. It is an approximate nearest neighbor data structure. IVF stands for "inverted file index," and PQ stands for "product quantization" ... (the rest of the answer is truncated)
As I said, I use this whenever I encounter something that is hard to grok quickly. That pretty much describes my day to day work, so I use technique all the time: when solving tricky bugs, on difficult chunks of code, when reading complex code bases, when reviewing long code reviews, learning new concepts, research, or designing new features.
Q: How does this process help me?
The benefit of the process comes down to three things: capturing questions, forcing myself to answer them, and the act of writing. Altogether it slows me down to think deeply about a subject.
Q: How does "capturing" questions help?
Capturing the question in my notes or in my todo-list captures my intent to seek an answer 2. If I didn't capture the question, then there is a higher risk of me ignoring my ignorance.
I have passed over many opportunities to learn or deepen my understanding of something important. It’s like skipping over a word you don’t know the meaning to while reading a book. If you keep skipping, you’ll never learn it. And it may be important enough to impact the meaning of what you are reading, and lead you to misunderstand things.
Skipping words is itself an example of where this process can help, but you can also generalize it to topics in software development as well. There are missed opportunities by skipping out on learning something that may be important to your work and career.
Q: Why use questions? Why not just write a note?
Phrasing my lack of knowledge as a question is intentional because it creates unresolved tension. Speaking that question into the world makes me feel a compulsion to give it an answer. This stirs up my motivation, and helps me fight off procrastination.
Q: Why does forcing myself to answer all questions help?
Because it forces me to follow through on sharpening my understanding of things I don't know. The time commitment here doesn't have to be great: it could be at little as 2-5 minutes per question, depending on the value. Or it could be hours.
Gathering knowledge now means I can reap the dividends of that knowledge over a longer time horizon. Those dividends compound over the months and years of my career.
It's an also matter of habit. By consistently working to answer the questions I write down, I consistently build the discipline of seeking answers. I reduce my internal resistance to acknowledging my own ignorance. It has sharpened my curosity: I am more sensitive to my gaps of knowledge and will ask probing questions to fill those gaps.
It also makes me feel good. I get a sense of accomplishment from conquering something that had moments before felt overwhelmingly complex.
Q: Why does writing help?
Clear writing is clear thinking. The act of writing — in such a way that another human (or your future self) can understand it — forces you to engage your rational mind. It slows you down.
Also, I don't know about you, but my pea-sized mind can only hold a few things in working memory at any given time. Writing questions down clears up space for me to think. If I tried to hold it all in my head, I'd feel overwhelmed by everything I don't know.
Offloading a question frees up my mind and gives it an opportunity to ask a question at a lower level of understanding. This tends to drive deeper and deeper until I find root causes or root kernels of truth. This is the same mechanism as Amazon's 5-Why's 3.
It also makes me resilient to interruption. Committing the question to my notes makes it easier to pick up context later.
Finally, it produces a well-formatted, clearly written FAQ that I can come back to at any time to refresh myself.
Q: Why would we want to slow down?
At work we have deadlines. We have urgent opportunities to pursue. We need to get stuff done. We need to go faster.
So then, why do I advocate going slower?
Well, I’m an enthusiastic guy, and I tend to get excited about my work. I'll get into a rush to build something or complete a task or learn a new thing. And in that heightened emotional state, when I encounter things that impede my progress, I'll become flustered, impatient, and then start to make mistakes. I shoot from the hip. I copy & paste solutions from Stack Overflow or ChatGPT and I won't fully understand why, and that also makes me even more frustrated.
In the book "Thinking, Fast and Slow" Daniel Kahneman presents a theory that humans have two modes of thinking: a fast mode and slow mode. The fast mode is low effort, low cost, automatic, rapid, based on instinct and experience, and great for routine tasks. But it's prone to mistakes and biases. The slow mode is deliberate and logical, it engages in complex reasoning, but it requires far greater effort to engage.
When it comes to software development (and perhaps, more generally, all knowledge work), I hypothesize that the fast mode is okay for some simple routine task (such as simple unit tests, or well-specified CRUD functions), but that it is more effective to engage the slow mode in complex or difficult work. Trying to use the fast mode results in brute force effort; literally hacking the code as if with an ax. The slow mode can produce the simple, elegant solution with a single precise stroke.
The bet I'm making is that by going slower in the moment, I'll arrive at far better solutions faster overall. It's optimizing for the global maximum (overall speed) by not pushing for the local maximum (speed right now) all the time.
Q: What about AI?
It's 2025, so it is hard to propose anything without considering it against the context of LLMs 4.
Q: Isn't this just prompt engineering, but with yourself?
This question popped in my head while writing this post. For context, prompt engineering is where you produce the best possible output from an LLM by providing good context and instructions.
But asking questions to drive critical thinking is much older concept, right? It's just the Socratic Method. If anything, my technique has made me better at crafting prompts to LLMs because I am better practiced at writing questions with tighter specificity.
Q: Why not just ask LLMs for the answer?
Because then you hand over your agency to think critically. I worry that over reliance on LLMs will chip away at people's capacity to think hard, do hard things, and grapple with ambiguous, complex topics. People will lose their comfort with being uncomfortable with the feeling of not knowing things.
Think back to the "routine tasks" I mentioned earlier. If AI steals any work from us, that is it. But thinking critically and deeply and creatively is the ability that AI will not replicate well.
Q: So do I think LLMs going to doom us to stupidity?
Not at all. I sense a potential for the opposite to be true. Perhaps, with effort, with a willingness to embrace discomfort, we can use AI tools to think harder and do harder things than we otherwise could without it. I think a key step is to incorporate it into a deliberately slow methodology, like what I propose in this post.
For example, I used Claude.ai to help me with the summary of "Thinking, Fast and Slow" in the previous section. I read that book seven years ago, and while I had remembered the general premise, I wasn't sure my recollection was accurate. So I asked for a synopsis of the book. But I didn't copy/paste Claude's summary and claim it as my own. I didn't even paste it into my notes. Instead, I used Claude's answer to refresh my understanding, and then I wrote that understanding in my own words in my notes. Then I rewrote a clean version for the blog.
Here is my question and answer:
Q: What is the core premise of Thinking, Fast and Slow?
There's a dual process to human cognition: fast and slow. "Fast" is referred to as "System 1" — it's emotional, makes rapid judgements based on instinct, handles routine tasks, habits, cognitive bias and errors, little effort. The "Slow" thinking is "System 2" — slow, deliberate, logical. Engages in complex reasoning and critical thinking. More analytical and rational. Requires far greater effort and cost.
It’s my opinion that one of the best hedges against AI taking your job — or taking opportunity to have a career at all — is to enhance your ability to think deeply and critically, and to combine ideas across topics in creative ways. Don't use AI merely to save time. Use it to do harder things.
Conclusion
Maybe I'm not offering anything groundbreaking here. It's a combination of note taking, the Socratic method, Amazon’s “5 Whys,” todo-lists, and FAQs.
But I think this combination is unique. It's simple and easy. It's a lightweight process. It only requires the effort to slow yourself down and commit to it.
This process has had a powerful effect on my day-to-day effectiveness as a software developer. It’s paid dividends over the last eight months. It is one of my best tools for learning and solving problems, and I hope it can help others.
So if you are interested giving it a try, go FAQ yourself.
Footnotes
Obsidian has a Template feature where you can define a template, and then insert it into any note. My Q/A format is pretty simple, so this template doesn't save much time. But it's handy to have.
If the verb "capture" reminds anyone of the capture step in the "Getting Things Done" workflow, then you are dead on. It is the same principle, and has the same benefits.
For more, checkout Amazon's COE Guide and ctrl+f "The 5 Whys"
LLMs are impressive tools, but they are not AI. They are very good natural language processors combined with enormous contextual models that allow them to answer complex questions with complex answers drawn from many sources. But they are only as good as what they are trained on. And they are expensive to train. This talk by Jodie Burchell does a great job de-hyping LLMs without diminishing their usefulness.