Question the Question

Some things are impossible, for a variety of reasons. One of the biggest challenges in software engineering, and I suspect other scientific domains, is not figuring out the direct answer to every question you're asked but rather figuring out if the framing of the question has posed a question that is impossible to answer.

If you don't think you can answer a certain question, or you find yourself confused when you walk the mental path you think you should to try and answer the question, you should ask the question - can this be answered? What are the assumptions that would lead me or someone else to ask this question? Are those all correct?

It's not giving up, sometimes it's the question that's the problem.

For example:

1. Are the logs you would need to determine the root cause of the issue even available? What logs would allow you to determine the root cause?

2. Can you determine the number of times a race condition will occur in production by creating code that monitors for the race condition without re-introducing the race condition in the code that is supposed to monitor for the race condition?

Sometimes you won't be able to know, but you have to know how to know if you can figure it out or not, or what you need to do to figure it out if you can't based on your current assumptions / context. In engineering and science, it's perfectly possible to conceive of and waste a great amount of time trying to answer a question that cannot be answered the way you are trying to. The trick is in knowing how to quickly identify when you're going down the path of trying to answer an unanswerable question or build an unbuildable system.

Never say “never say never”. Some things are impossible.