This content originally appeared on Level Up Coding - Medium and was authored by Marcin Kwiatkowski
For several years, I’ve been working remotely, and one of the most annoying things in my work are certain types of meetings. Imagine a situation where a Product Owner/Engineering Manager/anyone else who makes decisions in your project organizes a meeting. There’s no agenda; you can only guess from the meeting name, which usually looks like “something sync”. You can’t deduce anything from it.
Of course, you could try to ask about the agenda beforehand, but today I want to focus on such a hopeless case. There’s a meeting, nobody except the organizer knows why this meeting is happening, and the entire development team is there. The meeting is scheduled for 30 minutes.
At the beginning, there’s small talk, of course. I’m not joking here — small talk is important — if there’s no small talk, it means the atmosphere in the team and at the meeting isn’t good.
The 100-Point Question
Then the organizer starts talking about something, usually gives an introduction, and then fires away with questions like:
- I came up with feature FOO, how much time do you need for this?
- Functionality BAR is slow, what can you do to improve it?
- Why might users not notice the value of this feature? How can we change that?
- If we had to cut one thing from the roadmap, what would it be and why
- We need to show this functionality in today’s demo, but it’s not in production yet. Can we quickly finish and show it?
These are questions that aren’t easy to answer, even if you ask questions to clarify the problem.
Answering Under Time Pressure
The problem arises when the questioner expects an immediate answer. I’ve often seen people (or myself) trying to answer such questions under pressure in the shortest possible time.
You can answer intuitively or based on your experience. Then the boss is happy, and the train (project) keeps moving forward.
But what first comes to mind isn’t always the best. You can’t always solve a problem in fifteen minutes. Sometimes you need time to investigate the matter.
Have you ever said something under pressure and later regretted it? I have, and it’s a terrible feeling.
I’ve worked with many engineers, and many of them, especially the ambitious ones, don’t want to admit they don’t know something or don’t want to be blockers and slow things down. Sometimes they’re afraid to speak up for some reason, or in other cases, they don’t want to look bad in front of others.
What If We Gave Ourselves More Time?
Instead of saying whatever comes to mind, simply say “I don’t know”. You can explain why, but just “I don’t know” should be enough in an organization that isn’t broken.
Because you know what? It’s obvious that sometimes you need more time to answer a question. None of us knows everything, and projects are becoming more demanding, and we’re increasingly using new technologies, even ones that didn’t exist a few years ago.
Besides, meetings without agendas, ad hoc meetings are a nightmare. There isn’t even time to prepare because you don’t know what for. When we say “I don’t know”, the questioner might be unhappy, but if you’re a specialist and still don’t know, you need to stand firm until the questioner understands.
A wise boss will understand.
They’ll ask what’s needed to be able to answer the question. They’ll listen to your objections, ask about challenges, start a dialogue.
You’re Not Alone
Remember, even if you don’t know something, your teammate might know and can help you. You work as a team, and each of us should support others. Be a team.
If you’re afraid to say “I don’t know” because you think you’ll delay the project, I’ll tell you that’s total nonsense. Saying something thoughtlessly is worse than saying “I don’t know” and can lead to doing something stupid as a team.
And usually, when we do stupid things mindlessly, we waste more time than if we had said “I don’t know” and taken time for research.
“I Don’t Know” Prevents Mindless Action
When you say “I don’t know”, there’s a chance you’ll have more time to dive into the topic to investigate and find an answer. You’ll say “no” to mindless action, to later say “yes” to work that will bring real value to your project.
Space will appear for doing things that are needed and well-thought-out. Space for discussion will appear.
Collaboration will appear.
A World of Not-Knowing is Better Than a World of Ignorance
Someone who has a ready answer for everything is ignorant. I’m afraid of such people. I’ve seen how such “wise men” destroyed projects with thoughtless decisions. Do you want to be another wise man, or a conscious engineer who thinks about how to really do valuable things and is a long-term partner for business?
If so, then simply don’t be afraid to say “I don’t know” and give yourself time to think. Talk about your objections and doubts. Also try to propose some action, like needing a few days for research and coming back with an answer afterward.
Conclusion
Thanks to “I don’t know”, you’ll have more time to understand the problem and influence your project to be better in the long term.
Not knowing is human. Be curious and you’ll learn.
Of course, sometimes it’s worth trusting your intuition and experience.
But remember that “I don’t know” is an answer you shouldn’t be ashamed of.
If you liked this article, share it with a colleague and follow me to see more like it.
How Saying ‘I Don’t Know’ Can Make You a Better Software Engineer was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Marcin Kwiatkowski
Marcin Kwiatkowski | Sciencx (2025-01-07T18:35:20+00:00) How Saying ‘I Don’t Know’ Can Make You a Better Software Engineer. Retrieved from https://www.scien.cx/2025/01/07/how-saying-i-dont-know-can-make-you-a-better-software-engineer/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.