How Not to Ask Questions After a Talk
Dedicated to the memory of Mrutyunjay Mishra (M2). He was a torrent of ideas. He encouraged me to write this post because as much as he talked endlessly without pausing to breathe, he hated wasteful discourse.
New Delhi, January 2024
PyCon India 2017 ended last weekend in Delhi. The conference escaped the infamous winter smog-storm by a whisker. In the last few years, PyCon India has grown to become the largest PyCon outside of North America, with over a thousand participants attending from all over the country. The conference itself was driven by a team of about 50 volunteers.
I was one of them. I have been involved in PyCon India, in different capacities, for the last seven years. To me, PyCon season is like Christmas, and the community is like family — it is a chance to meet all your favourite cousins, and the uncles and aunts you look up to. There is also a fair share of annoying grandparents. This year was a little different. I had the privilege of being the programme chair (meaning I was responsible for the content of the conference — especially, the quality of the talks and workshops) and I was also the emcee of one of three parallel tracks in the conference (meaning I was responsible that things run smoothly on the ground). The latter, especially was quite a tiring experience.
As the emcee, one must get in touch with all the speakers in advance of their respective talks and make sure they have everything they need to make their experience smoother. This involves making sure that they have their slides in order, they can connect their laptops to the projectors (if they insist on using their own laptops and most of them do), they know their time limits, and they have signed consent forms allowing PyCon to publish the recordings of their talks.
There is very little time to relax. Unless it is a lunch break, you are either in the middle of a talk keeping an eye on the stopwatch or you are in the space between two talks. This is the most chaotic of times. This is the time when you have to locate the next speaker and make sure they are ready, while simultaneously ensuring that there is someone running around with a microphone taking questions from the audience. Secondly, the auditoriums are huge! They have to be, to accommodate hundreds or even a thousand people. This year PyCon India was hosted at the Shaheed Sukhdev College of Business Studies, which had this beautiful auditorium:
The main auditorium at the @pyconindia venue. Looking forward to the next four days. #pyconindia pic.twitter.com/B2B6EYG2Oh
— Jaidev Deshpande (@jaidevd) November 1, 2017
It is one of the biggest auditoriums to have hosted a PyCon, second only to the NIMHANS auditorium in Bangalore. The auditorium was broadly divided into three “columns” of seats on the lower level and four on the upper level. This meant that we needed at least seven volunteers with microphones who would be running around taking questions from the audience. We managed to make do with five volunteers since there were not too many seats on the upper level. Nevertheless, doing this exercise of running around the auditorium with mics for a couple of days made me realize something that I had only taken for granted so far — Q&A time is really expensive!
Normally, five to ten minutes are allotted for Q&A rounds between talks. Given the background, when you find that the audience (or maybe certain members of this audience) are not only not making the most of this time, but are actively wasting it, it is heartbreaking. This prompted me to deliver a lightning talk (these are short, impromptu 5-minute talks that are randomly selected from a set of on-the-spot proposals) on the ten commandments of Q&A. These are not really commandments, of course, just opinions. However, I have known people to get away with using the two words interchangeably.
1. Be Kind
You would think that this does not need to be said, but you would be surprised. The Q&A round, unlike a debate, is not supposed to be confrontational by nature. No one at PyCon would, of course, dissuade a healthy debate, but there is a time and place for it, and it is not the expensive Q&A round. More fundamental than understanding where to have a debate is the act of basic decency. Being an impolite jerk is inexcusable.
2. Don’t be a Rubber Duck
I have used rubber duck debugging a few times and I am surprised that it works. I should not be, since it is a legitimate software practice followed by a lot of people. As Einstein once quipped, if you cannot explain something to a child, you have not understood it well enough. However, a Q&A round is not an AMA session. Any detailed explanation or clarification you might want from the speaker is best taken offline.
3. Don’t Start Rehearsing Questions in the Middle of a Talk
I admit I have done this too. Sometimes, serendipitously, you see something on a slide that scratches a very specific itch, and then, you cannot stop thinking about it till the end of the talk. Since the question you have is an extremely specific one, you would understandably be worried about picking the right words to frame your questions. Unfortunately, the downside is that for the rest of the talk, you have shut yourself completely off from the speaker, and you may not even realize that the speaker had actually addressed your question somewhere in the remainder of their talk.
4. Don’t Present Your Current Problem to Try and Get a Solution
This is probably the most tempting mistake. Imagine helplessly struggling with a problem for the longest time without avail and then, running into someone who has not only handily routed the same problem, but also has a wide range of versatile solutions to it. (Disclaimer: Not all software problems are created equal — for the most part your Googling skills dictate how much luck you may have with any problem, and the rest is your perseverance.) Remember that Stackoverflow exists, and that a speaker is not Stackoverflow. Sometimes you feel that you could appeal to the speaker’s intellectual vanity by challenging them with your problem, but remember that this is of almost no interest to the audience, and there is probably no one other than you who will benefit from your question. Take it offline.
5. Don’t Try to Score Points Over the Speaker
This is almost a corollary to the first point. There is absolutely nothing to be gained by showing off or trying to dis the speaker for using a less-than-smart solution to a problem. Remember that the Q&A time is not the time for a debate. Point-scoring and one-upmanship always has an effect contrary to what you intend — it draws you out as the jerk.
6. Don’t Attack Tools or Libraries
The choice of tools is such a contentious problem in tech communities that I am surprised there is not an RPG based on it yet. You could walk into a tech conference, yell “Django is better than Flask” and watch the audience erupt into a verbal riot. Secondly, evangelism around tech tools is one of the least necessary things in technology. No carpenter ever goes on and on about how awesome a particular hammer is. Citing certain tools and libraries as examples of good software development is welcome, but being religious about them is not. In the same vein, criticising the speakers’ choice of tools in a Q&A round — X works better than Y, X is easier to use than Y, X is faster and more secure than Y — is also a no-no.
7. You May Attack Techniques
This is a corollary to the previous point. In his PyCon India 2017 talk on visualizing machine learning algorithms (video to be uploaded soon), S Anand, the Chief Data Scientist and Founder at Gramener Inc, mentioned Bret Victor’s seminal essay, Up and Down the Ladder of Abstraction. In essence, Anand pointed out that a good analyst always knows the entire abstraction ladder of their problem, and they know where on the ladder they should be when addressing a specific concern about the problem. In the discourse related to software development and technology, the abstraction should always be as high as possible. Tools and libraries are mere details, but philosophies, techniques and ideas are immortal, and often, are disproportionately more important to the longevity of a software product. Therefore, techniques and ideas are not only fair game in Q&A round, but also the debate is richly rewarding to the audience.
8. Don’t Wield (Too Much) Personal Experience
This is the tech-talk-Q&A equivalent of privilege. No matter how vast your experience be, it is not all-pervasive, and does not make you uniquely qualified — in any sense — to criticise a person’s choices or experiences. Some attendees are also very tempted to teach or guide the speaker on what they think would be the best solution to the speaker’s technical problem. Most speaker’s are not exactly looking for solutions from a crowd of attendees. You may, of course, out of nothing but pure helpfulness offer advice, and that is a very kind thing to do, but please do so offline.
9. Use Google First
The most avoidable questions in any Q&A round come in the form of asking for facts. A simple Google search can answer questions like, “Does library X support Y?” or “Will it work on Windows?” Such questions in a Q&A are at best, wasteful.
10. DRY — Don’t Repeat a Slide in Your Own Words
Starting a question with, “So what you are saying is… ” is a very telling sign that the next few minutes are going to be full of things you already heard. It is understandable — and sometimes even healthy — that rephrasing a slide, or something the speaker said, in your own words is a wonderful way of validating your own knowledge (somewhat like an inverse Rubber Duck debugger). However, like many other things on this list, eventually it is irrelevant to the broader audience.
The next time you find someone making these mistakes, feel free to share this article with them. I am aware that it is much easier to talk about ‘Don’ts’ than ‘Do’s’. So please, let me know your recipes for a healthy, rewarding Q&A round in the comments, or let us take it offline.