That invisible pressure to be a walking encyclopedia
Has it ever happened to you? You're in a meeting, someone drops a technical term that sounds like advanced Latin, and you just nod your head as if you were the creator of the technology itself? It happened to me for many, many years. I remember the feeling perfectly: slightly sweaty palms, a forced smile, and that inner voice screaming: "Please, let nobody ask me for details about that right now!". As developers, we often carry an invisible backpack full of expectations—both our own and others'—that force us to believe that 'seniority' consists of having all the answers instantly.
My experience living the 'expert' lie
During a good stretch of my career, especially when I started leading projects, I felt that if I admitted I didn't know what a specific database optimization technique was or exactly how a new React hook that came out two days ago worked, my credibility would go down the drain. I spent meetings doing mental gymnastics, connecting dots I didn't fully understand to give answers that sounded professional but were, deep down, quite empty.
I remember an especially painful anecdote with a major client. They asked me about the feasibility of implementing a microfrontends architecture for a project that didn't even need it. Instead of saying "look, I don't have direct experience with that approach in this context, let me research the pros and cons," I started rambling about modularity and context isolation. The result? We ended up wasting two weeks analyzing something that made no sense, simply because I didn't want to look 'ignorant' at that moment. It was a turning point. I felt terrible, not for not knowing, but for not being honest.
Why I think it's important to break this cycle
Now, don't get me wrong. I'm not saying we should fold our arms and stop studying. But I've learned that software development is such an absurdly vast field that it's physically impossible to stay up to date with everything. What really makes us valuable isn't memorizing the documentation for every library, but our ability to reason, to solve problems, and, above all, to learn fast.
When you pretend you know everything, you're building a wall between yourself and reality. That wall prevents you from learning from others (even from people more junior than you who might be much fresher on certain topics) and, even worse, it creates a toxic team culture where nobody dares to ask questions. If the most experienced developer on the team never has doubts, those who are just starting out will feel panic when they make a mistake or don't understand something. And that, my friends, is the perfect breeding ground for catastrophic bugs and technical debt that's impossible to pay off.
What I've learned by saying "I don't know"
The first time I dropped a "Hey, I actually have no idea about that, can someone explain it to me briefly?" in a technical meeting, I waited for a lightning bolt to strike from the sky. But nothing happened. Quite the opposite. A colleague, who by the way was quite a bit younger than me, lit up and explained it to me with amazing clarity. In five minutes, I learned more than if I had spent three hours faking it and then another four secretly searching on Google.
Since I accepted my ignorance on certain topics, I've noticed three massive changes:
1. Team trust has gone up: Now my colleagues know that when I say something is certain, I really mean it, because they've also seen me doubt. Honesty generates real security, not a fake one.
2. Meetings are shorter and more productive: We no longer waste time on metaphysical ramblings to save anyone's ego. If we don't know something, it's noted down, researched, and we move on to the next thing.
3. My stress has dropped to healthy levels: I no longer go into meetings with the fear of being 'found out.' Going in exposed is strangely liberating.
How to do it without looking incompetent?
I know what you're thinking: "Roberto, if I say I don't know anything to everything, they're going to fire me." And you're right. The trick isn't to be ignorant, but to be an honest professional. There's a way to say you don't know something that projects confidence instead of doubt.
For example, instead of a simple "I don't know," I usually use variations like:
"I haven't worked with that specific tool yet, but based on what I know about [X], I imagine it works similarly. Can anyone confirm that?"
Or my favorite: "That's an interesting topic and I don't want to give you a half-baked answer. Let me run a quick proof of concept this afternoon and I'll confirm if it's viable."
Here, you're not admitting defeat; you're demonstrating that you have a work methodology and that you prioritize accuracy over response speed. At the end of the day, your client or your CTO doesn't care if you knew the answer at second 1 or minute 60; what they want is for the solution to be correct.
Final thoughts
In the end, maturity in web development has much more to do with humility than with code. I've discovered that the people I admire most in this industry are precisely the ones who ask the most questions. They aren't afraid of looking foolish because they know the only way to stop being so is, precisely, by asking.
So, if you find yourself in that tense situation in your next meeting, I encourage you to try dropping the dead weight. Say you don't know. You'll see how, suddenly, the air in the room becomes much lighter and the learning really starts to flow. Being senior isn't about knowing everything; it's about knowing what to do when you don't know something. And believe me, it's much more fun to live this way.