I first noticed this effect in college, when the prof would be talking about something that didn't make sense to me. If I remained silent, he'd never explain (of course) and I'd remain ignorant. However, whenever I asked him, everyone would start furiously writing down his explanation in their notes.
So I got into the habit of saying "I don't understand". Inevitably, there would be quite a number of other people who also didn't understand, but were afraid to ask, so I'd just ask first. That stuck with me throughout my career and served me well. If you don't understand, ask.
Also, contrary to common sentiment, there is no minimum competency level that grants you the privilege of saying "I don't understand." Ignorance is not a monopoly of the elite.
Did you usually just say "I don't understand"... or was it more like "I get how a works with b when c occurs. But you lost me when you were talking about how it happens over z, I don't get the distinction, could you go into that?"
It's not about plain ignorance, but conscious incompetence. That can be a great deal of work to attain in a given domain, getting to that "I know what I don't know" place so you can actually make pointed questions. You have to have a fairly good map of the territory already to begin filling in the gaps.
Many of those people furiously writing probably didn't even know where to begin to ask... just write the stuff down now, understand later. Asking "I don't understand" doesn't make you look stupid, it's the follow-up "what don't you understand?", and then showing you can't even get into a proper discussion about your ignorance.
I'm a teacher and I like students who ask me to re-explain or re-present a step in an argument. In fact, I use techniques designed to find out how much my students know and 'how they know it'. I teach fairly basic Maths, and different students learn the basics in different ways.
I'd like a student who could articulate which step in a complex argument is the issue even more! I usually ask follow up questions to find out where the issue is without putting the questioner on the spot.
> In fact, I use techniques designed to find out how much my students know and 'how they know it'. I teach fairly basic Maths, and different students learn the basics in different ways.
This sounds interesting. Could you talk more about it?
OK, take a question like 'which is bigger, one fifth or one third or one half'. Some people just know the bigger number on the bottom of the fraction means that is smaller, for unit fractions. Other people have to visualise the fractions as a pizza and compare the slices. A few people have to take an actual value like 30 and work out the values of each of the fractions. They all solve the problem, but the 'way they know' is different.
Yeah, I don't think you should ever say, "I don't understand", it comes off as lazy, you're making the other person do all the work. Give them a little more to go on, tell them what you've understood so far and what you need clarification on.
Right, I really dislike when people say generally "I don't get it". I have no idea where I need to re-explain something, and I end up starting over from the beginning a different way. Sometimes, after a couple rounds of this, I just have to stop and say, "I'm not sure what you're confused about, why don't you help me a little in clarifying what you need info on?". I quickly lose patience (and respect) for someone who doesn't take an active role in understanding. Conversely I have no problem going over something N times with someone if they can help me map out their (not)understanding of something, because then progress can be made.
Even if you aren't sure what you don't understand, narrowing your questions or explaining your reasoning on things you do understand (or think you understand, sometimes we all are wrong on some key assumption that changes everything) can help your tutor fill in the bits that help explanation. Further, this sort of exercise is an example of metacognition, which teaching theory suggests is a very vital part of directed learning.
This is the first thing I look for in candidates. Ability to ask questions. There is no such thing as a dumb question, there is no such thing as asking too much (almost). The most confident and able developers I worked with were those who felt free to say "I lost you at your first sentence".
I think that it is the explainer's responsibility to explain it in a way that will be 1) understood by others 2) not intimidating, so if it's not understood, people will still feel they can ask.
Crafting an explanation in a way that others can follow is one of the most powerful and useful skills a developer or manager can strive to achieve, not just the ability to understand others who don't have this skill.
E.g. if I hear "I don't understand" I don't think "ok, this person is not getting it", but rather "my explanation should be better"
I saw that as well. One student asked what seemed like silly questions, but later he got invited to apply for PhD and I did not.
On the other side of the equation, I had one amazing EE professor who would write something on the board, and before he turned around would say to the class "You don't understand this", erase it, and take a better approach. He was able to tell when the class didn't get his explanation and would improve it real-time.
Maybe the questions were exactly as silly as they seemed. I noticed this too, people (e.g. students) asking stupid stuff simply to force others to interact with them. It's a silly manipulation but it works well, too. It's a good maneuver to feign interest and enthusiasm, and to make superiors remember your name.
Another aspect for which you might attribute this to more senior devs is in their ability to know how deeply they need to understand something in order to implement it.
A lot of times when I'm building something in a problem space I don't know very well, I like to keep guidelines loose, because I know that I'll be taking some leaps in development, and I know I'll be working in areas where I'm not fully competent.
For those reasons, it's hard for me to envision the project start to finish -- I'll know the general steps, but each implementation detail is a variably sized black hole that I can't peer into until I get deeper into it.
For things I'm more familiar with, I'm able to ask better questions, and more easily identify when something isn't going to work, or at least not work as expected. To the lay person, I appear dumber on the things I know better because I'm able to ask more specific questions, so I ask more of them until I'm 100% confident that I do understand, and generally, at that point I can just do what I'm supposed to. Where I'm less competent, I ask fewer questions up front, but then way more as I'm doing to make sure that what I've ended up with is going to meet expectations.
Yes, absolutely. Asking questions is how you turn a lecture from a poor substitute for just reading about the subject into something far better.
From the other side I find it incredibly useful to get questions while speaking and I wish I was better at encouraging them. When writing a talk you have to write for some imaginary audience who won't ever quite match your actual one. But if you can get them to start asking questions then immediately you have the opportunity to tailor what you're doing for the audience in front of you. It's a very satisfying feeling :)
Any tips from anyone here for making people feel more inclined to ask questions? Often the ones who could most benefit (and create the most benefit for others) are the the ones least likely to have the confidence to do it.
> Any tips from anyone here for making people feel more inclined to ask questions?
Become more of an asshole.
There are probably more eloquent ways of phrasing that, but I want something that will stick in your mind when you're actually on the spot, and that works.
The idea here is to stop caring quite so much about what others want and what others will think of you.
If you constantly worry that you're interrupting the flow and that you'll be bogging everyone else down, don't. Embrace the asshole side of you to ask the question and damn the consequences.
If you worry that the people around you will think you're dense, fuck them. They don't have the first clue about you, and you're in that class for you, not for them.
Yes, when I'm talking about something to a group of people, I like questions, they let me know where I need to be more in depth and where I an keep glossing. However, a good answer from a presenter is in fact "I will cover that in a bit (a few slides, or whatever)", and part of being a good questioner is temporarily accepting "I don't understand this one thing" and working around it. Sometimes it turns out that a bit of understanding falls out of understanding other, surrounding bits of knowledge first. Being a good questioner/learning isn't just about understanding everything instantly or when you first notice you don't understand, but rather noting the places where you need clarification, and paying attention for things that fill in that knowledge.
Making a clear statement such as "I don't understand" also is a great signal to your coworkers. It kills confusion and builds trust: I know that if you don't understand, you will let me know. That is much better than having someone who I have to poke to admit that they don't understand something.
Another personal favorite is stating unequivocally, loud and clear that "This was my mistake". It is tempting to just fix the mistake but even if you have fixed it, if there isn't clear declared ownership, you probably haven't addressed the root cause.
Doing this keeps you honest to yourself and also removes the awkward air where no one knows who is responsible for this mistake because no one has taken ownership. To pull this off you need an environment that won't punish mistakes by default.
There are absolutely fireable mistakes but if you do this right, the employee should volunteer to be let go because he realizes the gravity of his error.
Why does it matter who is responsible for a mistake?
Because the person who makes the mistake is often in one of the finest positions to suggest ways to prevent the same and similar mistakes not just by him, but by others in the future. In all, that adds great long term value to the organization.
Accepting responsibility does not mean "blame" or "scapegoating". Blame and scapegoating is something done by others in the organization and reflects on a poor culture than someone accepting responsibility.
It does mean seeing a situation objectively. If Mary broke the site and she knows why, it helps no one to keep that a mystery. It helps everyone if the environment lets her come forward and say it was her mistake, this is the fix and this is how we will prevent this category of mistakes in future.
In fact, in order for this to work, you have to go out of your way to make sure that "responsibility" is not used to blame or scapegoat. If it is, people responsible will stop accepting responsibility.
I understand this the following way: when nobody claims "ownership" of a mistake, everybody (ie. in a team) feels guilty about it, even of they had no control over what lead to this mistake. If someone says clearly that it was his mistake, everybody else may stop worrying and either concentrate on something else or help mistaken person avoid such mistakes in the future.
This has nothing to do with scapegoats, but my understanding can be, of course, completely off.
More to the point, people turn off their brains when they hear 'This was my fault'. They stop investigating further once the blame has been assigned.
It's more important to do the classic 'five whys' than to assign blame.
A scenario:
Maybe Joe forgot to do the maintenance task.
Maybe he forgot because he's been working overtime and is tired.
Maybe he's been working overtime because there aren't enough sysadmins.
Maybe there aren't enough sysadmins because hiring good sysadmins is difficult.
If you stop with just 'Joe's fault', you miss the point - time to spend some effort on recruiting new sysadmins. Worse, you might damage Joe's morale or even alienate him through punishment, even though that only makes the root cause worse.
Sure, the way I see that in order for the 5 whys to work, you still need to know that Joe made the immediate mistake. Now, as part of the process, you create ways to prevent that mistake. When doing that preventative analysis, the other whys should pop up and the solution may well be something beyond Joe.
Right my point is that saying 'It's Joe's fault' is wrong. The blame lies beyond him. It's cool to say 'he forgot to xxx' or 'he made a mistake and yyy', but to just categorically call it his fault is wrong.
If the responsibility lies beyond him, then he shouldn't say it was his fault. You only say that if it was indeed your fault or you qualify how much of it was your fault.
At our shop, we drive to specific "causal" or "responsible" event/party so that we know, as best we can, what actually happened. Nothing punitive about it, and every one of my best colleagues have 5 or 6 figure losses that they had a prominent role in causing.
I only care who, what and how for the purpose of minimizing the chance of recurrence or to improve our response when a third-party causes a recurrence.
Because the person who made the mistake is in the best position to understand how and why it happened. Responsibility and blame are entirely different things.
I am but an egg. Very new as a developer, not particularly good.
The smartest programmer in my workspace frequently looks for me when he's trying to solve something hard. There are a dozen people around us, at least, who are better able to _solve_ whatever problem he's working on. But they don't ask as many questions. I ask a lot of questions. Midway through explaining stuff he's solved his problem.
I can see why there seems to be a stigma attached to admitting you don't understand something, especially if you've just started at a new place and you want to make a good impression and reassure them they made the right choice hiring you. I've been guilty too many times of not speaking up when I don't understand something and it comes back to bite you. It makes you look more incompetent being ignorant and not speaking up and then ultimately failing to deliver, than it does to admit you don't understand something thus lowering expectations of the outcome from your work.
To be honest most senior developers are guilty of not creating the right kind of environments for people to comfortably admit they don't understand something and then it brings the whole team down as a result. With exception of where I work now, the senior developers at all other large companies I've worked at made you feel stupid for admitting you didn't understand. There's no weakness in admitting you don't understand, but because of the way companies these days throw words like Agile and lean around, it's no surprise people are afraid to speak up when a company works in the form of 3 week sprints.
While it comes down to the volatile environments managers and senior developers have created over the years, a bad economy doesn't exactly help when it comes to admitting you don't understand something you were hired to do either.
The best new hires we've brought on are the ones that jump in and ask for explanations.
When explaining things to a new hire I already know they don't understand everything, and I expect questions. Those questions help drive the discussion further in a way that hopefully fits in better with their thought process/learning style.
It is much more frustrating trying to explain things to people that just nod and have to be continually questioned to try and find out what they actually understand!
I am glad to hear that. If only more companies would lead by example and understand that just because you hired a Javascript or Python gun does not mean they're going to be familiar or understand with the way your company works, its methodologies or best practices immediately. Adjusting to a new environment takes time, there will be questions. The issue seems to be like I said, a lot of places I've worked at have made you feel stupid for asking questions (at least the senior developers anyway), especially if said company works fast and has adopted a methodology like Agile and SCRUM which can sometimes cause a stressed and tense work environment when the sprint period is coming to an end and things aren't going the way as planned.
I wouldn't exactly say I don't know what I am doing, but even I struggle just like everyone else because I don't know everything and it's better to ask a colleague who might than it is to search Google. Managers need to train their staff to be more sympathetic and patient with new hires especially. Some places (by the sounds of it like yours) have created a comfortable environment where it's easy to ask for help and clarification, this is how it should be everywhere.
Whilst it's important to admit that you don't understand, senior people can use "I don't understand" as a way to ensure that everybody understands.
If you're senior and you say that you don't understand then you're opening the gate for everyone to discuss the issue in more detail; no junior workmates will feel dumb - even the senior guy doesn't understand it!
And chances are that the deeper discussion will unearth something I didn't fuly appreciate, even if I wouldn't have called "I don't understand" for other people's benefit.
That the most experienced devs say this the most might not be just about status games. You need to have a very solid shared background to be able to jump to understanding something after the sort of short verbal explanation "I don't understand" can be replied with.
If I go to an university lecture on advanced math, I won't understand things, and can say so. But it's unlikely the lecturer can say anything in the span of five minutes that will make me understand, since what would actually get me close to understanding the content of that lecture are several semesters worth of studies leading up to it.
The senior devs might be the only people on the room who do have such a solid grasp of their stuff that they can fill in their understanding with just a few minutes of explanation. Junior people don't understand either, but they might need to work over the new thing for hours, not five minutes, to get a proper handle on it, and you can't give an hours-long answer to someone who says they don't understand.
I've been in maths courses where this has occurred, and the lecturer's response is usually to give a brief overview as a refresher, then point them in the right direction to learn those prerequisite skills if they don't have them. I think the same can be applied to programming, but if you don't ask at all, you may never learn where to start.
I've always used the words "I don't know". My mother kept telling me she hated hearing those words. I can imagine that she was pissed that I didn't take a guess, but guess what? I hate guessing! I hate making decisions and jumping to conclusions based on partial knowledge.
Almost every environment I've been in - whether it be high-school or grad-school, a corporate setup, a startup,; I've found that "I don't know"/"I didn't get you" goes a long way. The other person in the picture usually goes out of their way to make me understand what I'm missing.
I credit a large portion of my success in my chosen career to my ability to say 'I don't know, but I can find out' in response to questions outside my expertise.
One expression of this that I hear from newer devs (and clients) sometimes is "Can't we just...?" and what it really means is "I don't understand", but in a more socially safe way. If I address the question as if it were "what am I missing that makes this seemingly simple solution not viable?" it usually addresses the question and spreads better understanding. I also find that if someone is having trouble understanding my design, it is only rarely a lack of understanding on their part, and more often a lack of good design and good communication of that design on my part. "I don't understand" is a cue to try to make your architecture, design, and code more understandable.
I've been dealing with this exact experience the last couple of weeks, after being asked to take ownership of a huge codebase. From what I've noticed though, saying "I don't understand" usually triggers a more detailed explanation of the existing design, leaving out the "why" part unanswered, and ending with me still completely baffled. I've had to resort more often to "Can't we just..." type questions, and while that elicits a more useful answer that makes everything click into place, I'm afraid of looking like an asshole who thinks he knows the answer to everything. Isn't there some compromise between these two styles?
I usually go for something along the lines of, "I'm probably missing something, but it seems to me like it ought to be doing X here instead of Y. Is there a reason it's Y?"
I've been trying to use something closer to ColinDabritz's second wording: "What am I missing that makes ____ unreasonable?" or "I don't understand why ____ wouldn't work". Phrasing it like this hopefully conveys both that I'm aware that there's a gap in my understanding of the problem, not our solution to the problem, but still elicits a response more directed at my particular understanding. It's also easier for me to formulate what I don't understand as "here's what seems obvious, why is the solution different?" than "I don't understand this particular aspect", since I don't know the part of the solution to ask about.
"I don't understand" is to relate to "I don't know", of which something along the lines of this is said:
"He who asks a question may look like a fool once, but he who keeps his question to himself will stay a fool for the rest of his life."
Result-driven teaching in our societies fuels the natural fear of failure and of the look of your peers, when proper teaching should result in driving curiosity through one's own recognition of not knowing something as being a positive thing.
It's interesting how these unknown unknowns relate to Dunning-Kruger effect and also how people with limited knowledge tend to be more sure about themselves. I recall someone wrote an interesting article about those, but can't find the source right now.
Totally agree. In fact, when I was working at my first programming job, I realised I'd reached a milestone in competency when I could confidently say "I don't understand" without fear of ridicule or feeling stupid or worrying about slowing down the rest of the team.
I've asked interviewees very difficult questions for this exact reason. I want them to say "I don't understand" or "I don't know" rather than bullshit me an answer. Of course, after saying "I don't know," I instruct them to elaborate on how they would work out the solution -- co-workers? Google? Experiment?
There's an Israeli saying that encapsulates this effect exactly (if somewhat abrasively): "Whoever asks, is stupid for a moment; whoever doesn't ask, stays stupid forever."
I find that people not only have different views of The World, but also different internal definitions and understandings of basic terminology. This guy has the understanding that some assumption is implied in the implementation of an algorithm. That guy has never assumed that was the case. Both have tremendous amounts of experience in writing software systems (for example.) I've seen this exact scenario cause dozens of minutes of superfluous conversation because neither of them bothered to hear a detail that would allow them to realize there was not a full understanding between them. To address this case, my personal habit has become to listen carefully, consider the very words being spoken, identify those little things that aren't clear, have bred assumptions, or just plain don't make sense, and then interrupt ... even if by the time my brain has done all this the speaker has moved on.
It's leagues better than working under the wrong assumptions for days, weeks, months...
It's so critical to foster a culture where "I don't understand" and (to risk going off on a tangent) "I don't think that's right" is acceptable, even if its an intern to a CEO.
Reminds me of The Checklist Manifesto which cites how OR nurses and doctors who communicated best--they know each others names and nurses can tell doctors "stop"--had fewer surgical errors.
I started saying "I don't understand" years ago. A few very intelligent people have looked at me like I'm an idiot when I've said it. Don't expect it to make you look good in front of everyone.
One thing that irks me is when you're given some sort of spec document and just told by someone senior the equivalent to RTFM; no questions tolerated ... you have to read and understand the document by yourself, and that's it. That's happened a couple of times to me... and its totally unproductive.
I don't disagree with you but there's a fine limit between asking questions and asking to be hand held.
And it also works the other way around: I cannot stand when a member of the team is too afraid/shy/... to say "I don't understand". (I'm not blaming the team mate as much as the work environment. Nevertheless it's still a very real problem).
When I get out of a meeting with coworkers and they said they understood (or implied it by not asking questions or saying "I don't understand") I really need to trust they do, or else major problems lie ahead.
What is wrong with hand holding? If someone never outgrows it, they may meet a lower salary for being inefficient. If someone succeeds without it, it doesn't happen. If someone needs it and doesn't get it, we spend twice as long cleaning up mistakes. In any case, handholding itself is never the problem, and avoiding it just masks more serious problems while regarding communication and relationship building.
The office is not the place for chest thumping dominance displays and contests of will.
My analysis professor used to say, if you state that some part of the proof is trivial then it should be easy to just write it out. And when you have a hard time writing it out or it takes too long, perhaps it's not trivial after all.
There are subfields of programming that generate more than their share of subtle gotchas, so that one should be particularly careful even when doing many routine (aka "trivial") things. E.g., security, or multithreaded stuff. From my single real analysis course way back when, I remember an impression that real analysis was a subfield of math with a similar error-prone character --- particularly easy to conclude something incorrect by stumbling over a technicality (e.g. integrating before taking a limit instead of vice versa), where the technicality is likely to be tricky to keep track of because the cases where the technicality matters are so weird (e.g., carefully constructed horrendously discontinuous functions).
Not all fields of programming or mathematics are as productive of fiddly gotchas: often an experienced specialist can judge rather reliably that a piece of work will be entirely routine, though time-consuming. I can only appeal to my informal anecdotal impressions for this in programming, but in mathematics I have some harder evidence: setting up machine-checkable proofs in HOL Light. The prover won't let me get away with any hand-waving or ambiguity: I really do have to dot every single i and cross every single t. In the end, doing that is routine (though often very tedious and messy --- people talk about spending a week to formalize a page of mathematics), and I am very seldom surprised by a part of a proof that I expected to be tedious instead turning out to require new insight.
Just last week I've practiced "I don't understand" again. Now I don't particularly like jeopardizing my position at work, but looks like that question wasn't met well. A manager running the meeting (plans for next year) frowned upon a person who seems to be not understanding what he was talking before. In retrospect, I might missed some explanations - didn't quite get them at the time he gave them, possibly didn't pay enough attention - but that was the reason for my question!
The matter was important to "get". Hard to say if the annoyance was justified... but the result is this question may also backfire, even if it shouldn't.
I'm managing a project right now, and I've found that frequently if I don't understand something, then saying this is indeed helpful. It felt silly the first few times, as I'm supposed to know the hows and whys as the project manager. But it offers me an opportunity to learn, and a few times has found sections of code that weren't really understood by anybody (perhaps from prior developers or cut/pasted from god knows where).
Background and what social class you came from play a very big role in this too. While an upper class kid may feel perfectly entitled to say 'i don't understand' in any situation, this behavior is often implicitly if not more overtly discouraged for people from lower class backgrounds. When you say 'i don't understand', the unspoken subtext is 'i don't understand: this is important, and my understanding is definitely worth whatever time it takes for you to explain it to me personally, regardless of whether anyone else is having a problem or not'.
Equality among people academically and vocationally needs to be backed up by strong support and activism for greater social and economic equality. Otherwise trivial efforts to promote more participation are a farce, and nothing is ever going to change.
I used to say I'm always right because when I'm not I say it (or I admit I'm not sure). It came out as being arrogant so I stopped using it publicly. But it's true. When I'm not perfectly sure, I never act like so. I'm only comfortable arguing back when I'm totally sure, i.e. can point to the right explanation in a book or something similar. Friends find it a bit annoying.. because whenever they ask a question, I'm rarely comfortable answering yes or no.. it's always, well, it depends ;)
Living in a country where you're learning the language is a good way to get used to saying 'I don't understand'. When I was really bad at the language I just often sat there and hoped someone would translate for me but as my confidence increased I was able to say 'Can you rephrase that for me' or 'I don't get the cultural reference'. Now I love asking questions, as so much extra knowledge comes with it and you can get people to go off on wonderful tangents.
I agree very strongly with the sentiment of the article, and would like to add that I think the flipped side of the "I don't understand" is just as important.
I.e., You're trying to explain something and someone doesn't understand, you should be patient with the person. I don't think it's always (or even greater than 50%) the case, but enough times after finding out what the lynchpin of understanding was there are ways I could have improved my first explanation.
There are multiple levels in which I agree with the above sentiment.
Some of my teachers had these quotations to encourage questions!
1) If you say you dont understand, you may appear to be a fool for a few minutes, if you pretend to understand (while you dont)... you are a fool for life.
2) To learn something knew, you have to set your ego(pretending to know lest you appear ignorant) aside and start humbly with basics.
I would often do this in class (or at work, in meetings) either because I really didn't understand, or because I could tell a bunch of others didn't. But it is fine to phrase it something not being clear, asking if they can try to explain a different way to make it more clear, or trying to rephrase whatever it is myself.
Creating a culture where asking questions and identifying when one doesn't understand something is what we strive for, but there still seems to be a stigmatism when one expresses their confusion.
How do we create an environment where one doesn't feel it's wrong to ask for clarification without being subject to "looking stupid"?
I like to think most people in our field are naturally curious, so make sure your environment doesn't stifle that attitude. Hold group learning sessions for new technologies, code reviews, and so forth. As a senior explicitly seek out advice and explanations from newer colleagues even if you can figure it out on your own. Hopefully they'll end up feeling comfortable doing the same.
I agree with both side of this. Having someone ask me to explain the same thing multiple times per week, and most recently asking where my answer is written down for everyone to see is frustrating (not written down because it is basic knowledge that underpins everything we do, and we all hold a qualification that says we know this stuff, if he wasn't to remember, he can write it down).
Basic workflow issues and understanding of problems that have never been considered by this person lead to everyone else getting irritated. All sorts of things have been tried. Workplace tutorials, performance appraisals, direct conversation, indirect conversation, mentoring, keeping a note book of problems and solutions.
Untrainable, as this person has an unwillingness to acknowledge a need to learn.
Make a personal plea at the beginning of your semester stating that it's okay to say "I don't understand," and that even instructors say that often enough.
Make it clear that struggling is a perfectly normal factor of life -- in fact one could argue that intelligence is a measurement of someone's history of struggling.
One could even go so far that the top 5% of any class are simply people who have 'struggled' the most, or more to the point people who have stumbled (and overcome it) the most.
Here is an excellent article researching teaching methods in Japan:
I hope this isn't the case. I've been sure to speak up when I don't understand since the beginning. Don't people appreciate it when you want to make sure you get it right the first time?
Also, people who never say "I don't understand" will never get explanations of concepts they don't understand. The more you say this phrase, the faster you'll learn.
I speak up and protest when I don't understand. I "fight" back and challenge the logic of code|process|etc when I disagree. I don't do these things out of disrespect or because I think I'm "that smart". I do it because I need to understand and I don't. So I pick at it until I have a complete understanding. (Sometimes this is "Because." and I can accept that)
This also has the nice side effect of bringing a different perspective to an existing problem. It's a habit that has left several managers going "wow, you sure know what's going on, or you found problems that we'd not considered". I just shrug and reply honestly, "I'm just trying to understand."
It's of course also invaluable advice for students of any ages.
Well said, plus this gives the person a chance to think through more of their idea and explain it in more detail. Lot of times developers simply "assume" that other people get it, while that may not be the case.
So I got into the habit of saying "I don't understand". Inevitably, there would be quite a number of other people who also didn't understand, but were afraid to ask, so I'd just ask first. That stuck with me throughout my career and served me well. If you don't understand, ask.
Also, contrary to common sentiment, there is no minimum competency level that grants you the privilege of saying "I don't understand." Ignorance is not a monopoly of the elite.