It's okay to not know the answer to everything, that's an impossible task. Regardless of the subject or discipline the world is nebulous and all we can do is try our best. We now also live in a world of generative models being confidently incorrect. You don't want to be a person who adds to the noise. It's okay to say "I don't know". The best part of this career and life in general is the journey of learning.

The motivation to lie and pretend to know the answer to everything is clear; it feels better to be 'in the know' than it is to admit you're not. In a social situation it feels like the better option. But like all lies, it will unravel. It's just a matter of time. For example if a generative model lies or hallucinates the proof is in the pudding that is your application which won't run. It's just a mindless capitalist drone having to spit out slop in order to keep shareholder value high. Remember when Google first unveiled its AI search feature?

However, we know what we're dealing with when it comes to a generative model. We have our critical thinking cap on trying to decipher how accurate the information is. When it's a person who lies it's different. It's frustrating.

One of the best parts of this career and jobs within it is the understanding we build over time. Nobody comes into Software Development understanding everything. As I said previously, it's a nebulous task. Being frank and honest when you don't understand a task, solution, or likewise is best for everyone. Hearing a developer say "I don't know" is a great thing for two reasons. Firstly, if they're saying that they "don't know" and you do, you get to reinforce your understanding of the problem space walking through your accumulated knowledge. It's like a soft victory lap (and dopamine boost). Secondly, you get to support your coworker in their growth. Walking through your accumulated knowledge to solve the problem at hand while explaining it diligently to them boosts their understanding too.

Lately I've found this to be an extremely useful tool when I work with a more junior Engineer. I don't just provide the answer to the problem but I walk through the process of getting to the answer.

"Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime."

Which generally results in a mix of asking probing questions and looking through documentation. It reinforces my understanding of the problem and I'm helping them find the tools to accelerate their own learning. I try to remain fairly neutral in a situation like this, providing insight when required but not pushing towards the exact answer. "What does the documentation say about X?", "What if we got into a situation where Y happens? Would this still work?", "I think we're going to want to use Z".

In my latest role I've returned to the web, where previously I've been working in the react-native world for quite an extended period of time. So some random bits of my knowledge are a bit shaky. For example which semantic HTML element to use is a good example. I don't have that consciously memorised however I am aware of my shortcomings so I always make sure to double check what I plan to use. As I've walked through helping another Engineer it's helped reinforce my knowledge of semantic HTML. Quite often I'll end up saying something like "We're currently using a div to do X. Is there possibly a more apt piece of semantic HTML we could be using instead?". Honestly I think you also humanise yourself in that dynamic. To someone more junior than yourself you can come across as this all-knowing knowledge bank. However you're just as fallible as they are, you've just learnt how to get to the best answer you can.

Sometimes that's by saying "I don't know which semantic HTML element to use".

Pretending to know the answer when you don't is exhausting. It's also not what any rational person should expect of you or anyone else. With the situation I described above I could just lie and confidently say use X HTML element. Even though I don't know if it is correct. There may also be limited or no repercussions for myself in that situation. But I'm cheating them and more importantly myself. I'd be stifling my own knowledge and, for what gain?

I find it endlessly frustrating to be working alongside a peer who insists to know everything. Especially when the documentation disagrees with them, constantly.

Saying "I don't know" is a green flag.

Let's work together and find the answer as a team.