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.
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.
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.
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).
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.
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.
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"
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.
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.
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.
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.
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.
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.
"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.
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'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 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 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.
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.
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.
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.
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.
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.
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 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.
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?
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.
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.
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'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.
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:
That was a really interesting article. I've been praised for my knowledge but was always a slacker in school. It seems that praising effort has a great impact on motivation.
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.
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 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.
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?
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 ;)
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.
96 comments
[ 3.6 ms ] story [ 166 ms ] threadIt works against the biggest problem we all have miscommunication.
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.
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.
The office is not the place for chest thumping dominance displays and contests of will.
Great advice.
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.
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.
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"
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.
This sounds interesting. Could you talk more about it?
A longer example is at
http://sohcahtoa.org.uk/pages/maths_algebra-revision-card-so...
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.
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.
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.
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.
This! I believe this sums up the way people should behave when in a class.
And er, Donald Rumsfeld, when talking about unknown unknowns.
"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.
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.
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.
This has nothing to do with scapegoats, but my understanding can be, of course, completely off.
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 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.
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.
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 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.
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.
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.
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.
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.
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:
http://www.npr.org/blogs/health/2012/11/12/164793058/struggl...
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.
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.
And meanwhile I've learned a ton.
http://en.wikipedia.org/wiki/Rubber_duck_debugging