3

As a junior developer working on a rather complex system, I find myself in this situation constantly. A fellow programmer is explaining a topic that is relatively complex but I am following along with their thoughts enough as I deem appropriate.

But then they'll mention something that I'd like clarification on and would like them to explain, even if it may only be tangentially related to the big picture. It's like that minor point has acquired an exclusive lock on my cognitive reasoning ability. I just want to know how THAT works.

However, they are on a roll explaining the system, while I can't seem to stop thinking about that one thing that's confusing to me. Should I be interrupting more often or should I work on my own inability to let little things go and try to focus on just picking up the gist of what is being described after a snag point?

migrated from programmers.stackexchange.com May 13 '16 at 13:42

This question came from our site for professionals, academics, and students working within the systems development life cycle.

  • 2
    I face this problem daily. The problem is that you might be thinking about various possiblities that they didn't think. If the problem you are thinking is very clear to you and if you can communicate to them easily then interrupt then and ask them. If you haven't really understood it well yourselves, just note it down and try to form the question so that it can be explained to someone else. It is very important to formulate questions, it often clears your own doubts. Its as important as finding the answer. – Nishant May 13 '16 at 3:55
  • 3
    While I agree with @Nishant's comment, I also think there is a huge dependence on the nature of who is talking. Some people don't tolerate interruption, and it is not always that are rude, sometimes it's just that it breaks their flow, or train of thought. Others are more tolerant of that and may even enjoy the two-way dialog wherever it leads even if on a tangent. It is reasonable, I would think, to for listeners to ask the speaker if they would prefer questions held (e.g. until the end of the explanation or story); I think the same speaker would often have the same sentiment. – Erik Eidt May 13 '16 at 4:43
  • At work I suggest to write down your doubts. Don't be afraid to ask to the speaker to go a bit slow bc you need to take notes. Once the talk is over try to summarize to the speaker what you understod. Then introduce your doubts and do questions. Ask as many times.you need. Don't be worry to ask for repeat these things are not yet clear to you. Finally try to summarize it again to your job mate. If you are able to explain it you got it. And NVR lose your curiosity about how things works – Laiv May 13 '16 at 4:59
  • 2
    This feels like more of a "mental discipline" question than a workplace one but I'd say it's borderline on-topic. I've dropped the "or a friend over a beer" from the question to avoid this attracting close votes on that. – Lilienthal May 13 '16 at 13:53
  • @Laiv: The word "doubt" has significantly different meanings in different dialects of English; for many of us it is not interchangeable with "question". In international discussions, I suggest avoiding it entirely. – keshlam May 13 '16 at 15:25
16

Write down your question and release the exclusive lock. When your cohort is done hearing himself talk, read what you wrote down to jog your memory, and ask him the question.

  • +1 Even though writing down a question during a beer with a friend just feels weird. If it were a friend I would just say "hang on, insert question here – Kiwu May 13 '16 at 13:49
  • When paper isn't available, holding your hand in the shape of a trigger word or letter can be a helpful reminder to yourself. For example: keeping your hand in a sign-language "b" to ask about the contents of a box can help you to listen and still job your memory when the time is right. – pft221 May 14 '16 at 6:00
  • Thanks! I am going to start insisting on grabbing some paper before one of these Sr. Dev University lectures begin in the future. The hard part will be learning to truly release the question and refocus once it is written down. – jvanstry May 17 '16 at 13:44
3

"even if it may only be tangentially related to the big picture"

Learn to differentiate between what is essential for understanding, and what is a true tangent. If your question isn't a tangent, you need to interrupt. Your "understanding" questions need to be asked in the moment, otherwise the rest of the explanation will fly over your head.

If your question won't help you to understand what he is trying to teach, you should put it in the "parking lot." Most people will give you an opportunity to ask questions if they are explaining a complex system. Save your "parking lot" questions for that opportunity.

  • 1
    Excellent answer. I just want to add that the "parking lot" can just be represented by a small note on a piece of paper, a one word scribble on a napkin, or a knot on a string in your pocket (if nothing else is available to jot down the question). The knot may not be sufficient to recall the entire question, but it works for me about 50% of the time and it's better than nothing when nothing else is available right at the exact moment. I should say that I'll try to write down the question one or two minutes later, and that I use that knot as a reminder of doing that since I keep it in my hand. – Stephan Branczyk May 14 '16 at 3:57
  • Sometimes I find that I things I think are tangential, when they turn out to work the way I suspect they do, help solidify or, when they don't, refine my mental model of the system. Also, even trying to make this parking lot determination while listening to further explanation results in the same type of blocking behavior on my attention that I described in the question. – jvanstry May 17 '16 at 13:41
2

At a certain point, you have to turn the lecture into a conversation.

I often ask people to pause, and then say something like

"I need to run that back to you. Have I got this right?"

and then I ask true/false questions:

"So, at this point we haven't initialised anything?"
"Where does that variable get set?"
"Don't we want to do X at this point?"

The thing I find all the time is that developers explaining things assume more information is better, and will often over-explain or overwhelm when they should be slowing down. Your part is to flag this up, invert the conversation, and attempt to pull out the facts you need, and have them confirm your understanding.

(Of course, there might seem like a power/experience imbalance makes this 'rude' somehow, but you've gotta do it anyway)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.