The magical power of questions

Yesterday I was listening to Eric Johnson (a Principal Developer Advocate for AWS) on the Serverless Chats podcast and was heartened to hear him open up about meetings with his colleagues inside AWS where they admit to not knowing what something is or how another AWS service worked and when you might want to use it. (timestamped podcast link)

There are a few lessons to take away here.

Firstly, AWS is a huge beast and I doubt there is a single person in the world who has a broad and deep knowledge of every service they offer. No-one should feel bad about only having knowledge of a few services. I personally feel this impostor syndrome when hanging out in AWS forums, seeing re:Invent announcements, seeing LinkedIn updates of folks getting AWS certifications (I have zero) and reading link roundup newsletters with a huge list of new articles on serverless/cloud that I’ll never get time to all read. “Am I best serving my clients if I don’t learn about these other services/tools/techniques/new features?”

Secondly, it helps to get comfortable with saying “I don’t totally understand” and then asking (possibly dumb-sounding) questions. Don’t be afraid to zoom out from an in-the-weeds detailed discussion to a higher-level with questions like: “What were the motivations for choosing this service in the first place?” or “What role does it play in the whole system?” . Shawn Wang has a good article on different approaches juniors and seniors can take to confessing ignorance which he calls Lampshading.

On the other side of the conversation, if you’re the person describing something to colleagues, let’s say a proposed architecture for a new product feature, it helps to try and invite questions. If I finish an explanation of something non-trivial and everyone says they understand and don’t ask questions, I get a bit dubious—it’s highly unlikely that I nailed every question and objection for everyone listening in the first attempt. This can be a personal or cultural thing where they just don’t feel comfortable asking. One technique I find useful is to try to remember when I first learnt about the topic and remember what objections, concerns and unknowns I had and then use these as follow-up question prompts: “Can you see where this fits into the overall system?” or “Can you see what parts of the codebase you’d need to change to implement this?“.

And I also realise the irony here that a lot of what I talk about in these emails may not be clear to you folks. So please feel free to reply to any of my emails with any questions (no matter how fundamental or dumb sounding) and I’ll be happy to help however I can.

Go forth and ask/invite questions!