“There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question.”
― Carl Sagan, The Demon-Haunted World: Science as a Candle in the Dark
As digital forensics practitioners involved in both consulting and software development, we have a great deal of respect for Carl Sagan. If we could compel our colleagues in digital forensics to read a single book, it would be Sagan’s “The Demon-Haunted World: Science as a Candle in the Dark.”
It seems that people who leverage Sagan’s “no such thing as a dumb question” quote often fail to provide some important context – he was referring to children, not adults.
Of course there are dumb questions. If you need examples involving digital forensics, just ask anyone that provides support (especially free support) for free and open source software. At Arsenal we know that questions can not only be dumb (we are reformed offenders), but given our experience in litigation, misleading and even weaponized to harm… without answers ever being involved. Lawyers know this, and if you are a digital forensics practitioner, you should too.
Let’s focus on the support of free and open source software.
For years we have been happy to provide support for our tools to anyone who contacts us, whether they are our customers or not. I wrote this Insights article after a particularly frustrating week providing free support, because I reached a boiling point that I do not want other members of my team to reach. We have seen a disturbing trend in support requests, particularly from people looking for free support for our free tools. The questions (and associated behavior) have seemed to get more dumb and disrespectful over time. Whether the quality of the questions we receive has anything to do with a “participation trophy” environment in education is above our pay grade (we have our suspicions)… so for now we will provide some practical advice on how to ask smarter (e.g. more effective) questions, particularly when requesting free support from free and open source developers.
1. Tell us who you are. This is a common courtesy. When someone communicates one-on-one with me, I tell them exactly who I am. The same goes for members of my team. I am making a significant change to our support policy today, and we will no longer be providing free support unless we know who we are communicating with. The intensity of dumb questions, and the hostile responses we get to answers people don’t like, increases significantly when we are communicating with anonymous individuals.
2. Tell us the truth. For example, if someone is thinking about doing something so shady (perhaps involving an unsuspecting coworker, or a significant other) that they feel the need to lie to us… they should consider not doing that thing.
3. Do not send subordinates to us regarding technical issues you have. We tend to get very technical support requests, and for some reason it seems that subordinates frequently come to us with the kinds of questions that require in-depth troubleshooting. This is incredibly aggravating, not only for us but probably for the subordinates as well. Let’s troubleshoot together and in good faith, without involving middlemen.
4. When we ask questions, answer them. We ask questions for a reason while troubleshooting. Answer all of them, not some of them.
5. Be polite. We consider ourselves to be very friendly people, and demonstrably so… we provide free support (and not the hand-wavy kind) to people using our free tools. Whether it’s being lazy, passive aggressive, or outright hostile, do not insult us when we are trying to help.
6. As you formulate your questions, and work through answering them, actively consider your expectations. Why are you expecting something to exist? Why are you expecting something not to exist?
7. If you are a digital forensics practitioner, you should take pride in how you formulate and resolve questions – whether those questions are related to a case or getting support for one of your tools. If you haven’t already, get a cup (a big one) of your favorite coffee and carefully review Eric Steven Raymond and Rick Moen’s “How To Ask Questions The Smart Way” at http://www.catb.org/~esr/faqs/smart-questions.html. Not everything you see in this document will be relevant to you (and to the time we live in generally), but most of it should be. Longer term, read and occasionally revisit the aforementioned “The Demon-Haunted World: Science as a Candle in the Dark.” Remember, asking smarter questions does not involve an on/off switch, but a constant struggle.
8. Formulating a smart question and seeing it through to a solution should make you feel good – especially when dealing with a difficult technical challenge. Take some time to appreciate these kinds of victories, and be hungry for more.
Ultimately, people involved in digital forensics (in any way) should hold themselves and others to a higher standard when it comes to asking questions and seeing them through.
Ourselves included.