I don't know it all, and that's OK

This post was published on June 15, 2023

This blog post was published earlier in my (now defunct) weekly newsletter on April 19, 2023.

Over the last couple of months, I’ve been thinking a lot about where to focus on in my work and in my life in general. This after a period where I felt I spread myself too thin, taking on or pursuing lots of different things because I felt like I ‘had to’ do it all.

Aristotle famously wrote “The more you know, the more you realize you don’t know”, and while I have known that there’s a lot of truth in that for a long time, I haven’t really acted on it enough.

This is why lately, I’m focusing my thinking, writing, training, speaking and work in general more on the topics that interest me, and happily leave other topics for others to pursue. I simply can’t do or know it all, and I don’t think there’s anybody who actually can.

As an example, here are some of the topics I am actively working on / with these days, and where my interests and experience mainly is centered around:

• API testing and mocking
• Contract testing
• Writing better code and applying good object-oriented programming practices

I also have a decent working knowledge of some other technologies that are important in my line of work, including:

• UI automation (especially with Selenium and other WebDriver-based libraries)
• CI platforms and Git

Yet other areas I am exploring at the moment, with the potential of them being added to the first list. These days, that’s mostly API security and how to test for that.

But there are many subjects I know I don’t have a lot of experience in, such as:

• Performance testing
• Mobile testing and automation
• AI and ML

Where I used to try and stay on top of all of these things, I know happily refer people who ask me about these things to others. And yes, that’s even when there’s money to be made from it. I would be doing myself and them a disservice if I tried to wing it during a talk, training session or whatever on any of these topics.

I’m applying this lesson I’ve learned in a somewhat similar way in training sessions these days.

Even when it’s a training session on any of the topics that I listed first (and again, I try and focus on running training sessions on those topics these days), questions will come up that I cannot answer off the top of my head.

Even in an area where you are knowledgeable, and even when you’re seen as ‘the expert’, there are bound to be plenty of things you don’t know, or don’t know yet. And that’s OK. Nobody expects you to know everything.

I try to mitigate the risk of this happening partially by discussing the scope of the training and the topics covered with the participants or the training manager. While that helps, it doesn’t eliminate the chances of questions I cannot immediately answer coming up. And that’s absolutely fine, because eliminating that would be impossible.

Quite the opposite, I embrace these questions, because they present an opportunity to learn, for me AND for the participants. I deal with these questions typically in one of three ways:

• Sometimes, my answer is “let’s figure this out together” - this works especially well if chances are high that the answer is a Google search away
• Sometimes, my answer is “I’ll get back to you on that”- this works well if I sort of know where to look, but will need a bit more time to figure out a good answer
• Sometimes, my answer is “I don’t know” - this is perfectly acceptable for questions that are further outside your realm of knowledge and experience

It’s OK to say you don’t know something. People will often actually respect you for saying that.

Also, I’ve noticed that saying “I don’t know” raises the confidence of people in my courses, as it shows that even after 17 years of working in a field that’s still relatively new and sometimes daunting to them, you don’t know and don’t have to know everything.

An example: I still sometimes struggle with the syntax for a switch statement in Java, and I’m happy to show and tell that in talks and courses. I know switch statements exist, I know what they do, I know when and when not to use them. That’s important. Remembering the syntax isn’t, that’s a simple Google search.

How do you deal with focusing on specific subjects in your work? And with not knowing everything? I’d love to hear from you.

"