Agreed. The worst part is when they nod and pretend they got it and then that really important thing that you thought you had communicated everyone that was akin to the sky being on fire is not being prioritized/funded/worked on.
Agreed. The worst part is when they nod and pretend they got it and then that really important thing that you thought you had communicated everyone that was akin to the sky being on fire is not being prioritized/funded/worked on.
Being able to convey an idea often forces it to be closer to the simplest and most comprehensible version of that idea.
I've found that in situations like that, I just write out a prototype and that clears up the confusion.
Usually, what I'm trying to explain is good, but there's some context that I can't get out of my head and into theirs that's critical to understanding the thing I'm trying to explain.
Since I was using higher-order programming to control dispatch of various business rules, and they were not familiar with higher-order programming at all, there was a bit of a communication barrier/learning barrier that needed traversal.
Absolutely. I used to work in an aviation company writing software. When we were discusing architectural decisions (big or small) we often played around with the following thought experiment: Imagine that there was an accident with an airplane which was using our software. Maybe it was our fault, maybe not. Nobody knows. You are sitting in a cramped room with an irate NTSB investigator who points at this part of the code and asks “why on earth did you think this was a good idea?” If you don’t have a good and easy to understand answer to this question maybe we shouldn’t do it that way.
What do you think is the ratio of "they didn't understand my genius until I built it" to "I built it and nobody cared or used it"?
And I'm starting to believe the reason power/status corrupts is that it removes it as an option for character development.
Creating mock-ups and going back and forth costs time and money.
While most of the time what I do is good enough - I am getting tired of people trying to block work until unimportant details are “discussed”.
It would not be frustrating if customers would be willing to pay for mock-up work and then for actual work but what most want is working application right away not mockup but they also want to waste time blabbing about details that would be clear in mock-up or in first version of the app.
Life will slap you with this lesson time and time again.
It's not funny because it's absurd, it's funny because it's almost plausible.
Put another way: the only thing that you can verify when communicating that the sky is on fire is that the other party knows you think the sky is on fire. Whether or not they think the sky is on fire, or whether they think you're blowing hot air, is pretty inscrutable. If they don't agree with you, they're still likely to not show it because you (to them) are a neurotic hothead who they don't want to upset.
The only truth in what you manage to communicate to people is the effect it has on how they act. In other words - they can't tell you anything! They can only show you.
At least I've never heard anyone that could convincingly fake such a big difference under focused observation, assuming the verifier is competent.
For example, veteran car mechanics can tell in a minute when someone's never worked on a car in their life, just by asking them to do an oil change, or some other quick task.
And they can easily and reliably differentiate the folks who only occasionally work on cars vs those who regularly do with a half hour of observation in the shop.
The idea of verifying after communicating is in line with the original article, and the comment by outworlder. What do you think they failed to consider?
Huh?
To clarify, in my example of the veteran car mechanic assessing someone's proficiency, there's no set-up required, they can verify it 'in the moment'.
No special or unusual tools or environmental conditions are needed to conduct verification.
Well at least some environmental conditions are required: if you ask someone to change an oil filter, there has to be a car in the environment to do it on. To get any value of out of it, you also have to be able to oversee the process - it's no use if you're instructing someone over the phone, for example.
More generally, I think the point of the original post, and the original comment, are that verifying that something was communicated successfully requires out-of-band actions. Physically demonstrating something, or watching someone demonstrate something, are both out-of-band: neither work over all communication channels, like user manuals, or phone calls.
Even in-person communication is often restricted to make verification difficult: imagine if you're in a water-cooler meeting with another developer, and you mention that you think they should take a different approach to a certain problem. Are you going to follow them back to their desk to verify that they really choose to do so? Probably not: it's both incredibly rude, and a bad use of your own time. But there is nothing in the water-cooler conversation that you can really do to check that they'll take your advice.
Of course? That's the implication of not just taking someone's word for it in the context of an office environment.
> Even in-person communication is often restricted to make verification difficult: imagine if you're in a water-cooler meeting with another developer, and you mention that you think they should take a different approach to a certain problem. Are you going to follow them back to their desk to verify that they really choose to do so? Probably not: it's both incredibly rude, and a bad use of your own time. But there is nothing in the water-cooler conversation that you can really do to check that they'll take your advice.
That would be the case if it was a trivial matter. But for really important things, then I don't see a problem?