Answering "I don't know" (hereby referred to as IDK) is not an indication of ignorance. On the contrary, it may indicate that you're not willing to make wrong assumptions or provide inaccurate information.
I think we've been educated in believing that whatever question we've been asked, we must answer. This is probably true in a traditional school environment, where students are expected to show successful memorization of notions. In those cases "I don't know" means "I wasn't listening to the lesson" or "I didn't study".
There are other contexts though, where IDK not only is the most accurate answer, but it's probably the more useful.
Imagine you're having a surgery operation, but you can hear what surgeons say. One is a doctor fresh from university, at his first operation. He/she will perform the operation. The expert surgeon asks a question before the rookie can proceed. There's probably 'the right answer', and a plethora of sub-optimal others. And perhaps a few answers that incorrectly give the impression that the doctor knows what he/she is doing. If the rookie is unsure, what would you like to hear?
Different scenario: captain and second pilot on a Boeing 737. There is an emergency: they don't get readings about air speed and altitude. The captain asks... Well, you get the point.
Other cases, surely less time critical, can benefit from IDK. Engineering, and software engineering in particular are the contexts I wanted to talk about.
IDK means you're not satisfied by your current knowledge, you don't want to make any assumptions that may reveal to be inaccurate, but most importantly you're communicating it clearly.
IDK is not the end of a technical conversation: it's the beginning.
If you work in a friendly and trusting environment, IDK means "I need to consider additional data/details", " We should ask an expert", "We should not make any assumptions here until we've verified this and that".
This brings the technical analysis to a different level.
Many believe bugs in the code are dangerous. Surely they are, but not as much as bad assumptions.
A collateral effect of embracing, accepting or even encouraging the IDK approach is that people won't feel the pressure to answer as quickly as possible with the best approximation at hand. People will talk more, read more, and ultimately provide better answers.
Considering my University years, it's been more than two decades of technical conversations, and I've learned to distinguish between people pretending to know and those who end up teaching you something. The latter, which contribute to your knowledge, and at the same time improve theirs, have been the ones with the IDK attitude. "I don't know. Let's understand/discover/explain this."
In the era of Twitter and Skype, we should remember that there's a moment for quick, immediate interaction, and a moment where communication, in particular technical, requires time in order to deliver value.
Try this: the next time you're tempted to provide a quick but perhaps inaccurate answer, embrace the IDK spirit. Say IDK, ask questions, talk to people, read. Then look at the outcome: isn't it better, more precise, rich, useful, than the very first thing you had in mind? What else have you learned in the process? Did it take so much time?
Of course this is not always true, and I'm sure the reader can identify cases where a good enough answer provided quickly is the best thing.
What I wanted to say, because I genuinely believe it, is that we need to value good, accurate answers/conversations against approximate, superficial ones.
I think we've been educated in believing that whatever question we've been asked, we must answer. This is probably true in a traditional school environment, where students are expected to show successful memorization of notions. In those cases "I don't know" means "I wasn't listening to the lesson" or "I didn't study".
There are other contexts though, where IDK not only is the most accurate answer, but it's probably the more useful.
Imagine you're having a surgery operation, but you can hear what surgeons say. One is a doctor fresh from university, at his first operation. He/she will perform the operation. The expert surgeon asks a question before the rookie can proceed. There's probably 'the right answer', and a plethora of sub-optimal others. And perhaps a few answers that incorrectly give the impression that the doctor knows what he/she is doing. If the rookie is unsure, what would you like to hear?
Different scenario: captain and second pilot on a Boeing 737. There is an emergency: they don't get readings about air speed and altitude. The captain asks... Well, you get the point.
Other cases, surely less time critical, can benefit from IDK. Engineering, and software engineering in particular are the contexts I wanted to talk about.
IDK means you're not satisfied by your current knowledge, you don't want to make any assumptions that may reveal to be inaccurate, but most importantly you're communicating it clearly.
IDK is not the end of a technical conversation: it's the beginning.
If you work in a friendly and trusting environment, IDK means "I need to consider additional data/details", " We should ask an expert", "We should not make any assumptions here until we've verified this and that".
This brings the technical analysis to a different level.
Many believe bugs in the code are dangerous. Surely they are, but not as much as bad assumptions.
A collateral effect of embracing, accepting or even encouraging the IDK approach is that people won't feel the pressure to answer as quickly as possible with the best approximation at hand. People will talk more, read more, and ultimately provide better answers.
Considering my University years, it's been more than two decades of technical conversations, and I've learned to distinguish between people pretending to know and those who end up teaching you something. The latter, which contribute to your knowledge, and at the same time improve theirs, have been the ones with the IDK attitude. "I don't know. Let's understand/discover/explain this."
In the era of Twitter and Skype, we should remember that there's a moment for quick, immediate interaction, and a moment where communication, in particular technical, requires time in order to deliver value.
Try this: the next time you're tempted to provide a quick but perhaps inaccurate answer, embrace the IDK spirit. Say IDK, ask questions, talk to people, read. Then look at the outcome: isn't it better, more precise, rich, useful, than the very first thing you had in mind? What else have you learned in the process? Did it take so much time?
Of course this is not always true, and I'm sure the reader can identify cases where a good enough answer provided quickly is the best thing.
What I wanted to say, because I genuinely believe it, is that we need to value good, accurate answers/conversations against approximate, superficial ones.