Another person making their stream-of-consciousness available for everyone to see...

Saturday, July 9, 2016

Knowledge Vacuums

As the title of this blog would imply I'm generally pretty happy to talk tech with people when the opportunity presents itself. I also don't mind showing someone new how to do something if they ask about it. This is a great way to meet new people and get folks who are on-the-fence about electronics or computer technology to start getting interested.

There are, however, people who can best be described as knowledge vacuums. If you've ever encountered one, you will instantly know what I mean. These are people who ask question after question after question on a topic without ever doing any requisite discovery of their own. In fact, if they're like the person I encountered recently, they will freely admit that they "don't have the time to read all that stuff." I thought I would take a moment to identify the behavior and why it is bad. It will hopefully help arm those who have been victim to this situation to understand the dynamics, and hopefully deflect it to a more productive place (or at least, more than likely, to some other unsuspecting victim). If you're actually one of these people (and it's not likely you are, since you wouldn't take the time to read this), it will help you better communicate with someone who knows something you would like to know.

To help protect the guilty, I am going to choose a different topic from the one I was asked, but it won't be difficult to reconstruct the dialogue in a similar way.

To set-up the scenario: I am having a casual conversation with someone I see about once a month, in a place where I will be be speaking one-on-one for about 15 to 30 minutes. I am there because I am doing a favor for them. Let's call this person V (for vacuum).

During the conversation, V asks me, out of the blue, "What can you tell me about microcontrollers?"

Now it happens I know a fair amount about microcontrollers. Not everything, but I know my way around the block. The problem is that there is no possible way I can answer this question. So I reply, "That's a pretty big topic. What do you need to know?"

V responds, "Well, I don't know a lot about microcontrollers, but we're using one at work and I have to know how to connect a LED to it and make it blink on and off."

In this short period of time I have now gotten several good pieces of information that I will likely ignore. First is that V has been unwilling to do any basic research to find more information about the task they are being asked to do. Second is that they are not at all competent with the topic at hand, since making a LED blink is a pretty basic operation that a microcontroller can do. Finally, I am being asked to convey, in a casual setting, a piece of information that is more appropriate for a white board and maybe even a solderless breadboard for demonstration. The conversation continues.

I ask, "What kind of microcontroller are you using?" V says, "Well, they say it's like the one used in the Arduino, but I don't really know. All I really need to know is how to get the LED connected to it and make the LED blink."

I ask, "Well, do you know the drive capability of the GPIO pin that will be used to control the LED?" V responds, "I'm not sure I know what you mean." "Well, for example, if the GPIO pin can only provide 2 milliamps of drive current and the LED needs around 15 milliamps, then you'll need a transistor or such to drive the LED," I respond. V appears more confused, and asks, "How would I know if the LED needs more current than the GPO pin needs?" (note: V says GPO instead of GPIO).

It is now clear that V not only does not understand much at all about microcontrollers, but V also doesn't really understand how devices are electrically interfaced to circuits in a digital system.

At this point, it is clear to me that this conversation will require more than the 15-20 minutes that I am going to have with V. I respond, "Look, this is actually a pretty in-depth conversation. Would you have some time later to talk about it?" This is a polite way of saying, well, that it's going to take more than 15-20 minutes, and maybe you're needing a tutorial from somewhere. V says, "Well, I don't really have time because I'm so busy doing work and caring for my sick father."

This is where the conversation has clearly crossed the boundary between showing someone how to do something and a knowledge vacuum situation. With this said, here are some of the tell-tale behavior patterns associated with knowledge vacuums (and why it is bad):

They know so little about the subject matter they're inquiring about that they don't know how to ask an intelligent question. What isn't obvious is that they really don't want to know any more, either. They just want enough to solve their problem so that they can declare themselves as subject matter experts.

There is no desire to take the discussion from the casual realm into a teacher/student realm, generally due to some kind of emergency circumstance. The person assumes that you are just trying to make the subject more complicated than it really is, and that you could just answer their question in the short time available and they would know what they need.

There is no desire to read any material prior to the discussion, to become familiar with basic concepts. This implies that your time is not important and that it is perfectly acceptable for you to do the reading and understanding of the subject at hand, and then process and regurgitate what you learned to others. This is just rude.

This person is not really interested in the subject, but rather is trying to get enough information to appear that they know more than they do to someone else. It indirectly belittles the passion that you have for the subject.

So how would this situation work better?

V should have done some basic reading about microcontrollers. Do a search on interfacing LEDs to microcontrollers, and look at Wikipedia pages about microcontrollers. As V was reading the text, it would become clear that there were additional topics that needed investigation, and that process could be repeated recursively.

Don't begin the conversation with, "What do you know about microcontrollers?" Begin with, "I'm trying to interface a LED to a microcontroller and am completely lost. Where should I start looking to figure out what to do?" While this is still a bit difficult to answer, it better sets the scope and tone of the conversation, and immediately jumps to the inevitable questions about drive current and GPIO pins.

If V was further confused, it would be appropriate to realize that they were over their head and say, "I think I need to look at this a bit more. I will come back with more questions later, but now I have a place to start looking." This indicates a willingness to do the work required to learn about the topic, and is respectful of the time of the person being asked.

FInally, if it is clear that the topic is too complicated for casual discussion, V should have accepted the invitation to discuss the topic further at a later time, and offered to buy dinner or provide reciprocal help in return. This conveys an understanding that the time and knowledge of the person being asked is valuable.

Sometimes, while it may seem rude, the best response to this is to derail the conversation (as hard as it is when you're passionate about a topic) as soon as possible with, "I know you're busy but this topic is a bit too complicated for casual discussion. I don't think I can help you."