Patterns in Confusing Explanations
jvns.ca
jvns.ca
My explanations got noticeably clearer once I started replacing the pronouns with whatever they would refer to instead. Sometimes I also add an additional noun ("this practice") to make the pronoun clearer.
I still overuse pronouns sometimes, but when I want to be extra sure my point gets across, I'm trying to limit them as much as I can.
The client connected to the server, then it crashed
The client connected to the server, then the server crashed. The client connected to the server, then it crashed
The client connected to the server, then the server crashed.Okay, it's obvious to you that the client didn't crash (but should it be obvious? Clients can crash too, you know!), but for anyone who didn't make the right inference, or isn't sure, they now have a dangling node in their mental model and are still validating they understood it right as they read the next sentences.
If you really can't stand such repetition, go with "then the latter crashed".
I find the use of these terms does the reader a disservice by giving them additional cognitive load.
You typically end up having to go back and read whatever was written again.
On the other hand, "under use" of "it" can also lend friction to understanding as "under use" of "it" destroys briefness. Cognitive load increases as we wade through "under use" of "it" again and again.
A little bit of it is good. Too much of it is bad.
all pronouns must have a clear, one-word antecedent.
This principle was drilled into my brain, and it's helpful.
For those who don't normally ‘subvocalize’ in their mind when reading, I guess actual reading aloud to themselves is an option.
On a relevant note: There was a post on HN a while ago which basically was about how using language (and probably, speaking out loud) is actually a `feature' or `technology' of human mind. For long, we have been mocked for speaking our thoughts out load, but turns out, it in fact helps organize thoughts and get to more logical conclusions, free of the `fluid' logic-space of the silent mind. Ironic because sometimes I'm fed up with the load rush of thoughts in my mind.
Really would like to see that post, as I've been vaguely interested in this very topic for quite a while. Is there a chance that you remember any key words that might've been in the title, so I could plug them into the HN search?
From what I gathered so far, one hypothesis is that language development went hand-in-hand with both consciousness and empathy, i.e. social cognition: as we learned to see the world from the viewpoint of others, we also expanded the abilities to communicate with others and think to ourselves.
I’ve recently realized I do the exact same thing with speech — I’ll talk without thinking, forming sentences out of heuristic systems, and process them after the fact. Then tune the sentence slightly, and continue.
In this fashion, I produce sentences without really knowing what I’ve said, until I think about it later. In much the same way that I drive long distances on auto-pilot, and can’t even remember anything of the route by the end of it.
And those sentences often have ideas that I’ve never actually put together intentionally, but I completely agree with, and upon review, are correct to the best of my knowledge.
I don’t know what speech is, but it’s definitely more than vocalization of my thoughts.
What is a pitfall however to declare these variables implicitly and rely on them too long. As a writer it is very easy to forget this because of course you know what topic you are writing about. As a reader however you have to do some work to get into the same (or similar) world of thinking as the one the writer created for you.
Same is true for speaking. Of course I know what I mean when I say something, but the other person might not even know what language I am speaking in and would have to decipher that first. In a similar way people have to decipher abstract topics you might be talking about
One feature of language that helps with this is gendered nouns. In English "a book lies on a table, destroy it" can mean 2 things. In some languages you use "her" or "him" or "it" depending on the grammatical gender of the noun even if it's not a person. If the table happens to be male and book - female - it's clear what you meant.
Unfortunately, I consider that itself annoying because it then creates the problem of assuming your reader knows which of those are just alternate phrases vs other entities in the story!
Side note: this story got reposted twice recently so my comment on one of them (with examples of me producing a better explanation than the ones I had to wade through) got neglected: https://news.ycombinator.com/item?id=28241558
[1] Oops, another anti-pattern -- saying "this" or "that" when it's not clear what you mean. Here I should have said "this problem" -- it's a great technique for clarifying your own thoughts as well!
It just so happens that the pope has all those roles at same time time
Fortunately, I don't think it's as bad to do that in fiction, because the author is going to establish how the world works to begin with, and therefore makes sure you have enough to know whether the alternate phrases mean that character or someone else, so, at worst, it's just cringey rather than confusing.
I find this happens a lot also with personal pronouns: you, we, she/he/they, etc. A buddy got angry once and said to me "Why do you always do that?!" And I was really confused. I said, "I'm really confused, why do I always do what?" And he said "ohhh, I didn't mean you, I actually meant me and how I always forget to do things."
Double pronoun confusion
I think authors are sometimes reluctant to use a mathematical style when there's no theorem in the paper. They shouldn't be. Mathematical exposition can be useful for describing experiments and results too.
That cognitive blind spot causes people to unwittingly write confusing explanations in all domains of life.
It's frequently ironic when somebody writes a sentence following the rhetorical template: "Not really sure what the confusion is with <X>. It's really simple. [blah blah blah...] And that's it."
Whether it's attempting to explain "monads are like a burrito", or neural networks, Git, or how Federal Reserve works, people unintentionally write circular definitions.
E.g. "Not sure what the issue is... Git is just a DAG directed-acyclic-graph." <-- yes, in the mind of the author, that explanation is 100% self-explanatory!
The only way to avoid the issue is to test your tutorials and explanations on a variety of readers.
If the answer is no, I need to break the concepts down more.
I picture this as a tiny editor sitting on my shoulder who asks this question as I write.
Take the above examples on explaining something about git. It will depend immensely on what you need to explain and what you don't need to explain on what the context is and what you can assume is already known or not. This can work well enough if you have something self contained to document and you are the one documenting the whole thing. It falls apart quickly as things get larger and as more people work on it.
Pre-requisite reading that you assumed the reader went through before and "knows" are moved or slightly re-written. There are multiple paths to get to the part of the docs you're writing, some of which don't explain everything. Readers skip ahead because the pre-reqs are boring or over explaining some details they don't need or already know but that makes them miss the one important thing that they didn't know but is required for your part. If you re-explain it, your part might become this boring, skip-ahead part of the docs.
There are obviously techniques that can help with this, such as pointing towards pre-requisite documentation on a particular topic in case someone doesn't know already etc. Basically doing what you said, in a structured way with hyperlinks. In my experience, most documentation writers don't know how to do this properly/don't know the subject well enough and most developers that would know enough of the nitty gritty don't want to write documentation in the first place. There are just some very few (like you I presume) that are both good at this and like it. And many places won't let you do a good job of it, because you're supposed to be coding, not writing documentation for days.
I'd kill for a NN tutorial that doesn't go "Anyway, as you can see, by multiplying the derivative by a small value we can eventually find the local minima of this curve. Anyway, just use these exact tensorflow functions with the parameters we give you and you're all set!"
The videos give you a good vibe for what a NN network does, but they still stop at "if you can get the gradients using math wizardry, then you can train your network and do tons of cool stuff!"
Meanwhile, if I had to write a neural network trainer from the ground up (even a very slow CPU one), I have no idea how I'd do it.
Like, I get it! A neural network is a bunch of vector<float>! You change the weights in a way that is similar to finding the low point of a slope! Yes, every damn ML video uses the same metaphors! My question is, how do I actually change the values of the goddamn floats?!
I dunno. Maybe I need to watch the videos again and something will click.
EDIT: Okay, so the last video in that series is way closer to what I was looking for.
Wait, so a burrito is just a monoid in the category of endofunctors?
Trying to understand how a complex mechanism works is hard, but it’s harder if you don’t know why the mechanism exists in the first place.
It would be madness to start studying how an airplane engine works without knowing it is used to impulse a flying machine.
The experience of starting with something like Lucene at v8.0 is very different from someone who started when it was simpler and probably has both knowledge of and need for any new complications.
One of the clearest reasons he could save the aircraft, is that he spent some time in France, meeting w/ the designers of the different subsystems, and asked (and was answered clearly) tons of 'why' questions.
Yeah yeah 'how' is interesting but in the end, the 'why' is far more important, but also rememberable, and it helps when the thing is broken or half broken and you have to operate it. And I mean the original 'why', not the post-hoc rationalization! 'oh yeah the special "attack-beak" on each wing is there to give more portance during the landing phase, now that it is in "secured mode" (blocked) I will miss % portance during my approach I need to adjust'. And it is secured in case of hydraulic failure or WTF to avoid triggering spuriously during high altitude flight, etc.
I was lucky some time ago to have him comment on a twitter thread about automation and human-aircraft interactions, when I talked about 'why's: https://twitter.com/RichardDeCrep/status/1358560210927771649
Record the whys, that's what jira, code comments, design and justification documents are for! Forget the myriad uml, merise, whatever young people use these days, give me 'why's !
I highly recommend that book and anything from de Crespigny.
Basically, you start with a problem, than the teacher "helps" to come up with a solution, (by hints / guides), which casually ends up at the solution implemented. I think it's one of the reasons people love to reinvent the wheel. When they invent something themselves they truly know it inside out. You can somewhat do it yourself, if say, you want to learn a new library, by first trying to implement the problem yourself, then take hints from the library and finally use the library.
However, I find it rather unappreciated among both teachers and textbook writers. What is usually done is the result is presented on a silver platter to regurgitate and reproduce, and important details are glossed over in favour of 'simplicity', creating a (dangerous) knowledge gap.
He said (I'm paraphrasing) "when you get to really learning the Physics, it's not an incremental logically consistent picture rooted in mathematics like in the textbooks. It's mostly a bunch of little tricks that you learn when to apply, and sometimes you get somewhere."
He wasn't making a pedagogical point, but I wonder if being compelled by the "learn by invention" style is in some way detrimental to learning how to solve hard novel problems.
Perhaps quantization or the curvature of space would be better examples as they require prior knowledge of experimental data (assuming we ignore proposed philosophical arguments that stray a bit too far from physics imho.)
Done properly, it's an amazingly powerful way of explaining things.
We started with a general question of "What is the simplest sentence you can think of?", and then moved to "How could you represent that symbolically? Generically?". With the professor's guidance, the solutions and systems of representation evolved over the course of the quarter to become more rich and complex, and just so happened to trace the development of syntactic theory from roughly the 50s to the 70s. Then you took Syntax 2 tracing roughly the 70s to the 90s, and by the end of that time, you were ready to look at modern problems.
My favorite articles are where they only explain the "why" and largely leave the "how" as an exercise for the reader!
I suspect this largely stems from too many cases of not asking "Why do we X?" but rather "Why do we X instead of silver bullet/fad of the week Y that will fix all our problems?" Many of those technical leads have spent years fending off an onslaught of "obviously better" tools/processes/etc... that even if they _were_ actually an improvement would have grown to consume all available time in switching costs alone.
I believe this is the main reason so many people struggle learning git, to use it effectively you need to understand the underlying data model, but instead people treat and teach it as a sequence of black-box commands. Once treading out of the happy-flow without understanding what, this sequence will not help you.
Fred Brooks famous quote also comes to mind: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."
But generally you're right, guides/tutorials for the main use-cases speed up things drastically.
I understand every programmer I talk to loves this auto generated ‘documentation’ (prolly for selfish reasons). For me the tautological definitions, and lack of overview (which resources you need to form basic reporting—my introduction was swagger api for a Platform POS) undermine the description as ‘documentation’. I’m not complaining about what Swagger does, but about the cavalier way other programmers and vendor managers sound all chipper about their (un-)helpful ‘documentation’.
Looking at you, Nexus Repository Manager.
My categories are Source (Reference), Procedures (~Tutorials), Examples (How-tos) and Meta (Tribal Knowledge, history, etc).
In the context of software teams (and others I'm sure) my anecdotal insight is that without a balance of these kinds of information, certain team functions break down:
- No Source/Reference, no shared deep understanding
- No Procedures, difficulty scaling processes (and difficulty onboarding new team members)
- No examples, harder to develop new skills / level up existing skills
- No meta, no context or "why", leading to less motivation
I still remember CPAN perldocs as a high water mark for docs. They had specific sections for examples, starting with the summary at the top, and another for proper reference. And more importantly a strong culture of good docs. The examples tended to be close to comprehensive, progressing from simple to complicated problems. Then there would be a rundown of arguments and return values for the key methods.
A pet peeve on a smaller order: bad variable/function naming in beginner examples.
Hypothetical: You're writing a true beginner tutorial introducing the core concept of fooKinetic in your cool new gaming language. Many authors choose variable and function names similar to the concepts they're introducing, which adds unnecessary cognitive load for those who can't yet automatically visually parse the language. Someone who's looked at the code even for a couple of hours completely understands what `fook | fook ~~ fooKin | fook –– Fook{}` means, but to a complete language beginner, it's nonsensical. You lost an opportunity to reinforce your basic syntax, didn't communicate the core concept of the tutorial, and likely turned off people closer to the beginning of their coding journey.
I come across this one the most and suspect it's the most common reason people suddenly stop following an explanation. Whether it's in a book or a Wikipedia article. I guess when the author already knows something, it's a difficult skill to maintain the full perspective of the audience - some things they obviously don't know and are easy to explain, so they nail it, then for others they are difficult to explain and it may not even be clear to the author how they came to understand it in relation to the primary subject - which is when they tend to drop the ball and do some hand waving.
Multidisciplinary subjects probably make it harder still, since there is relevant knowledge that the target audience may or may not know due to their different backgrounds.
I've seen people try to improve things only to be shut down because they view Wikipedia as a reference manual.
To pick a random example, imagine trying to understand matrix multiplication from this:
> In mathematics, particularly in linear algebra, matrix multiplication is a binary operation that produces a matrix from two matrices. For matrix multiplication, the number of columns in the first matrix must be equal to the number of rows in the second matrix. The resulting matrix, known as the matrix product, has the number of rows of the first and the number of columns of the second matrix. The product of matrices A and B is denoted as AB.
Binary operation? Why is it talking about details like column numbers before it even explains what matrix multiplication is for?
It should be more like this:
> Matrices are 2D grid or arrays of numbers that can represent an operation on a vector. For example scaling or rotating it (or both). Two matrices can be multiplies together to form a new matrix that represents a combination of the operations of the input matrices. For example if A is a matrix that doubles the scale of a vector and B is a matrix that rotates it by 90deg, then the product AB will be a single matrix that both rotates and then scales the vector.
> The matrix product is calculated by summing the dot product of corresponding rows and columns of the inputs as shown in this illustration
And then jump straight to the Illustration section which is easily the most understandable part of the article.
But that edit would probably be reverted because some pedant will point out that matrices aren't only used for manipulating geometric vectors or whatever.
But they aren't all like that, wikipedia varies in quality greatly.
Mixin FAQ
Q: What is a mixin?
A: Mixin allows to inject functionality into classes. Mixins first appeared in the Flawors system and were inspired by an ice cream shop offering a basic flavor of ice cream (vanilla, chocolate, etc.) with a choice of optional "mix-in" ingredients like nuts, cookies, candies, etc.
Q: Can I mix-in a ServerSocket into a ColorPicker?
A: Yes, why not.
Q: How will it work?
A: Like ice cream with cookies.
You were saying?
I can confirm it doesn't work. But for me Oreo barely works as a cookie.
In particular, you can see examples of "inconsistent expectations of reader knowledge" and "starting out abstract" ALL THE TIME in stackoverflow. Someone will ask a specific question about a problem they're having but then have their question closed as dupe and referred to another related (or not) question that has somebody's idea of a "canonical" answer. That answer is often highly comprehensive but it is also often a poor fit answer for someone that is just trying to figure something out and is not equipped to handle and apply an abstract generalized solution to their specific problem.
If there's a good, general answer to the question, then it's on the asker to expand their knowledge as they need to in order to understand that general answer.
Sometimes a simple question needs a simple answer and not treatise or "canonical" answer.
The same goes for teachers in general - you can have professors who are very smart, but are poor teachers. It's a completely different skill set... that's why it's so exciting when you find someone who has both!
What usually convinces me that we're reaching into the "I'm just not smart enough" territory is when I listen to multiple explanations from multiple sources and I'm still stuck (although ... I find that on certain subject people are just parroting each other a lot, which makes me often question whether the person doing the explaining actually understands the topic at all).
As an extreme of this, if it takes you 20 years of hard study to grok a topic that normal people absorb in 6 months ... harsh to say, but you don't fall in the "smart" bucket.
If you don't refactor it to clean up your model, it will stay confused.
Once I have some explanation, I try to "refactor" that explanation by understanding the exact meaning of specific words (domain model) of that explanation.
Once I understand exact meanings and relations between all parts of the explanation it starts making much more sense because it moves from specific (made for me) to general (made for every case).
The paragraph following his series of steps then said, "I soon realized that this was not what I wanted, and in fact, it made for a cleaned out disk. No good. So next.."
And yes, it wiped my disk clean too. The light-hearted way in which he wrote this infuriated me. I just wiped clean my computer because of his article. Granted, I should not have blindly followed the article, and it was a good lesson that has prevented me from ever making the same mistake again. But the way he listed the steps in a very procedural, "this should be followed" format; it felt very deceptive, and the result was irreversible.
Sometimes an analogy is actually perfect, in that both the system you’re lecturing about, and a system the reader already understands intuitively, have exactly the same underlying abstract domain model, just perhaps using different jargon between them.
For example, sound waves vs. electromagnetic waves. A wave is a wave, and if you understand what waves do, it generalizes to other kinds of waves.
Authors reach for the Big Weird Analogy because they often believe they may have stumbled upon a perfectly generalizing underlying abstraction such as “waves.” They’re usually wrong, but I don’t blame them for trying; perfectly-generalizing underlying abstractions are so useful that it’s good to be on the lookout for them.
Sometimes an analogy isn’t perfect, but is close to perfect; in such cases, it is usually helpful to share it anyway, even if it has “holes”, because readers can often find that thinking “on the level of the analogy” helps them to realize additional non-obvious properties of the system they’re learning about. (In the author’s event-streaming analogy: realizing that there are such things as dams on rivers, can make you curious as to whether there’s such a thing as flow-control in message queues. Well, there is!)
I followed the instructions exactly, used every trick I had learned and then some but got stuck several days somewhere around page 20 in the documentation on how to compile the module for Apache, something just didn't work but there was always just more thing I could try, and I assumed the fault was mine since I was just a student.
One day I just gave up and mindlessly continued reading.
Around page 100 there was a line something like:
"This is how we used to do it, these days, just download this file, put it on this folder and use it like this: "
Worked immediately.
Now, I knew already back then that one should always read through the instructions before starting, but I usually think that means one chapter at a time, not the whole book :-)
That's the most important one for me. I've always thought it was the difference between a good and bad teacher. If you don't start with concrete examples then the listener has no where to map the abstraction. If you start with a couple of examples the listener will start to abstract by themselves.
Experts forget that they themselves started with examples.
Which is another example of "know your audience". Of course, even with the more advanced person I still have a preference to start with the concrete. I'll just move through it more quickly (easier in person, where you can read your audience, Zoom classes with muted participants have been an awful experience for me).
Someone can write lots of paragraphs on this Kafka/river analogy (just one random example), but that doesn't impart in my head the same neuronal linkage that they have. Instead I am left, like the post author, trying to figure out how far the analogy extends, what the limits are (okay, so messages are like notes-in-bottles dropped in the river... but what are the fish? are there fish?), and so on. I would rather get clear, detailed explanation, and then think through the subject on my own time in a way that allows my brain to build its own relationships with the information. Maybe instead of rivers, my brain begins to understand Kafka as, I don't know, highways.
I can see your point, that if you try to "steal" the analogy (in the Picassian sense of the word), the analogy could become more distracting than helpful. If you take it for what it is and try to focus on the author's or speaker's vision, they probably work much better.
To someone reading in Europe, explaining something by analogy to baseball innings, bases and pitchers reads: "think of it like dipping your youtiao in chashaojiang instead of haoyou"
I don't even mean non-native speakers, but people from the UK/US.
People tend to leave out crucial information all the time and can't focus on what they try to explain. As if they don't read their texts after they've written them.
Somewhere at the end of the API ref, after a list of deprecations, they mentioned the flush function.
Wouldn't have expected such important info buried that deep.
For example, documentation targeted at our customer support assumes a basic familiarity with the monitoring systems and the structure of the customer facing services. However, documentation for the support cannot build on concepts like the network architecture, or shell access to servers.
On the other hand, documentation for operations engineers doesn't have to slow down the reader with information about the network architecture, as that's assumed to be known.
And being somewhat consistent with these documentation personas simplifies the onboarding of new employees, because there is a known knowledge base you need to access the documentation effectively.
The description restates this as "make the design reflect the style of the explanation", which I think is better, since it goes both ways.
I can't stand cutesy writing on technical topics, but I've nothing against cutesy drawings, so I can't agree with the title. But on the other hand, I've been disappointed a few times by "friendly style" writing hiding in dry visuals, so I guess I agree about wanting consistency.
Or an arbitrary unsplash landscape photo with a tenuously related caption. Why do people do this? Is it to stretch the content, or just a fad? Surely there's a different way to break up long text than adding visual noise.
I love this.
As I get more skilled with a thing I think I can have more confidence that I'm doing it well and according to best practices up front but that my highest level of confidence comes from employing the thing in practice and observing the results.
That could be deploying code to prod with monitoring, having another dev review my code to see if it's readable, having users interact with my system while I observe, or in this case seeing if someone can read my explanations and understand the ideas I'm trying to communicate.
Information => confusion => more research => reformulate with your own words => finally reached a good grasp of the topic
That’s a very common way to learn about something and doesn’t have a lot to do with the quality of the initial information. You have to go through the process of being confused, then build your mental model of the thing.
That's why one of the suggested fixes is simply to place a warning that the following is not to be read as reliable gospel.
"The traditional way to solve this problem ..."
"Other tutorials suggest something like the following ..."
It's just sadistic to give an example that doesn't work and then I waste time looking for a syntax error or typo that doesn't exist.
> pattern 12: explaining the “wrong” way to do something without saying it’s wrong
I encounter Pattern 12 in three different ways:
1. Google for solution problem. Find tutorial. See solution that, for all intents and purposes, looks correct. Adapt to my problem. Doesn't work. Return to to tutorial. "Surprise! How much time did you lose!?!?".
2. Following tutorial. See solution. Something seems off. Wrack my brain trying to reconcile the solution given that it seems wrong. Scroll down. "Surprise! That was the incorrect solution."
3. Following tutorial. See solution. Seems legit, integrate solution into my learning. "Surprise. Now your brain is broke!"
There is no version of this pattern that I've encountered where I didn't both treat the author as an unreliable narrator going forward and also assume they were a bit of an ass.
You can't learn if you no longer trust your guide.
Each acronym opens up a world full of new questions.
If one finds too many unknown acronyms flying around and giving headache, it's probably a sign they should step back and sort out fundamentals in their head first?
I think it's an attempt to make the text 'feel' chipper, optimistic, and newbie-friendly.
Julia writes some really good stuff, but that particular quirk in her writing has annoyed me for a long time.
pattern 2: having inconsistent expectations of the reader’s knowledge
pattern 3: strained analogies
pattern 4: pretty pictures on confusing explanations
pattern 5: unrealistic examples
pattern 6: jargon that doesn’t mean anything
pattern 7: missing key information
pattern 8: introducing too many concepts at a time
pattern 9: starting out abstract
pattern 10: unsupported statements
pattern 11: no examples
pattern 12: explaining the “wrong” way to do something without saying it’s wrong
>pattern 2: having inconsistent expectations of the reader’s knowledge
>pattern 3: strained analogies
>pattern 4: pretty pictures on confusing explanations...
edit: I understand you're trying to help, but... Your post simply listing the 'titles' of each of the categories is ironically itself an example of exactly the problem the blog-post is discussing: your bare list implies that these are all known rhetorical devices (assuming knowledge) whereas the blogger is attempting to articulate the reasons why these categories are confusing for the reader/learner.
In other words, the value of the blog-post is in the detail, not in some list that can be summarized like this as a tl;dr.
I thought it was a pretty self-evident summary. The article is great too and goes in more detail, but i have trouble imagining anyone saw that summary post, and was like "pattern 11: no examples" - i have no idea what that could possibly mean
Having read the article I found that list painted a clear picture and summed up the patterns nicely.
If one reads that and wants more, read the article.
(Not authors)Pattern 13: Using excessive prose where less will do
That's just a mix of #1 and #2. "Excessive" prose is usually people trying to provide nuance through language with the assumptions others will be familiar enough with that type of language for it to provide benefit. Different words have slightly different connotations which can help if people understand those differences.
Fundamentally, it's the same problem as using acronyms that people aren't comfortable with to immediately parse so they don't cause extra mental load.
The alternative is to make everything really simple, but the lost nuance can affect communication negatively as well, as Randal Munroe's Thousand Word Challenge showed.
“I have only made this letter longer because I have not had the time to make it shorter.” — Blaise Pascal.
> (Not authors)Pattern 13: Using excessive prose where less will do
Ok I guess we simply have to assume that people know the underlying explanations for why assumed knowledge is a bad pattern.
So while I disagree a lot with your statement my experience told me that actually there’s a lot of truth to what you are saying.