One of my biggest roles at my new job is mentor, and I've quickly learned a five-word phrase that my peer-students have come to understand and respect: "I don't know that yet."
The team I'm mentoring consists mostly of QA people who are moving into SDET roles, with a healthy side of SDET tooling development. I did a lot of mentoring at Isilon, and I did a lot of SDET tooling at Splunk, but I don't think I did both at the same time so this has been interesting. There are two groups inside this team: one is developing reporting tools using Django and React, the other is developing DevOps tools using Docker and Python.
I know both of these worlds very well, but having been out of both of them for three years, two because Splunk needed me to write a lot of Go and Kubernetes and one because I wanted to learn Rust and systems programming, I'm having to reboot those skills.
The team knows this, but they've learned that "I don't know that yet" from me doesn't mean I can't know the answer. What it means is that I will come up with it quicker than they will. Often I go back to my desk, type in some magical search term, and walk back saying, "Search for this. We'll find the answer in these keywords."
Experience at my stage isn't about knowing things; it's about knowing how to know. This is what I'm trying to teach them, more than anything else. How do you search for the answer, and how will you incorporate it into your code? I've been a little more harsh on the Docker people; they're in the habit of cutting and pasting from Stack Overflow without really understanding the underlying mechanisms, and so I ask a lot of questions about "I'm curious, how do you expect this works?" and "I'm curious, why did you choose this?"
By the way, that phrase, "I'm curious," is super useful; it creates a consensual context for a question that has no "bad" answers, only ones with differing degrees of correctness, and sets the person answering it up for success. Learn to use it.
I spend a lot of time walking around the work "pod," answering questions. A do a lot of code reviews where I say things like "The next person to look at this, who might even be you, might have no idea why this is like this. Please add a comment explaining why you chose to do it this way" and "Could you please include the JIRA ticket in the pull request?"
This is the biggest lesson I've learned in my second major mentorship role: it's not just okay to say "I don't know," it's necessary. I seem to know everything: from kernel modules to the basics of graphic design and CSS. I quote Captain Kirk a lot: "You have to learn why things work on a starship." (We will ignore the fact that the cryptographic key to every Federation Starship's command console is a five-digit PIN with no repeating digits; although I would hope that was just the password to the real key and requires executive biomarkers just to type in!)
"I don't know that yet." indicates vulnerability. I don't know everything. They respect that. Better, they trust when I give them answers, because they trust that I do know what I'm talking about at those times. The "yet" is also a huge part of the lesson: "I don't know, but I'm going to find out." And when I do, I'll share it, document it, and keep it for other people.
So be fearless about admitting ignorance. If you're a greybeard developer like me, your number one skill should be learning faster than anyone else. That's it. You know how to know. You know how to learn. When someone on the team is lost, you know how to find the path, and how to show them where it is. That's what they're paying you for: the experience needed to know how pull other people up to your level.