[outworlder]

> When people ask me about my life’s ambitions, I often joke that my goal is to become independently wealthy so that I can afford to get some work done. Mainly that’s about being able to do things without having to explain them first, so that the finished product can be the explanation. I think this will be a major labor saving improvement.

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.

[wolfram74]

When I first started pair programming, I found the most important part was even if I had a solution that would work, if I couldn't explain it to my partner, it was not a very good solution.

Being able to convey an idea often forces it to be closer to the simplest and most comprehensible version of that idea.

[krisoft]

> if I couldn't explain it to my partner, it was not a very good solution

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.

[simoncion]

> ...if I couldn't explain it to my partner, it was not a very good solution.

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.

[ludston]

At an early stage of my career, a product person asked me to walk them through our code to show how a particular algorithm worked so that they could verify it worked according to their initial design.

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.

[ludston]

Can you give an example of a solution that you came up with that you decided couldn't be very good based on it being hard to explain?

[darkerside]

Probably not that you'd understand very well

[xyzelement]

On the flip side, if you can't get people to get excited about the problem and solution now, what are the chances you're totally on the mark - and even if you are, whether you can get them to care after?

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"?

[ozim]

For me worst part is just like in article that I have to explain to people first and only then I can start.

[jackpirate]

One of the reasons I've intentionally decided not become independently wealthy is that I want to have to explain to other people why I'm doing things. Part of my work is "charity-ish", and by not being able to do things on my own, I'm forced me to improve my communication skills and involve other people in these charity activities. I think that ultimately improves the final outcome, even if the process is immensely more frustrating.

[wwweston]

Accountability (including the light form of it represented it by explanation) is super useful in refining personal development.

And I'm starting to believe the reason power/status corrupts is that it removes it as an option for character development.

[ozim]

I am referring to technical work specifically. Where most of the time people don’t even know what they want until they see it.

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.

[mewpmewp2]

Could be so with charity or depending on the field I suppose. I think innovating or figuring out new tech is different as if something is easily understood and explainable, it's probably already done, and if you have a great idea that hasn't been done it's probably because it's really hard to explain or to sell to others on it.

[MichaelZuo]

I don't get this. Did you not attempt to verify something that important was actually understood?

[ivanbakel]

That presumes that communication is just about people understanding the thing you are trying to say, rather than the transfer of thoughts, ideas, and opinions.

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.

[MichaelZuo]

Methods such as reviewing their work, observing their actions without them knowing, testing them in some form, literally sitting behind them, etc..., will quickly reveal someone's true disposition towards whether the 'sky is on fire', regardless of what might be said.

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.

[ivanbakel]

I agree - as I said, you can see the results in the actions of the other party. But those are all techniques beyond communication: none of them allow you to verify, in the moment, whether or not the other person has "understood" you in the sense of agreeing with what you have to say.

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?

[MichaelZuo]

> But those are all techniques beyond communication: none of them allow you to verify, in the moment, whether or not the other person has "understood" you in the sense of agreeing with what you have to say.

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.

[ivanbakel]

>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.

[cptaj]

I bet he did. I bet they confirmed they had understood.

Life will slap you with this lesson time and time again.

[hinkley]

See also the documentary scenes in Guardians of the Galaxy 2 with Groot and the dangerous red button that will kill everyone.

It's not funny because it's absurd, it's funny because it's almost plausible.

[dataflow]

I don't know what they had in mind, but I'm guessing something like "we need to refactor/restructure our code, it's a mess right now" might fall into that bucket.