"Dad, why's the sky blue?"
I confidently told my son: "I don't know." And that's okay, because most people - and even most dads - don't know why the sky is blue.
In IT, though, there seems to be a nagging feeling that we're supposed to know everything under the sky. Problem is, we don't know everything. We can't. It's impossible.
If I'd have told him a made-up reason, he would have eventually caught me out. Far better to admit you don't know something...for now...but that you'll find out.
When you're first studying computers you learn how to write loops, branching instructions, read from and write to files, maybe throw some graphics on screen and do basic maths. This is pretty much where you are fresh out of university. At this level, it's safe to say that you don't know most things. Mistakes are quickly forgiven, as you're usually following the directions of a senior staff member. Your mistakes usually don't have a large footprint on the business.
After a while you've done that for a few different roles and started to see some underlying patterns. Your experience starts to play a role, letting you model new features in your head a little bit better. You start designing for both the current task and maintenance. Meta-programming, if you will. It's more about architecture and procedure than about the individual loops and branches. You know more things, your decisions are more fundamental and affect a larger portion of the codebase. When you make a mistake here in the architecting of the software, your decisions can have wide-ranging implications.
Eventually it dawns on you that Software Engineering is *not* a profit center. That means that we have a pretty sharp responsibility to the business that pays us to deliver software both on time and within budget. We need to use every trick we can find to make this possible (while not compromising the meta-programming above). Of course, your decisions at this point have the widest-ranging impact. Go down the wrong path and the company could spend lots of money trying to change course at a later date.
I haven't even mentioned the specifics of programming...which language, which OS, which targets, etc. All of those need to be learned independently too.
You see, there's a *lot* to learn...no matter where you are in your career. This can lead to imposter syndrome, where you feel you'll never learn enough to be considered truly knowledgeable.
It is terrifying at most companies for an engineer to say those little words: "I don't know". It can take incredible courage. Perhaps the person you're talking to will find out you don't know everything. Perhaps YOU will finally have to admit you don't know everything.
The thing is...how can you ever learn if you can't admit that you don't know?
If you're an engineer and you don't know something, admit it. Out loud. People are going to figure you out pretty quickly if you claim to know something but then show them you do not.
Every single person you're going to speak with today has something to teach you. Your role (whether you know it or not) is to figure out what that thing is. And then work like hell trying to learn it.
I would go so far as to say it is *critical* for the environment of a healthy organisation to accept or even celebrate when an engineer has the intelligence to know when he doesn't know and the courage to admit it in public.
So, for those of you dying to know why the sky is blue (because we all want to know everything), here's the answer: https://spaceplace.nasa.gov/blue-sky/en/
When your son or daughter asks, you can now tell them. They will be as astounded as my son was when I finally was able to tell him.