IME, if this is a problem, turning it around and asking the other person questions about what you’re discussing is a way to both get them engaged in the topic, and identify gaps in their understanding so you can work towards filling them.
Not a perfect solution, of course, but questions are a powerful way to turn a passive listener into an engaged participant in the conversation.
This is part of communicating. The idea that you can just spew out the perfect set of sounds and everybody “worth your time” will just grok you is a sure sign of being a shitty communicator.
I’m a shitty communicator too, but at least I know it :)
If somebody is overloaded or trying to do something or understand something…. Telling them what to do is useless. Your voice is just “Noise in their Head”.
If they have a bee stuck in their bonnet… you can talk until you blue in the face, all you will do is frustrate everybody.
Sometimes “Show, don’t Tell” will break the impasse.
Yeah, I think this is the point of the blog post. Even if somebody has the “Listening Attentively” superpower, and even if they are calm, collected and think they are getting it, it is still sometimes nigh-on impossible to “just tell” them anything.
Listening attentively also involves verifying what you’re hearing, repeating it back, in a sense, not just nodding your head. Truly listening well can effectively act as a parity check on the other persons’s ideas. Many folks don’t practice this sort of conversation, though, because it requires investing yourself in another person’s mental landscape, which isn’t often valued, outside of the therapy profession.
I’ve taken to describing this class of things as “Stuff so important that nobody ever talks about it.” As in, the assumptions that are deeply embedded but seem totally basic to an insider.
But yeah, I get it. There are so many arenas where I could talk for days, or we could just sit down and work together for a few hours.
This is a very personal and painful lesson for me.
When I started trying to coach developers and teams, I thought I would just ask them what they needed to know, then tell them. I did this. Many times. Every time they nodded and looked happy. Every time they didn’t get it.
People speak and use language conceptually. We wave our hands, we use broad terms. It all works out because, frankly, in the real world nobody cares about the details. But when we start taking that to formal systems like computer programs and architectures, the details matter. So here we are, dumb humans, still speaking, gesticulating, and communicating conceptually. We smile. Everybody is happy doing this.
But then at some point somebody has to start actually working. It’s at this point a critical decision is made: do I go back to that person and have long conversations with them where I try to pin down exactly what they were talking about? Or do I do what I do with everything else: take the conceptual, general, fuzzy idea and replace it with some technical muscle memory stuff I already know?
It is very rare to see the first option taken, especially with the modern development environment consisting of so many contractors, vendors, senior developers, remote teams, and so forth.
In my first book I talk about one of the main problems with communication is that there’s not some big red light that starts flashing when it’s not working. Instead, everybody has a good time and goes on about their business. It might be months or years — or perhaps never – when somebody finally figures out that the communication was not working as it should. Even then, as this essay shows, you can finally figure out it’s broken and never have an idea of exactly what or why.
Did you ever have a chance, or any luck with trying to get people to explain what you said back to you? Or what were your experiences with that side of things?
Explaining back was the first thing I tried. I found that people are very good at parroting and mimicking things they hear. I also tried simulations and games. People love good games! They were even more enthusiastic when we did good games that demonstrated complex concepts.
Unfortunately, this only made the feedback problem worse. I would create training material, show some code, talk about concepts, tell stories about how I used those concepts, create and play really fun games with the folks. The better I got at that, the more “positive” feedback I was receiving. What a great trainer! We had a blast at that new class and learned some really good stuff! They felt good. I felt good. I got great reviews and ratings.
But this is very similar to the self-help book problem: the promise you get from a book, the feeling you get while consuming the book, the great recommendations you’ve heard and that you give to others, the imagined future you think you’ll have by applying the book? That’s a completely different thing from actually getting value say five years later from the book. The better those things are, the better everybody feels, including the content creator, but it doesn’t track at all with long-term real value.
I did find an answer: smaller concepts presented, demonstrated, and then executed round-trip by the participants. Participants can either round-trip them as a group or individually. Both strategies have benefits. So, for instance, if you’re talking about C++ class inheritance, you’d show some concepts, say the diamond pattern, you’d code some on the screen, then you’d present a problem for people to work through that involved it. People were not complete until they solved the problem round-trip, from description to executing code. When they did that, you’d find all kinds of stuff that each person had assumed that others did not. Oh, you keep classes in separate files? Why’s that? You explicitly type a polymorphic relationship as close as possible to when you use it? Why’s that?
None of these necessarily have right or wrong answers. It’s the cognitive load of all of these tiny little details that prevents the application of the high-level concept to their day-to-day work. So you have to work through them, talk about each of these little details. They don’t need the perfect way to group classes, files, and project folders, for instance, but they need some kind of example that they can mimic for a bit until they begin more learning in that area. Silly things like project file/folder grouping sounds trivial and inane to folks who have coded for a long time, but you stack a few dozen things like that, different for each participant, and you’ve got an insurmountable obstacle for practical learning.
A friend and I have a theory that soon everyone will have their own AI that knows them and their personal language/learning model intimately well - better than any single person could after a lifetime. These AI’s will be able to do the incredibly complex work of the ‘translating’ of things someone is trying to tell you, or questions you’re trying to ask or goals you have, to/from your/their learning model.
Clearly communicating really is a superpower.
Sadly, it’s useless unless you’re talking to someone with the “Listening Attentively” Superpower.
IME, if this is a problem, turning it around and asking the other person questions about what you’re discussing is a way to both get them engaged in the topic, and identify gaps in their understanding so you can work towards filling them.
Not a perfect solution, of course, but questions are a powerful way to turn a passive listener into an engaged participant in the conversation.
This is part of communicating. The idea that you can just spew out the perfect set of sounds and everybody “worth your time” will just grok you is a sure sign of being a shitty communicator.
I’m a shitty communicator too, but at least I know it :)
Actually, step 0 is patience.
If somebody is overloaded or trying to do something or understand something…. Telling them what to do is useless. Your voice is just “Noise in their Head”.
If they have a bee stuck in their bonnet… you can talk until you blue in the face, all you will do is frustrate everybody.
Sometimes “Show, don’t Tell” will break the impasse.
Yeah, I think this is the point of the blog post. Even if somebody has the “Listening Attentively” superpower, and even if they are calm, collected and think they are getting it, it is still sometimes nigh-on impossible to “just tell” them anything.
Listening attentively also involves verifying what you’re hearing, repeating it back, in a sense, not just nodding your head. Truly listening well can effectively act as a parity check on the other persons’s ideas. Many folks don’t practice this sort of conversation, though, because it requires investing yourself in another person’s mental landscape, which isn’t often valued, outside of the therapy profession.
I’ve taken to describing this class of things as “Stuff so important that nobody ever talks about it.” As in, the assumptions that are deeply embedded but seem totally basic to an insider.
But yeah, I get it. There are so many arenas where I could talk for days, or we could just sit down and work together for a few hours.
See also:
This is a very personal and painful lesson for me.
When I started trying to coach developers and teams, I thought I would just ask them what they needed to know, then tell them. I did this. Many times. Every time they nodded and looked happy. Every time they didn’t get it.
People speak and use language conceptually. We wave our hands, we use broad terms. It all works out because, frankly, in the real world nobody cares about the details. But when we start taking that to formal systems like computer programs and architectures, the details matter. So here we are, dumb humans, still speaking, gesticulating, and communicating conceptually. We smile. Everybody is happy doing this.
But then at some point somebody has to start actually working. It’s at this point a critical decision is made: do I go back to that person and have long conversations with them where I try to pin down exactly what they were talking about? Or do I do what I do with everything else: take the conceptual, general, fuzzy idea and replace it with some technical muscle memory stuff I already know?
It is very rare to see the first option taken, especially with the modern development environment consisting of so many contractors, vendors, senior developers, remote teams, and so forth.
In my first book I talk about one of the main problems with communication is that there’s not some big red light that starts flashing when it’s not working. Instead, everybody has a good time and goes on about their business. It might be months or years — or perhaps never – when somebody finally figures out that the communication was not working as it should. Even then, as this essay shows, you can finally figure out it’s broken and never have an idea of exactly what or why.
Did you ever have a chance, or any luck with trying to get people to explain what you said back to you? Or what were your experiences with that side of things?
Explaining back was the first thing I tried. I found that people are very good at parroting and mimicking things they hear. I also tried simulations and games. People love good games! They were even more enthusiastic when we did good games that demonstrated complex concepts.
Unfortunately, this only made the feedback problem worse. I would create training material, show some code, talk about concepts, tell stories about how I used those concepts, create and play really fun games with the folks. The better I got at that, the more “positive” feedback I was receiving. What a great trainer! We had a blast at that new class and learned some really good stuff! They felt good. I felt good. I got great reviews and ratings.
But this is very similar to the self-help book problem: the promise you get from a book, the feeling you get while consuming the book, the great recommendations you’ve heard and that you give to others, the imagined future you think you’ll have by applying the book? That’s a completely different thing from actually getting value say five years later from the book. The better those things are, the better everybody feels, including the content creator, but it doesn’t track at all with long-term real value.
I did find an answer: smaller concepts presented, demonstrated, and then executed round-trip by the participants. Participants can either round-trip them as a group or individually. Both strategies have benefits. So, for instance, if you’re talking about C++ class inheritance, you’d show some concepts, say the diamond pattern, you’d code some on the screen, then you’d present a problem for people to work through that involved it. People were not complete until they solved the problem round-trip, from description to executing code. When they did that, you’d find all kinds of stuff that each person had assumed that others did not. Oh, you keep classes in separate files? Why’s that? You explicitly type a polymorphic relationship as close as possible to when you use it? Why’s that?
None of these necessarily have right or wrong answers. It’s the cognitive load of all of these tiny little details that prevents the application of the high-level concept to their day-to-day work. So you have to work through them, talk about each of these little details. They don’t need the perfect way to group classes, files, and project folders, for instance, but they need some kind of example that they can mimic for a bit until they begin more learning in that area. Silly things like project file/folder grouping sounds trivial and inane to folks who have coded for a long time, but you stack a few dozen things like that, different for each participant, and you’ve got an insurmountable obstacle for practical learning.
Thanks for taking the time to explain things more!
A friend and I have a theory that soon everyone will have their own AI that knows them and their personal language/learning model intimately well - better than any single person could after a lifetime. These AI’s will be able to do the incredibly complex work of the ‘translating’ of things someone is trying to tell you, or questions you’re trying to ask or goals you have, to/from your/their learning model.